Re: runit SIGPWR support

I patched runit-2.1.2 (ALTLinux build) to handle SIGPWR on systems which support it. SIGPWR cause immediate system shutdown just like SIGCONT with executable /etc/runit/stopit present in system. It works with LXD for me. mx --- diff -Naur --new-file a/runit-2.1.2/man/runit.8 b/runit-2.1.2/man/ru

Re: runit SIGPWR support

will the setting achieved by this very ioctl() call survive after exec()ing into another binary (s6-svscan/stage 2) ? Testing on s6-linux-init 1.0.4.0 shows that a SIGWINCH is sent to s6-svscan on kbrequest after s6-linux-init has performed the ioctl. So, the answer seems to be yes. Having

Re: runit SIGPWR support

25.02.2020, 10:08, "Jonathan de Boyne Pollard" : > Yes. First: This is a kernel virtual terminal thing not a console > thing. Strictly speaking, it is doing it wrongly to access it through > the console device, which is not necessarily a KVT. Second: The > mechanism does not require an open file d

Re: runit SIGPWR support

25.02.2020, 10:08, "Jonathan de Boyne Pollard" : >>   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? > > Yes. First: This is a kernel virtual terminal thing not a console > thing. Strictly speaking, it is doing

Re: runit SIGPWR support

24.02.2020, 23:25, "Laurent Bercot" : > 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. will the setting achieved by this very ioctl() call survive after exec()ing into another binary (s6-svscan/

Re: runit SIGPWR support

On 29.02.2020 21:20, Guillermo wrote: El mié., 26 feb. 2020 a las 5:07, innerspacepilot escribió: I have checked openrc and busybox - both support SIGPWR. BusyBox init does support SIGPWR, it is equivalent to SIGUSR1, the signal sent by the 'halt' applet. However, if by "openrc" you mean openrc

Re: runit SIGPWR support

So, I have created a patch for runit to support SIGPWR. https://pastebin.com/PXhUp5B9 Laurent & others, please review. It is not for mainline, it is a patch for linux only (no defines needed). I will offer it to linux distributions based on runit, If no errors found.

Re: runit SIGPWR support

El mié., 26 feb. 2020 a las 5:07, innerspacepilot escribió: > > I have checked openrc and busybox - both support SIGPWR. BusyBox init does support SIGPWR, it is equivalent to SIGUSR1, the signal sent by the 'halt' applet. However, if by "openrc" you mean openrc-init running as process 1, then no,

Re: runit SIGPWR support

Alex Suykov: Just for reference, I checked apcupsd sources. That was not nearly enough research, and your conclusion is ill-founded. The SIGPWR signal, from before Linux even existed, has always meant "something has happened with the power". In AT&T Unix System 5 books it is conventionall

Re: runit SIGPWR support

It might be plain ignorance on my side but is there a possibility that some malicious outsider's intent be able to induce a SIGPWR signal just to fool the system to shut down? If so then hardcoding it as an autoresponse would be perceived as a weakness. The choice for any sysadmin to use the kern

Re: runit SIGPWR support

Fri, Feb 28, 2020 at 07:39:47AM +0100, Jan Braun wrote: > The Linux kernel uses SIGPWR to tell init "there's a power failure > imminent". There's a difference to "please shutdown the system", even if > (current versions of) busybox and openrc choose to shutdown the system > when told about an immi

Re: runit SIGPWR support

innerspacepilot schrob: > I have checked openrc and busybox - both support SIGPWR. > > So I see no reason to change lxd behaviour, unless some realworld > software uses SIGPWR. *sigh* We've been here before. The Linux kernel uses SIGPWR to tell init "there's a power failure imminent". There's a d

Re: runit SIGPWR support

I have checked openrc and busybox - both support SIGPWR. So I see no reason to change lxd behaviour, unless some realworld software uses SIGPWR. On 24.02.2020 18:26, Serge E. Hallyn wrote: On Mon, Feb 24, 2020 at 04:12:31PM +0300, innerspacepilot wrote: On 24.02.2020 13:23, Laurent Bercot wrot

Re: runit SIGPWR support

El mar., 25 feb. 2020 a las 6:08, Jonathan de Boyne Pollard escribió: > > Laurent Bercot: > > 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? > > Yes. Also, I tested it :) I added an open2("/dev/tty0", O_RDONLY

Re: runit SIGPWR support

Laurent Bercot: 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? Yes. First: This is a kernel virtual terminal thing not a console thing. Strictly speaking, it is doing it wrongly to access it through the con

Re: runit SIGPWR support

Laurent Bercot: What piece of software sends SIGRTMIN+3 to pid 1 when you're not running systemd? * http://jdebp.uk./Softwares/nosh/guide/commands/system-control.xml#SYSTEMCONTROL (-:

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

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

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

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 an

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, nothi

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

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. Eve

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

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

Re: runit SIGPWR support

On 24.02.2020 02:53, Laurent Bercot wrote: s6 should also catch SIGWINCH (keyboard request) and let the user handle it via a hook executable if the signal exists btw. dunno if it already does so.  Both SIGPWR and SIGWINCH are caught in the latest s6 git head.  Release coming whenever real li

Re: runit SIGPWR support

have you ever used s6 as process #1 on any other platform than Linux ? i bet you have not even tried to do so on any of the BSDs. The BSDs are a different kind of beast: they're much more tightly integrated than your run-of-the-mill Linux distro, and you can't easily switch out one of the compon

Re: runit SIGPWR support

s6 should also catch SIGWINCH (keyboard request) and let the user handle it via a hook executable if the signal exists btw. dunno if it already does so. 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 act

Re: runit SIGPWR support

18.02.2020, 10:39, "Laurent Bercot" : > you're telling me that s6-svscan needs to understand SIGPWR in case the > kernel wants to signal a power failure, you actually have a good point, > and yes, I should implement SIGPWR support when this signal exists. BTW: have you ever used s6 as process #1

Re: runit SIGPWR support

18.02.2020, 10:39, "Laurent Bercot" : > An additional reason is that signaling init is not a casual operation; > instead it's part of a very limited API between the kernel and user > space, to be used in very controlled, exhaustively listed, situations. right. > Now, *as a separate conversation*,

Re: runit SIGPWR support

> Most init systems allow the SIGPWR behavior to be configured. > This includes Upstart, systemd, and my own "little init": > > https://gitlab.com/chinstrap/linit#configuration > > I provide a guide for using linit with runit here, but the process is > experimental: > > https://gitlab.com/chinstrap

Re: runit SIGPWR support

On Tue, Feb 18, 2020 at 09:39:14AM +, Laurent Bercot wrote: > In the former case, lxd *emulates* a kernel, and is supposed to adapt > to every kind of init that runs in a container, so it should follow > existing conventions and be able to adapt to every init. And that's > exactly why the lxc.s

Re: runit SIGPWR support

absolutely right, totally agreed. i also wondered why he refuses to add this. just catch and handle ALL possible signals, including the RT signals and leave it to the user how to react. In the github issue you linked, I explained my exact reasoning. An additional reason is that signaling init is

Re: runit SIGPWR support

On Fri, Feb 14, 2020 at 3:22 PM Steve Litt wrote: > > On Fri, 14 Feb 2020 05:18:33 -0800 > Cameron Nemo wrote: > > > On Fri, Feb 14, 2020 at 4:45 AM Steve Litt > > wrote: > > > > > > In my computer usage, I usually need about 5 minutes to gracefully > > > exit all my programs before powering dow

Re: runit SIGPWR support

17.02.2020, 11:00, "innerspacepilot" : > Just as a thought: You have implemented signal diversion, but limited to > known signals. Why not just pass unknown signals as numbers or something > like (S6SIG55011), so they can be diverted by user? You wouldn't have to > catalogue them. absolutely right

Re: runit SIGPWR support

17.02.2020, 15:45, "Jeff" : > what about SIGINT and SIGWINCH ? are they required by the POSIX > standard ? if not why does runit handle both ? oh no, i just saw that it "POSIX-correctly" ignores SIGWINCH ... the BSD kernels do not send SIGWINCH to process #1, so (ab)using it violates the POSIX sta

Re: runit SIGPWR support

12.02.2020, 22:54, "Colin Booth" : > far as I know SIGPWR is a Linux-specific signal so services that are > aiming for portability will either need to have special handling for > that in the linux case or need to ignore it. Ergo, runit (and all other > POSIX-compliant inits) currently have no speci

Re: runit SIGPWR support

14.02.2020, 13:29, "innerspacepilot" : > I would suggest it should be a graceful shutdown ( stopping all daemons, > syncing filesystems and stuff ) yes, of course, this should preceed the powerdown step. a more "correct" solution would be the approach taken by SysV init via the "powerfail" stanza

Re: runit SIGPWR support

Great, your point I wanted to hear especially. But, well, I am disillusioned with my hops for s6. My fault about SIGPWR, RTMIN+3 should be used instead, please, treat SIGPWR as a template for any other signal name, that doesn't matter. Not only me who want this "lxd simplicity", e.g. https://git

Re: runit SIGPWR support

Jeff: > > you should patch the code, runit is dead anyway. > try something along this lines in the source: > > #ifdef SIGPWR > /* handle that one */ > ... > #endif > > i can't see the problem, you have to patch the runit sources to > fulfil your requirements since that project is dead and th

Re: runit SIGPWR support

I don't generally question people that are this far above my weight class on a topic - but I'm pretty sure this [1] implies that pid 1 is not a requirement. Of course, you can run runsvdir directly under a different init. But that requires a bit of work: you now need to find another way to run y

Re: runit SIGPWR support

Good Day, On Fri, Feb 14, 2020 at 3:18 PM Laurent Bercot wrote: > >That's a win-win > > Lengthening the supervision tree in the container and using more RAM > just to save writing one line in a configuration file does not seem > like a win to me. > > ... Besides, runit will refuse to run if

Re: runit SIGPWR support

That's a win-win Lengthening the supervision tree in the container and using more RAM just to save writing one line in a configuration file does not seem like a win to me. ... Besides, runit will refuse to run if it's not pid 1, so that wouldn't work. -- Laurent

Re: runit SIGPWR support

Good Day, On Wed, Feb 12, 2020 at 6:26 AM innerspacepilot wrote: > > Why not just make runit systems run inside containers out of the box? > We are talking about one/two lines of code. > > The much better option here (in terms of playing well with others) would be this https://github.com/Yelp/d

Re: runit SIGPWR support

You mean that adding few lines of code in one place is worse than many users of many distros must configure their containers? I can configure that myself, but I don't want every user of runit driven container to walk this path. Is it necessary? As counterintuitive as it may seem at first glance,

Re: runit SIGPWR support

On Fri, Feb 14, 2020 at 05:06:40PM +0300, innerspacepilot wrote: > If you read it carefully, there is NO signal for shutdown. > Or lxd should also create file /etc/runit/stopit and set permissions for > that? Here runit provided a small machanism, and you also need a policy, like those from Void o

Re: runit SIGPWR support

Documentation says: " Signals runit only accepts signals in stage 2. If runit receives a CONT signal and the file /etc/runit/stopit exists and has the execute by owner permission set, runit is told to shutdown the system. if runit receives an INT signal, a ctrl-alt-del keyboard request is trigge

Re: runit SIGPWR support

On Fri, Feb 14, 2020 at 11:46:16AM +0100, Jeff wrote: > what should SIGPWR mean to a Linux init ? > i would suggest: halt and power down the system ASAP. Init signal semantics is already a mess: . When thinking of standardisation, we need to bewa

Re: runit SIGPWR support

On Fri, Feb 14, 2020 at 04:39:28PM +0300, innerspacepilot wrote: > You mean that adding few lines of code in one place is worse than many > users of many distros must configure their containers? > I can configure that myself, but I don't want every user of runit driven > container to walk this path

Re: runit SIGPWR support

On 14.02.2020 16:15, Casper Ti. Vector wrote: On Wed, Feb 12, 2020 at 05:25:56PM +0300, innerspacepilot wrote: Why not just make runit systems run inside containers out of the box? We are talking about one/two lines of code. Likewise `lxc.signal.halt' only needs one/two lines of code. It is al

Re: runit SIGPWR support

On Wed, Feb 12, 2020 at 05:25:56PM +0300, innerspacepilot wrote: > Why not just make runit systems run inside containers out of the box? > We are talking about one/two lines of code. Likewise `lxc.signal.halt' only needs one/two lines of code. It is also a interface with well-defined semantics.

Re: runit SIGPWR support

In my computer usage, I usually need about 5 minutes to gracefully exit all my programs before powering down the computer, and I have a 40 minute UPS. If this is done at all, I'd suggest a configurable amount of time, with a visible countdown, telling the user to get his or her affairs in order, an

Re: runit SIGPWR support

On Fri, 14 Feb 2020 10:38:38 +0100 Jeff wrote: > 12.02.2020, 22:54, "Colin Booth" : > > On Wed, Feb 12, 2020 at 05:25:56PM +0300, innerspacepilot wrote: > >>  Why not just make runit systems run inside containers out of the > >> box? We are talking about one/two lines of code. > > you should

Re: runit SIGPWR support

I would suggest it should be a graceful shutdown ( stopping all daemons, syncing filesystems and stuff ) On 14.02.2020 13:46, Jeff wrote: 12.02.2020, 22:54, "Colin Booth" : I wasn't trying to be hostile, apologies if it came across that way. As far as I know SIGPWR is a Linux-specific signal s

Re: runit SIGPWR support

12.02.2020, 22:54, "Colin Booth" : > I wasn't trying to be hostile, apologies if it came across that way. As > far as I know SIGPWR is a Linux-specific signal so services that are > aiming for portability will either need to have special handling for > that in the linux case or need to ignore it. E

Re: runit SIGPWR support

12.02.2020, 22:54, "Colin Booth" : > I wasn't trying to be hostile, apologies if it came across that way. As > far as I know SIGPWR is a Linux-specific signal so services that are this is a SysV signal that is sent in case of power suply problems. it has no special meaning per se and can be (ab)us

Re: runit SIGPWR support

12.02.2020, 22:54, "Colin Booth" : > On Wed, Feb 12, 2020 at 05:25:56PM +0300, innerspacepilot wrote: >>  Why not just make runit systems run inside containers out of the box? >>  We are talking about one/two lines of code. you should patch the code, runit is dead anyway. try something along this

Re: runit SIGPWR support

Yes Colin, you're right. PWR is not in the FreeBSD list of signals, per # kill -l HUP INT QUIT ILL TRAP ABRT EMT FPE KILL BUS SEGV SYS PIPE ALRM TERM URG STOP TSTP CONT CHLD TTIN TTOU IO XCPU XFSZ VTALRM PROF WINCH INFO USR1 USR2 LWP Also doesn't appear in Open Group Base Specifications Issue 7 l

Re: runit SIGPWR support

On Wed, Feb 12, 2020 at 05:25:56PM +0300, innerspacepilot wrote: > > Why not just make runit systems run inside containers out of the box? > We are talking about one/two lines of code. > > Why can't we be just a little bit more friendly to each other? > > Thanks. > I wasn't trying to be hostile

Re: runit SIGPWR support

Why not just make runit systems run inside containers out of the box? We are talking about one/two lines of code. Why can't we be just a little bit more friendly to each other? Thanks. On 31.01.2020 07:39, Colin Booth wrote: On Thu, Jan 23, 2020 at 11:44:12PM +0300, innerspacepilot wrote:

Re: runit SIGPWR support

On Thu, Jan 23, 2020 at 11:44:12PM +0300, innerspacepilot wrote: > Hello! > > Would you please implement handling of SIGPWR in runit's init to make > LXD containers shut down properly. > More info here https://github.com/lxc/lxd/issues/1183 > What keeps you from updating lxc.signal.halt and using

runit SIGPWR support

Hello! Would you please implement handling of SIGPWR in runit's init to make LXD containers shut down properly. More info here https://github.com/lxc/lxd/issues/1183 Thank you.