/var/run/chef-client.pid and instruct the chef-client process to write its PID
to this file when daemonizing. Without a pidfile, the status and onestatus
command fall back to process inspection. If chef is run with a resource defined
to :stop the chef_client service, such as chef-client::cron, then the
non-daemonized chef-client process effectivelly kills itself by running
/usr/local/etc/rc.d/chef_client status and /usr/local/etc/rc.d/chef_stop.
Run chef-client manually, then run /usr/local/etc/rc.d/chef_client onestatus.
The status will report chef-client running with the PID of the manually invoked
chef-client process.
- Bump PORTREVISION
Submitted by: Scott Sanders <ssanders@taximagic.com> (private e-mail)
Approved by: maintainer (implicit)
Feature safe: yes
literal name_enable wherever possible, and ${name}_enable
when it's not, to prepare for the demise of set_rcvar().
In cases where I had to hand-edit unusual instances also
modify formatting slightly to be more uniform (and in
some cases, correct). This includes adding some $FreeBSD$
tags, and most importantly moving rcvar= to right after
name= so it's clear that one is derived from the other.
configuration management to your entire infrastructure. With Chef, you can:
* Manage your servers by writing code, not by running commands.
* Integrate tightly with your applications, databases, LDAP directories, and
more.
* Easily configure applications that require knowledge about your entire
infrastructure ("What systems are running my application?" "What is the
current master database server?")
WWW: http://wiki.opscode.com/display/chef/Home
PR: ports/153504
Submitted by: Renaud Chaput <renchap@cocoa-x.com>
Feature safe: yes
