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 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, and also a way to cancel the shutdown.
> > >
> > > The only reason I see to have the computer automatically power down
> > > when signaled by the UPS is that I might not be home, but in that
> > > case waiting 5 minutes wouldn't matter.
> >
> > 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/linit/-/blob/master/README.runit.md
> >
> > Linit is packaged in Void Linux, and void images are available for
> > LXD. Lastly I want to mention that lxc.signal.halt is not available
> > with LXD.
> >
> > Regards,
> > --
> > Cameron Nemo
>
> Hi Cameron,
>
> I'm very impressed with linit. In my 20 minute perusal it looks quite a
> bit like Suckess Init, which I like. On line 54 you have
> int linit_spawn(char * restrict path) {
>
> Is path the path to the rc file that linit forks off? I've never seen
> char * restrict before: What does "restrict" mean?
I use the term hook, which could refer to /boot, /sigpwr, or /sigint.
Roughly equivalent to an rc file.
restrict keyword is described here:
https://en.wikipedia.org/wiki/Restrict
https://stackoverflow.com/questions/745870/realistic-usage-of-the-c99-restrict-keyword
It is probably not useful in this case, but the posix_spawn API
specifies it so I used it.
>
> I notice linit responds only to a couple signals, whereas Suckless
> Init responds to:
> { SIGUSR1, sigpoweroff },
> { SIGCHLD, sigreap },
> { SIGALRM, sigreap },
> { SIGINT, sigreboot },
> { SIGILL, sigillhandle},
>
SIGUSR1: I am unaware of any linux tools which use that signal. I used
SIGPWR specifically for compat with UPS tools and lxc/lxd.
SIGCHLD: linit actually ignores this signal, which reaps the child.
SIGALRM: because childs are implicitly reaped, there is no reason to
include a tick from what I can tell. (i.e. this case never happens:
https://git.suckless.org/sinit/commit/170d599d58efee6c9be675a85c6e435d68e8a2de.html)
SIGINT: same behavior as sinit here.
SIGILL: you must have added that. I would be curious to know why.
> Actually, I think I might have put one of those in, but I don't think
> you respond to most of them: Is there a reason?
>
> Anyway, I kind of like your linit PID1.
Thanks.
The only real novel details are that:
- it calls pause() in the main loop
- uses posix_spawn() to exec from signal handlers in a thread safe manner
> Steve
Regards,
Cameron
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, 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. > We need good, flexible and user-friendly init alternatives for linux. right. >> But even if your containers were using s6, which has a well-defined >> upstream (me) and which does not understand SIGPWR either, I would not >> apply your patch suggestion. Why? Because SIGPWR is not standardized, >> and s6 aims to be portable, it works ootb on other systems than Linux >> and making it use SIGPWR would endanger that. It's the exact kind of >> problems you haven't thought of but run into when you want to patch >> software, and makes patching always more complex than it seems from the >> outside. sorry Laurent, this is absolutely ridicolous. we are talking about using s6 as Linux process #1, so it should catch, handle and react to all possible signals the kernel may send to said process, there might be a good reason for it, same for any other possible platform, be it BSD or SysV unices. this is inherently unportable per se. there exists no POSIX standard describing the signals a kernel may send to notify process #1 about certain events.
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 standard, rite ?
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 special handling around SIGPWR > as they don't understand what it is. what about SIGINT and SIGWINCH ? are they required by the POSIX standard ? if not why does runit handle both ?
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 for the "real" process #1 (not those running in containers/other process namespaces). it starts a subprocess to handle the situation, i. e. see if power returns and shutdown ASAP if not. there is no excuse for a Linux process #1 to ignore SIGPWR anyway since that signal is sent by the kernel in powerfail situations (Linux and System V unices), it also makes sense to abuse it to shutdown a container, so i cannot understand why runit just ignores it.
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://github.com/skarnet/s6/issues/5, where you fully described your position. 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. We need good, flexible and user-friendly init alternatives for linux (other systems have their own). So, I just want to make user experience of new runit or s6 users who use LXD more comfortable, apologies if this hurts someone. Have a good day! On 14.02.2020 21:30, Laurent Bercot 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. Is it necessary? As counterintuitive as it may seem at first glance, the answers to your questions are yes and yes. Patching software is always more complex than configuring it. Configuring software is using an API that has been especially thought out to accommodate the needs of various users; if a piece of software does what you want but requires you to tweak a configuration lever, then it does what you want period. Because your needing to tweak the configuration lever is *the exact reason why that lever is there*. If you refuse to use it, you are basically putting your needs in front of everyone else's, and demanding that the author of the software adapt to you at the exclusion of others, instead of using the mechanism that has been prepared for you. Patching software: - requires communication with upstream, so, takes support resources - requires new deployment, which is significant effort - is dangerous: it may introduce bugs that you haven't thought of - may change the workflow of other users It is, of course, a supplementary order of magnitude more difficult with software that has no well-defined upstream, as is the case with runit these days. But even if your containers were using s6, which has a well-defined upstream (me) and which does not understand SIGPWR either, I would not apply your patch suggestion. Why? Because SIGPWR is not standardized, and s6 aims to be portable, it works ootb on other systems than Linux and making it use SIGPWR would endanger that. It's the exact kind of problems you haven't thought of but run into when you want to patch software, and makes patching always more complex than it seems from the outside. Explaining to users how to configure lxc to send the correct signal to the init system running in the container is a matter of one line in the documentation. It's extremely manageable. Also there is a huge lack of documentation about it on the net, especially on signals that runit accepts. You are talking about patching the code, and you're not going to look at runit's code to see what signals it accepts? ;) It adds complexity to users, and that means users will choose other distros which just work. If your definition of "just working" is "everything is working with the default configuration", then I don't think you'll find a single Linux distribution that "just works". Your runit distro is working just as well as any other. You just need to set one variable in the lxc configuration. It's certainly not the only variable you need to set; it's certainly not even the only variable you need to set conditionally depending on the guest distro. So, there's really no reason to get hung up on this. Why can't we be just a little bit more friendly to each other? Most participants in this thread would benefit from taking this advice to heart. And in your case, the friendliness will consist in using the configuration levers that were made for you instead of demanding that upstream change its defaults to adapt to you. -- Laurent
