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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
