changes in update-rc.d breaks Chef::Provider::Service::Debian

it's a bit more than that
the output format has also changed.
I guess it should not rely on commands' output because its output format might change and also might be subject to localisation.

anyway, here's a quick fix: http://gist.github.com/459877

Laurent, Can you get a CLA filled out? I need it before I can use your code.

http://wiki.opscode.com/display/chef/How+to+Contribute

Once that's taken care of, could you publish a CHEF-1407 branch to your fork on Github and mark this ticket as resolved?

Thanks,

Dan DeLeo / kallistec

fixed in llaurent/CHEF-1407 (http://github.com/llaurent/chef/tree/CHEF-1407)

bulk updating fix versions to next release

Laurent,
Can you add tests for this as well, please? The ideal way to goo would be to grab stdout and stderr separately from an invocation of the command and use that as data in the test(s). Look at the existing tests for an example:

http://github.com/opscode/chef/blob/43d791d6195817edc7dbf8a0b434dc4d0fe6ff7f/chef/spec/unit/provider/service/debian_service_spec.rb

and of course bug me if you have any questions.

Thanks.

I've updated the spec as well, but i'm not too sure about what i've changed.

in debian/lenny :

/usr/sbin/update-rc.d -n -f chef-client remove  
 Removing any system startup links for /etc/init.d/chef-client ...
   /etc/rc0.d/K20chef-client
   /etc/rc1.d/K20chef-client
   /etc/rc2.d/S20chef-client
   /etc/rc3.d/S20chef-client
   /etc/rc4.d/S20chef-client
   /etc/rc5.d/S20chef-client
   /etc/rc6.d/K20chef-client

in debian/squeeze :

/usr/sbin/update-rc.d -n -f chef-client remove 
update-rc.d: using dependency based boot sequencing
insserv: remove service /etc/init.d/../rc0.d/K02chef-client
insserv: remove service /etc/init.d/../rc1.d/K02chef-client
insserv: remove service /etc/init.d/../rc2.d/S17chef-client
insserv: remove service /etc/init.d/../rc3.d/S17chef-client
insserv: remove service /etc/init.d/../rc4.d/S17chef-client
insserv: remove service /etc/init.d/../rc5.d/S17chef-client
insserv: remove service /etc/init.d/../rc6.d/K02chef-client
insserv: dryrun, not creating .depend.boot, .depend.start, and .depend.stop

lines starting with "insserv:" are sent to STDERR

so the change in provider/service/debian.rb is a quick fix to it work with squeeze and oldest releases, but i'm not sure that quick fix should be reflected that quickly in the spec.

Laurent,
You're on the right track here, but I think we need tests that cover both situations: the one we currently support where everything goes to STDOUT, and the squeeze scenario where some output goes to STDERR. So basically you want to keep the tests that are already there, and add new ones that test the squeeze behavior.

Thanks,

Dan

i've discovered that http://github.com/opscode/chef/commit/ad90e98fc969cd872802967217b52592cc54c1d2 breaks debian/stable. The patch is only half-ok for squeeze and earlier as there's no way to enable the service after it has been disabled (with update-rc.d service disable).

in that case, update-rc.d service enable has to be run instead of update-rd.d service defaults.

The disable|enable API is not stable and might change in the future.

also i don't see why disable_service() and enable_service() are defined twice.

ok, there're a lot of issues to be resolved in this provider. They'll be addressed in different tickets.

For now i've updated llaurent/CHEF-1407 to fix the tests.
two different ways: HEAD~1(duplicated code) and HEAD

i'm closing it, i don't want it to be missed in the next merges

laurent,

Can you please confirm for me that this is not resolved?

I'm not seeing this on lenny, so I assume it's a squeeze problem. If this is not resolved, please reopen and assign to me and I will fix it in my ongoing debian service provider refactor.

this is fixed, but feel free to merge it into your fixes. If you feel like fixing it in another way it's also ok.

Merged this bad boy, thanks for all hard work everyone!

https://github.com/opscode/chef/commit/9f3b09771bb34a0e11c25b3e13323a497798a10d

Dan

There are some issues conflicting here with the priority work due to the use of insserv in squeeze.

In the priority work in CHEF-1794, when we disable a service we have update-rc.d stop it in all run levels. However, insserv ignores this and uses the LSB values in the init script, choosing the priority as part of its "dependency based boot sequencing".

btm@btm-mbp-squeeze:~$ grep Default- /etc/init.d/apache2
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
btm@btm-mbp-squeeze:~$ sudo /usr/sbin/update-rc.d -f apache2 stop 80 2 3 4 5 .
update-rc.d: using dependency based boot sequencing
update-rc.d: warning: apache2 start runlevel arguments (none) do not match LSB Default-Start values (2 3 4 5)
update-rc.d: warning: apache2 stop runlevel arguments (2 3 4 5) do not match LSB Default-Stop values (0 1 6)
btm@btm-mbp-squeeze:~$ find /etc/rc* -name '*apache*'
/etc/rc0.d/K01apache2
/etc/rc1.d/K01apache2
/etc/rc2.d/S18apache2
/etc/rc3.d/S18apache2
/etc/rc4.d/S18apache2
/etc/rc5.d/S18apache2
/etc/rc6.d/K01apache2

If we modify the init script, then we can get affect the outcome of update-rc.d

btm@btm-mbp-squeeze:~$ grep Default- /etc/init.d/apache2
# Default-Start:     
# Default-Stop:      0 1 2 3 4 5 6
btm@btm-mbp-squeeze:~$ sudo /usr/sbin/update-rc.d -f apache2 stop 80 2 3 4 5 .
update-rc.d: using dependency based boot sequencing
update-rc.d: warning: apache2 stop runlevel arguments (2 3 4 5) do not match LSB Default-Stop values (0 1 2 3 4 5 6)
btm@btm-mbp-squeeze:~$ find /etc/rc* -name '*apache*'
/etc/rc0.d/K01apache2
/etc/rc1.d/K01apache2
/etc/rc2.d/K01apache2
/etc/rc3.d/K01apache2
/etc/rc4.d/K01apache2
/etc/rc5.d/K01apache2
/etc/rc6.d/K01apache2

Obviously this is intrusive to the init script and unacceptable. I think the solution is to use enable/disable on squeeze. I'm not yet sure what the correct course here is, perhaps an insserv service provider.

Wrote an insserv service provider. It doesn't support priorities. We're going to have to figure out how to do that all over again on insserv, but at least we're not getting ignored anymore.

https://github.com/btm/chef/tree/CHEF-1407_insserv

the insserv provider looks ok here.
I'm just having some special needs, i manage some init scripts with chef.
If I changed the start level from S to 2345, the provider won't make any change. As a workaround, I use notification in my recipes so that the links get immediatly removed when the init script is updated.

It's going to be tricky to add that kind of detection in the provider with insserv instead of the glob().
I guess we would need to do the glob() and check every links with the result of "insserv -n -f -r corosync" to see if the links are correctly set.
What do you reckon ?

See CHEF-2034 for further discussion on improving the insserv provider.