On Sat, 5 Mar 2011 01:40:15 +0200, Faidon Liambotis <[email protected]> wrote:
> On Thu, Mar 03, 2011 at 12:31:07PM -0500, micah anderson wrote:
> > On Wed, 02 Mar 2011 11:28:46 -0500, micah anderson <[email protected]> wrote:
> What can we do to have this backported in squeeze as well? Can I do
> anything to help? I can NMU but I maybe you prefer handling this as a
> maintainer upload, no?

I sent the request to debian-release to have this put in as a stable
point release update, but I'm afraid that I am now unsure that it is a
proper fix. One way to help would be to help me sort this out.

The enable portion of the diff looks like this:

@@ -43,6 +43,6 @@ Puppet::Type.type(:service).provide :debian, :parent => :init 
do

   def enable
     update_rc "-f", @resource[:name], "remove"
-    update_rc @resource[:name], "defaults"
+    update_rc @resource[:name], "enable"
   end
 end

This seems to throw errors if no symlinks exist for the service. Perhaps
this is fine if all that is ever being done is to re-enable a previously
disabled service, is that true?

However, it is called right after an 'update-rc.d remove' which seems
like it would break, for example:

First we make sure that a service is properly enabled:
# invoke-rc.d --query ssh start
# echo $?
104
(according to invoke-rc.d 104 means that its properly enabled)

so lets disable it using the mechanism that puppet would use with this
patch to disable it, and then once its disabled, we will enable it again
and see the problem:

# update-rc.d -f ssh remove
update-rc.d: using dependency based boot sequencing
# echo $?
0
# update-rc.d ssh disable
update-rc.d: using dependency based boot sequencing
update-rc.d: error: no runlevel symlinks to modify, aborting!
# echo $?
1
# invoke-rc.d --query ssh start
105

(note 105 is behavior uncertain)

So that would be the state it is in when we do an enable, now lets do
the enable that puppet would do:

# update-rc.d -f ssh remove
update-rc.d: using dependency based boot sequencing
# echo $?
0
# update-rc.d ssh enable
update-rc.d: using dependency based boot sequencing
update-rc.d: error: no runlevel symlinks to modify, aborting!
# echo $?
1
# invoke-rc.d --query ssh start
# echo $?
105

And again, we are in an unknown state. 

So... I'm a little puzzled about what the right way to do this is. Is
using insserv directly the right way to do this? Can we count on insserv
being available on all squeeze systems, and dependency-based initscripts
enabled? What if they are not?

This would also make backporting to lenny a problem because "update-rc.d
foo {en,dis}able' would not work right, but this is less of a concern.

micah

Attachment: pgpnXeV1NUKWv.pgp
Description: PGP signature

Reply via email to