Re: runit SIGPWR support

2020-04-14 Thread Maxim Vetsalo
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

Re: runit SIGPWR support

2020-03-16 Thread Laurent Bercot
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.

Re: runit SIGPWR support

2020-03-16 Thread Jeff
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

Re: runit SIGPWR support

2020-03-16 Thread Jeff
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

Re: runit SIGPWR support

2020-03-16 Thread Jeff
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

Re: runit SIGPWR support

2020-03-06 Thread innerspacepilot
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

Re: runit SIGPWR support

2020-03-06 Thread innerspacepilot
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

2020-02-29 Thread Guillermo
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

2020-02-29 Thread Jonathan de Boyne Pollard
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 Unix System 5 books it is conventionally

Re: runit SIGPWR support

2020-02-28 Thread fungal-net
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

Re: runit SIGPWR support

2020-02-28 Thread Alex Suykov
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

Re: runit SIGPWR support

2020-02-27 Thread Jan Braun
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

Re: runit SIGPWR support

2020-02-26 Thread innerspacepilot
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

Re: runit SIGPWR support

2020-02-25 Thread Guillermo
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",

Re: runit SIGPWR support

2020-02-25 Thread Jonathan de Boyne Pollard
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

Re: runit SIGPWR support

2020-02-25 Thread Jonathan de Boyne Pollard
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

2020-02-24 Thread Laurent Bercot
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

2020-02-24 Thread Guillermo
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

2020-02-24 Thread Guillermo
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

Re: runit SIGPWR support

2020-02-24 Thread 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. 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

2020-02-24 Thread Laurent Bercot
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

2020-02-24 Thread Guillermo
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

Re: runit SIGPWR support

2020-02-24 Thread Laurent Bercot
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,

Re: runit SIGPWR support

2020-02-24 Thread Serge E. Hallyn
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 > > >

Re: runit SIGPWR support

2020-02-24 Thread innerspacepilot
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.

Re: runit SIGPWR support

2020-02-24 Thread Jeff
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,

Re: runit SIGPWR support

2020-02-24 Thread Laurent Bercot
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

2020-02-23 Thread innerspacepilot
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

Re: runit SIGPWR support

2020-02-23 Thread Laurent Bercot
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

Re: runit SIGPWR support

2020-02-23 Thread Laurent Bercot
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

Re: runit SIGPWR support

2020-02-23 Thread Jeff
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

2020-02-23 Thread Jeff
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

Re: runit SIGPWR support

2020-02-23 Thread Jeff
> 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: > >

Re: runit SIGPWR support

2020-02-20 Thread Serge E. Hallyn
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

Re: runit SIGPWR support

2020-02-18 Thread Laurent Bercot
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

Re: runit SIGPWR support

2020-02-17 Thread Cameron Nemo
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

Re: runit SIGPWR support

2020-02-17 Thread Jeff
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

Re: runit SIGPWR support

2020-02-17 Thread Jeff
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

Re: runit SIGPWR support

2020-02-17 Thread Jeff
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

Re: runit SIGPWR support

2020-02-17 Thread Jeff
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"

Re: runit SIGPWR support

2020-02-17 Thread innerspacepilot
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.

Re: runit SIGPWR support

2020-02-15 Thread fungal-net
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

Re: runit SIGPWR support

2020-02-14 Thread Laurent Bercot
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

Re: runit SIGPWR support

2020-02-14 Thread John W Higgins
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

2020-02-14 Thread Laurent Bercot
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

2020-02-14 Thread John W Higgins
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

Re: runit SIGPWR support

2020-02-14 Thread Laurent Bercot
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

Re: runit SIGPWR support

2020-02-14 Thread Casper Ti. Vector
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

Re: runit SIGPWR support

2020-02-14 Thread innerspacepilot
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

Re: runit SIGPWR support

2020-02-14 Thread Casper Ti. Vector
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

Re: runit SIGPWR support

2020-02-14 Thread Casper Ti. Vector
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

Re: runit SIGPWR support

2020-02-14 Thread innerspacepilot
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

Re: runit SIGPWR support

2020-02-14 Thread Casper Ti. Vector
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

2020-02-14 Thread Steve Litt
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,

Re: runit SIGPWR support

2020-02-14 Thread Steve Litt
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

Re: runit SIGPWR support

2020-02-14 Thread innerspacepilot
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

Re: runit SIGPWR support

2020-02-14 Thread Jeff
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.

Re: runit SIGPWR support

2020-02-14 Thread Jeff
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

Re: runit SIGPWR support

2020-02-14 Thread Jeff
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

2020-02-12 Thread Dewayne Geraghty
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

Re: runit SIGPWR support

2020-02-12 Thread 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. > > Why can't we be just a little bit more friendly to each other? > > Thanks. > I wasn't trying to be

Re: runit SIGPWR support

2020-02-12 Thread innerspacepilot
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

2020-01-30 Thread Colin Booth
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

runit SIGPWR support

2020-01-23 Thread innerspacepilot
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.