On Thu, Jan 06, 2022 at 01:07:01AM +0100, lorenzo wrote: Hi,
> > You now have two flag files and unconditinally use > > /lib/runit.runlevel.6 first if it exists, even if > > /lib/runit.runlevel.0 also exists and is newer. > > Please look at > https://salsa.debian.org/debian/runit/-/commit/2c56dadf15fef1bc809c00aec903970617aeb948 Yes, that's what I was looking at. > The flag file is /run/runit.runlevel.$LAST and /run is mounted as tmpfs > in Debian by default, so it's not persistent across reboots. > Am I loosing something relevant? Yes; I think you place too much faith in things being nice and clean and standard everywhere. :) In reality, I think people will have systems where /run isn't a tmpfs; they'll have homebrew scripts that muck around with the runit flag files in strange and wonderful ways; they'll initiate a reboot, then change their minds and try to shut down; they'll restore the contents of /run from a backup that accidentally included it; they'll syncrhonize it with another computer; etc. etc. Some computers are left running for years without rebooting, and may see a dozen new runit package versions being installed in the meantime (I'd be willing to bet there are still running runit instances that will look for /etc/runit/stopit instead of /run/runit.stopit). It's really impossible to anticipate all the kinds of messy environment your code will be expected to run in. Considering that 1. runit's philosphoy is to try to avoid race conditions and fragiliy arising from e.g. the use of PID files; and that 2. it's not terribly hard to get it right(er) by using the flag file that is most recent, I think it's worthwhile to do so. It certainly doesn't seem like a good idea to me to explicitly implement fragility (depending on /run being "clean"). > > (FWIW, I think the technically correct solution would be to have a > > "runit runlevel daemon": a simple process that provides a fifo to > > read the current runlevel from, and another fifo to write into when > > the runlevel changes; but this is overkill as the concept of a > > 'runlevel' is very rarely needed.) > > I see it in a different way: the proper solution here would have to have > a native set of runit boot and shutdown scripts, and drop most of the > Sysv compatibility. That's the high-maintenance solution, yes. However, in this particular case I think it's possible and worthwhile to achieve a limited but sufficient degree of compatibility (and to make it as robust in the face of unexpected messes as is possible without making it too complex). > I don't have time to maintain such set of scripts right now, so my > second best option is to use initscripts and keep some minimum level of > Sysv compatibility. Glad we're on the same page. :) András -- Dave, put down those Windows disks. Dave, please. DAVE! - HAL 9000
