Bug#889640: lintian: init.d-script-possible-missing-stop misfire on rcS scripts
On Mon, Feb 05, 2018 at 08:48:57PM +0530, Chris Lamb wrote:
> tags 889640 + moreinfo
> thanks
>
> Hi Ron,
>
> > # Default-Start: S
> > # Default-Stop: 0 6
> >
> > Will cause lintian to complain about it not being stopped in runlevel 1,
> > with a rationale that would be fine for services started in 2-5, but that
> > doesn't really apply for things which can be shut down in an orderly way
> > but shouldn't be just because you're switching to or entering runlevel 1.
>
> Getcha. I'm not an runlevel expert, but do you suggest we don't emit
> this tag at all for scripts that /include/ 'S' in Default-Start or for
> ones that /only/ have 'S' (ie. "Default-Start: S")
Ok, so this one turns out to be a little more convoluted than I always
understood it to be ...
The rcS runlevel is/was used for things which need to be started early
in the boot sequence, regardless of which runlevel the system was going
to enter. Ostensibly the 'S' stands for 'single user', but there's a
fuzzy overlap in that particular role as rc1 is also a/the single user
mode runlevel (but rc1 scripts only get invoked when explicitly entering
or leaving runlevel 1) ...
With that in mind, for something started in rcS, there's usually only
two sensible behaviours for when it should be stopped. It may be a
one-shot task, which runs at early boot then exits, so it never needs
to be stopped, or it sets up or runs something which shouldn't be
explicitly stopped before the CPU itself is halted or rebooted - for
both those cases nothing would be specified for Default-Stop.
Alternatively, it does start some long-running early boot service, which
can and should be explicitly shut down in an orderly way when the system
is being halted (0) or rebooted (6). But which should remain running in
single user mode (S/1).
In line with that, every rcS script I recall ever looking at (and all
the ones still on the machines I checked here), used either:
# Default-Start: S
# Default-Stop: 0 6
or
# Default-Start: S
# Default-Stop:
So to directly answer your question above, it would probably be a
(separate) bug for anything that had 'S' in Default-Start to have
any other runlevel included there too (because entering any other
runlevel will have already run the rcS start scripts anyway).
Where things start to get a bit more confusing is that the initscripts
package ships a SysV init script 'killprocs' - which is 'started' upon
entering runlevel 1, and basically brutally slaughters *every* process
except the kernel threads, init, and the shell running it, with
killall5(8) ... after which the /etc/rc1.d/single script is run, which
then changes from runlevel 1 to runlevel S - restarting all the things
in rcS again to actually enter the real 'single user mode' ...
So ostensibly, the lintian warning is actually correct about what will
happen if 1 isn't included in Default-Stop - it will still get killed
anyway, but then immediately be (re)started again ...
But wait! There's more!! The reason I missed that detail when I first
reported this was that on the buster system I looked at this all on,
the initscripts package isn't installed, so there is no killprocs
script on it - and even if it was installed, when systemd is installed
it masks that script so that it won't run at all. But that in turn
makes this all a bit moot on current releases, because since Stretch,
systemd won't run rcS scripts at all - if they don't have a native unit
now, it simply ignores them completely ... which means this all really
only matters for Hurd/kFreeBSD and people not running systemd (in which
case sysvinit-core will pull in initscripts again).
So with all that said and done, I think the somewhat dizzying conclusion
is that:
- lintian is actually right.
- almost everything I know of providing an rcS script gets this wrong.
- killprocs seems a little bit batshit, but I can sort of see the
logic of wiping out everything and starting again with a clean
slate if you're changing to runlevel 1 from some other runlevel
(and who ever does that anymore anyway if you weren't thrown into
it due to a boot failure!)
- hopefully everything in rcS is actually safely idempotent if anyone
does try that.
- there was probably something else, but now I need a stiff drink and
a lie down, safe in the knowledge that every time I look at init
stuff it's always more horribly broken in ways that I never imagined
the last time I shook my head at how horribly broken it all was ...
And unless I've really missed some other detail there, we can probably
just close this one, leave lintian as is, and point at this bug log if
anyone scratches their head at this warning again in the future ...
Sorry for the noise on this one then. For most things, killprocs will
probably only do the same thing that the service's own stop function
would do (send a polite, then more insistent signal to terminate it),
so it's probably not a big deal to have runlevel 1 missing from the
Default-Stop - but lintian is right that leaving it out won't prevent
it from being stopped and restarted when switching to runlevel 1, so
unless killprocs changes, this warning was unexpectedly educational :)
Cheers,
Ron
Reply to: