On Sun, Feb 02, 2025 at 11:00:46PM +0100, Lorenzo wrote: > On Sun, 2 Feb 2025 21:00:41 +0000 > Andrew Bower <and...@bower.uk> wrote: > > For the boot entry I can just remove the wtmpdb call in stage 1; for the > shutdown entry in runit, is implemented as "halt -w[1]" in shutdown.c > that is called by umountnfs.sh in runlevel 0 or 6, and it's not obvious > to me how to prevent a double shutdown entry here. > maybe the sysv script can be a no-op when runit is init? > > [ -f /run/runit.stopit ] && exit 0 > > better ideas are welcome; when I added the code to runit I didn't think > a sysv script was going to be accepted in the wtmpdb package.
What about /etc/runit/override-sysv.d? > [1] by the way, what's the plan for 'halt -w' in SysV 's shutdown > implementation? No idea, hoping the experts on this mailing list will chime in! :-) However, since umountnfs.sh is an initscript that won't be used from systemd, it seems to me that this would be the place to call wtmpdb, instead of going via the halt command. That then makes this a co-ordination question between this initscript and the wtmpdb one? We might find out that the call is redundant from umountnfs.sh if we have the wtmpdb initscript. But in the case of sysvinit, it still records classic wtmp. It could simply continue to do so. That might be useful in an ultra low footprint scenario where some minimal audit capability is required - the use case where my proposed sysvinit-utmp-utils subpackage would be useful. By the way, killing plymouth lets this script start in S runlevel in single user mode, but it also means double entries for every boot. I don't know why. I think perhaps we could start with runlevel 1+ and then iterate the initscript if we find we can improve on this?
