[Pkg-sysvinit-devel] Bug#545448: Bug#545448: invoke-rc.d should indicate whats wrong when not starting services

[Patrick Schoenfeld]

Hi,

On Mon, Sep 07, 2009 at 12:41:18PM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 07 Sep 2009, Patrick Schoenfeld wrote:
> > On Mon, Sep 07, 2009 at 11:26:38AM +0200, Petter Reinholdtsen wrote:
> > > [Patrick Schoenfeld]
> > > > recently I stumbled across some behaviour in invoke-rc.d which I
> > > > consider somehow broken. When trying to start a service with
> > > > invoke-rc.d it sometimes refuses to start the service, without a
> > > > notice whats wrong. Of course not starting services under some
> > > > circumstances is OK, but not telling the user whats wrong isn't.
> > > 
> > > When does this happen?  How can we reproduce it?  Currently your
> > > request is to vague for me to know what do adress. :)
> > 
> > Good question. If the program had proper diagnostic messages
> > in the first place, it would be easier to answer. What I had,
> > where it happened, is an LSB header like this in the init script:
> > 
> > # Default-Start:  3 5
> > # Default-Stop:   0 1 2 6
> > 
> > System was in runlevel 2, so this script probably did not
> > start because of the wrong runlevel. Script was installed
> > with update-rc.d defaults.
> 
> I.e. invoke-rc.d was doing exactly what it has to do.  The script is not to
> accept "start" or "restart" actions on runlevel 2.  It will allow "stop"
> actions, though.  Invoke-rc.d will not let you start that script unless you
> are at runlevel 3 or runlevel 5, and it will let you stop it on any
> runlevel.  It will let you do anything on runlevel 4 (since behaviour is
> undefined, and doing otherwise would expose bugs on many packages that have
> runlevel S scripts).

sorry.. what?! Why is invoke-rc.d not starting services in the default
runlevel? Or did you want to bring this in relation to the above stated
LSB header?

If yes, you are basically repeating what I already said.
Not needed to tell me what my debugging already brought up.

> > The output of invoke-rc.d was simply nothing. RC = 0.
> 
> Which is also correct, invoke-rc.d is to be used in maintainer scripts, its
> result codes in default mode of operation are optimized for that usage.

Yeah, I know that. And that is okay. However if it does not start a
service (for whatever reason) it should say WHY. It does so for
the policy.d case, why shouldn't it do for the not-the-right-runlevel
case? Its not that it would it be a problem. After all the only
reasoning regarding maintainer scripts is to not disrupt the
installation of a package due to an exit code of rc != 0.

> > Starting it with --disclose-deny yields into rc 101. Thats
> > something to start with, but actually not very much.
> 
> Why are you using invoke-rc.d manually to begin with?  What is the use case
> that is causing problems?

Well, because I need to test somehow why it isn't starting a service from a
maintainer script. As already said: An invoke-rc.d that basically does
nothing, leaving me with an installed package, but without a service
running, without any sign of failure is not particulary helpful.

> > Basically the behaviour is similar as described in the
> > already existing bug reports, with the description that
> > invoke-rc.d simply does not start something, like
> > #452119 or #385593. BTW. the first has the sh -x output
> > attached which you asked for.
> 
> invoke-rc.d exists ONLY to make sure package maintainer scripts will NOT
> start something out-of-runlevel (and to let someone add more policies using
> a separate script, policy-rc.d, very useful for build daemons and build
> chroot jails).  The local admin is not supposed to need this unless he has
> some very weird scripts that should obey the rules just like package
> maintainers do.

Uh? I was under the impression that invoke-rc.d exists also for maintainer
scripts to not know about implementation-specific ways of calling
the init scripts. For example so that we have a central place to change,
in case we ever get the idea to move files away from /etc/init.d
or something like that.

Regards,
Patrick