Re: runit SIGPWR support
s6-linux-init has a suitable open file descriptor. It is its standard input, before it closes it to do the slashdev test. Of course, but once the fd is closed, /dev/console should not have any impact on the process, so would a kbrequest still reach it? -- Laurent
Re: runit SIGPWR support
El lun., 24 feb. 2020 a las 19:49, Laurent Bercot escribió: > > So there is no fd to call the ioctl on, and no way for a user to trigger > a kbrequest. s6-linux-init has a suitable open file descriptor. It is its standard input, before it closes it to do the slashdev test. G.
Re: runit SIGPWR support
El lun., 24 feb. 2020 a las 19:25, Laurent Bercot escribió: > > I purposefully did not add a default SIGWINCH handler, because > sysvinit does not come with a default kbrequest in /etc/inittab. > I added a SIGPWR handler that performs a regular poweroff because > it sounds like a sane default for a power failure. I see. I couldn't tell whether the omission of .s6-svscan/SIGWINCH was intentional or not. > The output of s6-l-i-m is only a baseline, a starting point; > it can be tweaked for arcane stuff such as non-default shutdown and > kbrequest. OK. G.
Re: runit SIGPWR support
However, I was not aware that kbrequest needed a special ioctl call before it can be accepted, so thank you for that; I'll add the call to s6-l-i. Scratch that. s6 never uses /dev/console as input: s6-l-i redirects stdin to /dev/null. (This is intentional, and is not changing.) So there is no fd to call the ioctl on, and no way for a user to trigger a kbrequest. A minor inconvenience compared to the advantages of not having any /dev/console input. CAD still works because it's treated as a special event by the kernel, not something that's tied to a fd receiving input. -- Laurent
Re: runit SIGPWR support
I purposefully did not add a default SIGWINCH handler, because sysvinit does not come with a default kbrequest in /etc/inittab. I added a SIGPWR handler that performs a regular poweroff because it sounds like a sane default for a power failure. I suppose I could add an empty SIGWINCH script by default, to avoid polluting logs if a kbrequest arrives and s6-svscan fails to spawn the corresponding, nonexistent, script. I don't much like the idea of wrapping every s6-l-i action with a script; if someone wants a kbrequest handler, they can write a .s6-svscan/SIGWINCH file. It's not an obvious configuration switch, but people who know what a kbrequest is and who know that they need one will find it without any trouble. The action for SIGPWR, and for other signals, in s6, is also entirely configurable: the user can modify the .s6-svscan/SIGfoo script themselves. The output of s6-l-i-m is only a baseline, a starting point; it can be tweaked for arcane stuff such as non-default shutdown and kbrequest. However, I was not aware that kbrequest needed a special ioctl call before it can be accepted, so thank you for that; I'll add the call to s6-l-i. -- Laurent
Re: runit SIGPWR support
The keyboard signal can actually be set to any signal less than or equal to NSIG with the KDSIGACCEPT ioctl. sysvinit just happened to pick SIGWINCH for that, and so did systemd and nosh, presumably for compatibility. El dom., 23 feb. 2020 a las 20:53, Laurent Bercot escribió: > > Both SIGPWR and SIGWINCH are caught in the latest s6 git head. > > Release coming whenever real life stop throwing things at me and I > can actually find a week-end to polish things and cut it. I noticed that you modified s6-svscan to divert SIGPWR and SIGWINCH, but s6-linux-init-maker only creates a handler for SIGPWR (that just does 's6-inux-init-shutdown -a -p -- now', like the SIGUSR1 handler). If you bothered making SIGWINCH 'divertable', you could also add the KDSIGACCEPT ioctl() call to the stage1 init (s6-linux-init), just like you did with the reboot(RB_DISABLE_CAD) call, and have s6-linux-init-maker create a run-image/service/.s6-svscan/SIGWINCH file. My suggested action for SIGWINCH would be to execute a file in the 'scripts' subdirectory of the basedir. The skeldir counterpart of this file could be a shell script with only explanatory comments, just like the skeldir's rc.shutdown.final (so, by default, unless the administrator configures something, the keyboard signal would do nothing). Since the inittab action field for the keyboard signal is "kbrequest", the target unit that systemd starts in response to the keyboard signal is named "kbrequest.target", and the target bundle that nosh's system-manager starts in response to the keyboard signal is named "kbrequest", my extremely original suggestion for the script's name would be... "kbrequest" :) (Actually, for sysvinit, systemd and nosh, the action in response to SIGPWR is also configurable, and by default SIGPWR does nothing, so I don't know what LXC containers do if they include an init system… they must have some extra configuration I guess). G.
Re: runit SIGPWR support
in this case systemd compatibility can be trivially achieved, so there is no real reason to abstain from it. "systemd compatibility" makes no sense here. We are talking about runit or s6 as an init system: by definition, in that context, there is no systemd, no interaction with systemd, nothing that requires compatibility with systemd. If by "compatibility" you mean: doing the same things that systemd does, following the same API, aligning on its choices, then I have a question for you: are you also in systemd discussion spaces and asking them to align on the design choices made by s6? Why not? systemd uses real time signals since they were introduced for this purpose: signals without an already assigned default meaning, free for application (ab)use, hence the systemd approach is absolutely correct here. systemd uses a mechanism that it chose, and that works. sysvinit uses another mechanism, and that works. busybox init uses another mechanism, and that works. runit uses another mechanism, and that works. s6 uses another mechanism, and that works. What do you have trouble understanding? #else /* probably OpenBSD */ #endif Ah yes, very accurate heuristics, absolutely up to par with my code quality standards. 10/10, would throw into the garbage bin again. -- Laurent
Re: runit SIGPWR support
On Mon, Feb 24, 2020 at 04:12:31PM +0300, innerspacepilot wrote: > On 24.02.2020 13:23, Laurent Bercot wrote: > > > SIGRTMIN+3 should also be caught and processed. > > > > What piece of software sends SIGRTMIN+3 to pid 1 when you're not > > running systemd? > > > > -- > > Laurent > > > Looking at lxc sources (src/lxc/lxccontainer.c:2084) nothing will, until > you block SIGRTMIN+3 signal. > > Even if you add SIGRTMIN+3 it will not work. Why do you say that? > Maybe we should open bug request on lxc and welcome developers from > other init systems to make an arrangement on common shutdown signal? Sure, either open an issue in github.com/lxc/lxc, or email the list (lxc-de...@lists.linuxcontainers.org) -serge
Re: runit SIGPWR support
On 24.02.2020 13:23, Laurent Bercot wrote: SIGRTMIN+3 should also be caught and processed. What piece of software sends SIGRTMIN+3 to pid 1 when you're not running systemd? -- Laurent Looking at lxc sources (src/lxc/lxccontainer.c:2084) nothing will, until you block SIGRTMIN+3 signal. Even if you add SIGRTMIN+3 it will not work. Maybe we should open bug request on lxc and welcome developers from other init systems to make an arrangement on common shutdown signal?
Re: runit SIGPWR support
24.02.2020, 11:23, "Laurent Bercot" : >> SIGRTMIN+3 should also be caught and processed. why only this one and not ALL of the real time signals ? > What piece of software sends SIGRTMIN+3 to pid 1 when you're not > running systemd? in this case systemd compatibility can be trivially achieved, so there is no real reason to abstain from it. systemd uses real time signals since they were introduced for this purpose: signals without an already assigned default meaning, free for application (ab)use, hence the systemd approach is absolutely correct here. support code for ALL of the RT signals on ALL platforms that provide them can be added without much effort (in a "POSIX-correct" way that is always so important to you): https://man.voidlinux.org/signal.h ... #include ... #if defined (SIGRTMIN) && defined (SIGRTMAX) /* catch and handle them with a hook executable like say * "SIGRT signum" * that is called with the RT signal number as a first parameter */ #else /* probably OpenBSD */ #endif ...
Re: runit SIGPWR support
SIGRTMIN+3 should also be caught and processed. What piece of software sends SIGRTMIN+3 to pid 1 when you're not running systemd? -- Laurent
