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
