Tollef Fog Heen email@example.com writes:
]] Bryan McLellan
We’re not crazy about adding resource method solely for this. The
simplest solution is to just run “invoke-rc.d --disclose-deny” all the
time. The big question here, is there a use case where you would have
the service disabled by policy but still want Chef to keep running if
you ask it to start it? Laurent? Thom? Tollef? (CHEF-597 )
Well, invoke-rc.d is not what is used by init, invoke-rc.d is used by
maintainer scripts to decide what, if anything, should be done on
The symlinks in /etc/rc$runlevel.d/ are usually what controls if a
service should start.
I think we shouldn’t use invoke-rc.d, but rather use the service
A use case for having policy-rc.d decline anything invoke-rc.d asks it
would be to not restart services on upgrade, but rather handle that
through chef or similar mechanisms.
To solve Laurent’s use case, I’d say just diverting the service command
at the start and undiverting it afterwards would be just as sane as
“invoke-rc.d is a generic interface to execute System V style
init script /etc/init.d/name actions, obeying runlevel constraints
as well as any local policies set by the system administrator.”
Another use case: I want to do some maintenance by hand, plenty of
recipes use the service resource with action :start. I don’t want chef
to restart a service, some approaches:
- i stop chef-client, here chef is restarted by a cron task if not
running, i also stop cron (does that sound silly ? )
- put a exit 0 on top of the init script (yuk)
- i alter the recipe (or the provider) with a not_if
- i use the policy-rc.d script to return 101 for the service in
The policy-rc.d script only works for debian based systems.
Ever thought of a generic policy system for chef resources ?
It would be better than option 3) and could apply to resources and
possibly to recipes/cookbooks.