services not disabled correctly on Debian

Can you explain how update-rc.d can be used to do this?

There's an example in the man page, as it turns out (which I didn't notice when I filed the original ticket).

       Example of disabling a service:
          update-rc.d -f foobar remove
          update-rc.d foobar stop 20 2 3 4 5 .

yes, just disabling the links will work for a while but fails as at each apt-get upgrade the link will be back. The proper way to prevent this is the above mentionned way:

update-rc.d -f foobar remove update-rc.d foobar stop 20 2 3 4 5 .

this way debian apt does not rebuild the link as they allready exist.

Hmmm - tricky to re-enable. I've tried the above commands:

update-rc.d -f foobar remove
update-rc.d foobar stop 1 2 3 4 5 6 .

and then tried to re-enable:

update-rc.d foobar defaults

I get the error:

System startup links for /etc/init.d/foobar already exist.

But the links remain K* rather than S*

indeed you have to make

update-rc.d -f foobar remove update-rc.d foobar start defaults

i wonder if it keeps the priority numbers, the issue is that not all init script use those even if they should: http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot

those headers are described here: http://wiki.debian.org/LSBInitScripts

ghislain.

Re-enabling in this fashion will indeed not keep priority numbers. Unfortunately, unlike on Red Hat, Debian never represented the priority numbers in the init script itself, so the priority numbers are only known to the package postinst script and aren't really derivable.

The same thing is true, however, of the current behavior. As soon as the init scripts are removed, there's no way to know what priority to put them back at. So that problem is somewhat ancillary to this report.

Dependency-based boot in lenny will hopefully fix the underlying problem.

Then I can't see how this issue can be fixed. Any other ideas?

I don't understand what you don't think can be fixed.

Currently, Puppet runs update-rc.d -f foobar remove. This is not the correct way to disable a service, since it means the service will be re-enabled on package upgrade.

The correct way to disable a service is to run:

    update-rc.d -f foobar remove
    update-rc.d foobar stop 1 2 3 4 5 6 .

When re-enabling the service, Puppet needs to run:

    update-rc.d -f foobar remove
    update-rc.d foobar defaults

This change will fix the current problems with disabling services.

There is a separate problem that both the current Puppet behavior and Puppet behavior after this change doesn't preserve the start order of a script after disabling it and re-enabling it, but that problem is not new and making this change doesn't make it either better or worse.

Okay - fixed in commit [f3fbc77b52bde3ce643d25f4a0d28a2cd35ef52] in branch 0.24.x

Pushed.