supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
* runit SIGPWR support
@ 2020-01-23 20:44 innerspacepilot
  2020-01-31  4:39 ` Colin Booth
  0 siblings, 1 reply; 64+ messages in thread
From: innerspacepilot @ 2020-01-23 20:44 UTC (permalink / raw)
  To: supervision

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.




^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-01-23 20:44 innerspacepilot
@ 2020-01-31  4:39 ` Colin Booth
  0 siblings, 0 replies; 64+ messages in thread
From: Colin Booth @ 2020-01-31  4:39 UTC (permalink / raw)
  To: supervision

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 a signal that
runit already understands? 
-- 
Colin Booth


^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
       [not found] <1beb6e35-d4be-60b8-fc52-af666c4fffe3@gmx.com>
@ 2020-02-12 14:25 ` innerspacepilot
  2020-02-12 21:54   ` Colin Booth
                     ` (2 more replies)
  0 siblings, 3 replies; 64+ messages in thread
From: innerspacepilot @ 2020-02-12 14:25 UTC (permalink / raw)
  To: supervision


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:
>> 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 a signal that
> runit already understands?




^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-12 14:25 ` runit SIGPWR support innerspacepilot
@ 2020-02-12 21:54   ` Colin Booth
  2020-02-12 22:16     ` Dewayne Geraghty
                       ` (4 more replies)
  2020-02-14 13:15   ` Casper Ti. Vector
  2020-02-14 19:08   ` John W Higgins
  2 siblings, 5 replies; 64+ messages in thread
From: Colin Booth @ 2020-02-12 21:54 UTC (permalink / raw)
  To: supervision

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, 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. Ergo, runit (and all other
POSIX-compliant inits) currently have no special handling around SIGPWR
as they don't understand what it is. 

Is this the right behavior? I don't know. Something like SIGPWR as an
alerting mechanism when you're switched to UPS battery is pretty nice in
a general case but using that as your container shutdown solution
isolates you into a very SysV-specific world. Overriding the default via
lxc.signal.halt will allow you to modify what you send to something that
is within the POSIX spec and allow you to trigger shutdowns the "right"
way. It's a little lame but it is portable, and LXC using a non-portable
signal is a little bit of a bummer.

-- 
Colin Booth


^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-12 21:54   ` Colin Booth
@ 2020-02-12 22:16     ` Dewayne Geraghty
  2020-02-14  9:38     ` Jeff
                       ` (3 subsequent siblings)
  4 siblings, 0 replies; 64+ messages in thread
From: Dewayne Geraghty @ 2020-02-12 22:16 UTC (permalink / raw)
  To: supervision

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 list of
signals https://pubs.opengroup.org/onlinepubs/9699919799/
Cheerio.


^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-12 21:54   ` Colin Booth
  2020-02-12 22:16     ` Dewayne Geraghty
@ 2020-02-14  9:38     ` Jeff
  2020-02-14 12:38       ` Steve Litt
  2020-02-15 10:47       ` fungal-net
  2020-02-14 10:08     ` Jeff
                       ` (2 subsequent siblings)
  4 siblings, 2 replies; 64+ messages in thread
From: Jeff @ 2020-02-14  9:38 UTC (permalink / raw)
  To: supervision

12.02.2020, 22:54, "Colin Booth" <colin@heliocat.net>:
> 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 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 the code
is not maintained anymore.

>>  Why can't we be just a little bit more friendly to each other?

that would be indeed helpful.

> 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. Ergo, runit (and all other
> POSIX-compliant inits) currently have no special handling around SIGPWR
> as they don't understand what it is.
>
> Is this the right behavior? I don't know. Something like SIGPWR as an
> alerting mechanism when you're switched to UPS battery is pretty nice in
> a general case but using that as your container shutdown solution
> isolates you into a very SysV-specific world. Overriding the default via
> lxc.signal.halt will allow you to modify what you send to something that
> is within the POSIX spec and allow you to trigger shutdowns the "right"
> way. It's a little lame but it is portable, and LXC using a non-portable
> signal is a little bit of a bummer.

just BS. adding a bit of handler code for SIGPWR is no big deal,
please stop your lamento, it's so boring.



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-12 21:54   ` Colin Booth
  2020-02-12 22:16     ` Dewayne Geraghty
  2020-02-14  9:38     ` Jeff
@ 2020-02-14 10:08     ` Jeff
  2020-02-14 10:46     ` Jeff
  2020-02-17 14:45     ` Jeff
  4 siblings, 0 replies; 64+ messages in thread
From: Jeff @ 2020-02-14 10:08 UTC (permalink / raw)
  To: supervision

12.02.2020, 22:54, "Colin Booth" <colin@heliocat.net>:
> 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)used for everything
the coder sees fit.

is the abuse of SIGTSP in BSD init "POSIX-compliant" or even necessary ?
certainly not.

> 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 is a "POSIX-compliant init" btw ?

> Is this the right behavior? I don't know.

yes. what should power suply problems mean to container ?

> Something like SIGPWR as an
> alerting mechanism when you're switched to UPS battery is pretty nice in
> a general case but using that as your container shutdown solution
> isolates you into a very SysV-specific world.

BS. Linux provides this signal so you can (ab)use it for anything
you wish.

> Overriding the default via
> lxc.signal.halt will allow you to modify what you send to something that
> is within the POSIX spec and allow you to trigger shutdowns the "right"
> way. It's a little lame but it is portable, and LXC using a non-portable
> signal is a little bit of a bummer.

why "fix" LXC when adding handler code for SIGPWR to runit is not
much of a deal:

#ifdef SIGPWR
  /* handle it analogous to SIGTERM or else */
#endif

this is also very portable to systems that do not provide SIGPWR.

not in any way, the signal is portable between Linux and SysV unices.
it is a good idea to use it since it is rarely used for anything, another
solution could be usage of real time signals.



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-12 21:54   ` Colin Booth
                       ` (2 preceding siblings ...)
  2020-02-14 10:08     ` Jeff
@ 2020-02-14 10:46     ` Jeff
  2020-02-14 12:29       ` innerspacepilot
  2020-02-14 14:02       ` Casper Ti. Vector
  2020-02-17 14:45     ` Jeff
  4 siblings, 2 replies; 64+ messages in thread
From: Jeff @ 2020-02-14 10:46 UTC (permalink / raw)
  To: super

12.02.2020, 22:54, "Colin Booth" <colin@heliocat.net>:
> 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. Ergo, runit (and all other
> POSIX-compliant inits) currently have no special handling around SIGPWR
> as they don't understand what it is.

what should SIGPWR mean to a Linux init ?
i would suggest: halt and power down the system ASAP.



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-14 10:46     ` Jeff
@ 2020-02-14 12:29       ` innerspacepilot
  2020-02-14 12:45         ` Steve Litt
  2020-02-17 14:39         ` Jeff
  2020-02-14 14:02       ` Casper Ti. Vector
  1 sibling, 2 replies; 64+ messages in thread
From: innerspacepilot @ 2020-02-14 12:29 UTC (permalink / raw)
  To: supervision

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" <colin@heliocat.net>:
>> 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. Ergo, runit (and all other
>> POSIX-compliant inits) currently have no special handling around SIGPWR
>> as they don't understand what it is.
> what should SIGPWR mean to a Linux init ?
> i would suggest: halt and power down the system ASAP.
>



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-14  9:38     ` Jeff
@ 2020-02-14 12:38       ` Steve Litt
  2020-02-15 10:47       ` fungal-net
  1 sibling, 0 replies; 64+ messages in thread
From: Steve Litt @ 2020-02-14 12:38 UTC (permalink / raw)
  To: supervision

On Fri, 14 Feb 2020 10:38:38 +0100
Jeff <sysinit@yandex.com> wrote:

> 12.02.2020, 22:54, "Colin Booth" <colin@heliocat.net>:
> > 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.

Oh really. No chance that Gerrit has simply taken a year or two off?
Why are you using software you consider dead? Why not move to s6 if
runit is dead?

> try something along this lines in the source:
> 
> #ifdef SIGPWR
>   /* handle that one */
>   ...
> #endif

If it's that simple, why don't YOU do it? Someone already mentioned
that BSD doesn't have this signal, so incorporating it in the wider
project could be objected to by some people as non-portable. So why
don't YOU make this change on YOUR copy?

> 
> i can't see the problem, you have to patch the runit sources to
> fulfil your requirements since that project is dead and the code
> is not maintained anymore.
> 
> >>  Why can't we be just a little bit more friendly to each other?  
> 
> that would be indeed helpful.

And you can start by not calling a project "dead".

> 
> > 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. Ergo,
> > runit (and all other POSIX-compliant inits) currently have no
> > special handling around SIGPWR as they don't understand what it is.
> >
> > Is this the right behavior? I don't know. Something like SIGPWR as
> > an alerting mechanism when you're switched to UPS battery is pretty
> > nice in a general case but using that as your container shutdown
> > solution isolates you into a very SysV-specific world. Overriding
> > the default via lxc.signal.halt will allow you to modify what you
> > send to something that is within the POSIX spec and allow you to
> > trigger shutdowns the "right" way. It's a little lame but it is
> > portable, and LXC using a non-portable signal is a little bit of a
> > bummer.  
> 
> just BS. adding a bit of handler code for SIGPWR is no big deal,
> please stop your lamento, it's so boring.

I guess your resolution to be a little bit more friendly to each other
didn't last too long.

You're one guy who wants this change. You have many alternatives:

* s6
* lxc.signal.halt
* Patch runit yourself

Everyone else: Just to express my opinion: I use runit every day and
personally have no need to have it react to SIGPWR.

SteveT

Steve Litt 
February 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive


^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-14 12:29       ` innerspacepilot
@ 2020-02-14 12:45         ` Steve Litt
       [not found]           ` <CALZWFRLvtofWfP4kzxJ8_8_K3nzebPjCR-NsJ2MU22cSuaOLng@mail.gmail.com>
  2020-02-17 14:39         ` Jeff
  1 sibling, 1 reply; 64+ messages in thread
From: Steve Litt @ 2020-02-14 12:45 UTC (permalink / raw)
  To: supervision

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.

By the way, how would this be handled on a laptop, whose core usage
includes unplugged usage? Maybe by monitoring when the battery gets too
low?

SteveT

Steve Litt 
February 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive


On Fri, 14 Feb 2020 15:29:49 +0300
innerspacepilot <innerspacepilot@gmx.com> wrote:

> 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" <colin@heliocat.net>:  
> >> 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.
> >> Ergo, runit (and all other POSIX-compliant inits) currently have
> >> no special handling around SIGPWR as they don't understand what it
> >> is.  
> > what should SIGPWR mean to a Linux init ?
> > i would suggest: halt and power down the system ASAP.
> >  
> 



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-12 14:25 ` runit SIGPWR support innerspacepilot
  2020-02-12 21:54   ` Colin Booth
@ 2020-02-14 13:15   ` Casper Ti. Vector
  2020-02-14 13:39     ` innerspacepilot
  2020-02-14 19:08   ` John W Higgins
  2 siblings, 1 reply; 64+ messages in thread
From: Casper Ti. Vector @ 2020-02-14 13:15 UTC (permalink / raw)
  To: supervision

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.  Modifying runit source code
touches the implementation, with all the potential coupling between
modules and/or between submodules.  So the increase in total complexity
of the system is almost certainly smaller when using `lxc.signal.halt'.

> Why can't we be just a little bit more friendly to each other?

Let's see some more examples.  Some daemons (eg. mysqld and php-fpm)
use a signal other than SIGTERM for graceful shutdown, and s6 uses a
`down-signal' file (similar to `lxc.signal.halt') for these daemons.
Instead of modifying the daemons, we configure s6 specially; likewise,
here I would definitely prefer `lxc.signal.halt'.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-14 13:15   ` Casper Ti. Vector
@ 2020-02-14 13:39     ` innerspacepilot
  2020-02-14 13:57       ` Casper Ti. Vector
  2020-02-14 18:30       ` Laurent Bercot
  0 siblings, 2 replies; 64+ messages in thread
From: innerspacepilot @ 2020-02-14 13:39 UTC (permalink / raw)
  To: supervision

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 also
> a interface with well-defined semantics.  Modifying runit source code
> touches the implementation, with all the potential coupling between
> modules and/or between submodules.  So the increase in total complexity
> of the system is almost certainly smaller when using `lxc.signal.halt'.

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?
Also there is a huge lack of documentation about it on the net,
especially on signals that runit accepts.

It adds complexity to users, and that means users will choose other
distros which just work.


>
>> Why can't we be just a little bit more friendly to each other?
> Let's see some more examples.  Some daemons (eg. mysqld and php-fpm)
> use a signal other than SIGTERM for graceful shutdown, and s6 uses a
> `down-signal' file (similar to `lxc.signal.halt') for these daemons.
> Instead of modifying the daemons, we configure s6 specially; likewise,
> here I would definitely prefer `lxc.signal.halt'.
>



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-14 13:39     ` innerspacepilot
@ 2020-02-14 13:57       ` Casper Ti. Vector
  2020-02-14 14:06         ` innerspacepilot
  2020-02-14 18:30       ` Laurent Bercot
  1 sibling, 1 reply; 64+ messages in thread
From: Casper Ti. Vector @ 2020-02-14 13:57 UTC (permalink / raw)
  To: supervision

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. Is it necessary?
> It adds complexity to users, and that means users will choose other
> distros which just work.

The burden is just a few lines of code anyway, and user only need to
learn it once.  It is also easily doable with some templating mechanism.

> Also there is a huge lack of documentation about it on the net,
> especially on signals that runit accepts.

<http://smarden.org/runit/runit.8.html>.
Took me less than one minute.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-14 10:46     ` Jeff
  2020-02-14 12:29       ` innerspacepilot
@ 2020-02-14 14:02       ` Casper Ti. Vector
  1 sibling, 0 replies; 64+ messages in thread
From: Casper Ti. Vector @ 2020-02-14 14:02 UTC (permalink / raw)
  To: supervision

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:
<https://skarnet.org/cgi-bin/archive.cgi?2:mss:1377>.
When thinking of standardisation, we need to beware of this:
<https://xkcd.com/927/>.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-14 13:57       ` Casper Ti. Vector
@ 2020-02-14 14:06         ` innerspacepilot
  2020-02-14 14:25           ` Casper Ti. Vector
  0 siblings, 1 reply; 64+ messages in thread
From: innerspacepilot @ 2020-02-14 14:06 UTC (permalink / raw)
  To: supervision

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

"

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?

Also what complexity you are talking about? runit.c is only 346 lines long.



On 14.02.2020 16:57, Casper Ti. Vector wrote:
> 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. Is it necessary?
>> It adds complexity to users, and that means users will choose other
>> distros which just work.
> The burden is just a few lines of code anyway, and user only need to
> learn it once.  It is also easily doable with some templating mechanism.
>
>> Also there is a huge lack of documentation about it on the net,
>> especially on signals that runit accepts.
> <http://smarden.org/runit/runit.8.html>.
> Took me less than one minute.
>



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-14 14:06         ` innerspacepilot
@ 2020-02-14 14:25           ` Casper Ti. Vector
  0 siblings, 0 replies; 64+ messages in thread
From: Casper Ti. Vector @ 2020-02-14 14:25 UTC (permalink / raw)
  To: supervision

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 or Gentoo.  Someone can provide a container template
with a given policy, and then the user does not need to care about
creating it by himself.  The same goes for many other init systems.

> Also what complexity you are talking about? runit.c is only 346 lines long.

Note the word "coupling" I used:
<https://en.wikipedia.org/wiki/Coupling_(computer_programming)>.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-14 13:39     ` innerspacepilot
  2020-02-14 13:57       ` Casper Ti. Vector
@ 2020-02-14 18:30       ` Laurent Bercot
  2020-02-17 10:00         ` innerspacepilot
  1 sibling, 1 reply; 64+ messages in thread
From: Laurent Bercot @ 2020-02-14 18:30 UTC (permalink / raw)
  To: innerspacepilot, supervision

>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



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-12 14:25 ` runit SIGPWR support innerspacepilot
  2020-02-12 21:54   ` Colin Booth
  2020-02-14 13:15   ` Casper Ti. Vector
@ 2020-02-14 19:08   ` John W Higgins
  2020-02-14 23:18     ` Laurent Bercot
  2 siblings, 1 reply; 64+ messages in thread
From: John W Higgins @ 2020-02-14 19:08 UTC (permalink / raw)
  To: supervision

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

Good Day,

On Wed, Feb 12, 2020 at 6:26 AM innerspacepilot <innerspacepilot@gmx.com>
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/dumb-init

A very small pid 1 that sits just on top of your now pid 2 runit and will
rewrite signals for you [1] so that SIGPWR magically becomes SIGTERM for
runit. No modification to either side.

That's a win-win

John W Higgins

[1] - https://github.com/Yelp/dumb-init#signal-rewriting

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-14 19:08   ` John W Higgins
@ 2020-02-14 23:18     ` Laurent Bercot
  2020-02-14 23:38       ` John W Higgins
  0 siblings, 1 reply; 64+ messages in thread
From: Laurent Bercot @ 2020-02-14 23:18 UTC (permalink / raw)
  To: John W Higgins, supervision

>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



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-14 23:18     ` Laurent Bercot
@ 2020-02-14 23:38       ` John W Higgins
  2020-02-15  2:15         ` Laurent Bercot
  0 siblings, 1 reply; 64+ messages in thread
From: John W Higgins @ 2020-02-14 23:38 UTC (permalink / raw)
  To: supervision

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

Good Day,

On Fri, Feb 14, 2020 at 3:18 PM Laurent Bercot <ska-supervision@skarnet.org>
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 it's not pid 1, so that
> wouldn't work.
>
>
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.

I'm also confused why my suggestion would be put down so harshly outside of
the possible pid 1 issue.

If one doesn't want to require a user of their lxc image to modify the
config - but wants to use runit - what I suggested certainly would fit that
core requirement. I made no suggestion that it was perfect - but it was an
option for someone that views the reality of changing a line in a config
file differently than I would.

I have a boat load of issues with things that I work with that consume way
more time than should be necessary. I also happened to remember having seen
an init that allowed signal remapping in the past.

This smallest amount of empathy for a fellow bike shed painter meant that I
offered up what I remembered.

My apologies for the noise.

John W Higgins

[1] - http://smarden.org/runit/useinit.html

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-14 23:38       ` John W Higgins
@ 2020-02-15  2:15         ` Laurent Bercot
  0 siblings, 0 replies; 64+ messages in thread
From: Laurent Bercot @ 2020-02-15  2:15 UTC (permalink / raw)
  To: John W Higgins, supervision

>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
your stage 1, and also your stage 3 when shutting down the container.
Stages 1 and 3 are an integral part of using runit as an init system
instead of just a supervision mechanism (which the runsvdir invocation
in stage 2 is), so if you can't run them because you can't run the
runit binary because it's not pid 1, you need to work around that. And
it's not entirely trivial; to accomplish something similar in s6, I had
to write a whole specific package, s6-linux-init.

innerspacepilot wants to use runit with the least possible amount of
effort, so rewriting a significant portion of the init sequence doesn't
sound like a good match. ;)


>I'm also confused why my suggestion would be put down so harshly outside of
>the possible pid 1 issue.

Sorry if I appeared hostile, that was not my intention; I tend to be
blunt and terse when something seems obvious to me. I just wanted to
stress that any alternative solution to changing the lxc config will
be more costly, one way or another.

--
Laurent



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-14  9:38     ` Jeff
  2020-02-14 12:38       ` Steve Litt
@ 2020-02-15 10:47       ` fungal-net
  1 sibling, 0 replies; 64+ messages in thread
From: fungal-net @ 2020-02-15 10:47 UTC (permalink / raw)
  To: supervision

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 the code
> is not maintained anymore.

As far as void is concerned runit is alive and well.  They also have
many scripts written to make power tasks simple like sleep called zzz

Artix has runit scripts for apcupsd, if that helps any.


^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-14 18:30       ` Laurent Bercot
@ 2020-02-17 10:00         ` innerspacepilot
  2020-02-17 15:13           ` Jeff
  0 siblings, 1 reply; 64+ messages in thread
From: innerspacepilot @ 2020-02-17 10:00 UTC (permalink / raw)
  To: Laurent Bercot, supervision

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
>



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-14 12:29       ` innerspacepilot
  2020-02-14 12:45         ` Steve Litt
@ 2020-02-17 14:39         ` Jeff
  1 sibling, 0 replies; 64+ messages in thread
From: Jeff @ 2020-02-17 14:39 UTC (permalink / raw)
  To: supervision

14.02.2020, 13:29, "innerspacepilot" <innerspacepilot@gmx.com>:
> 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.



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-12 21:54   ` Colin Booth
                       ` (3 preceding siblings ...)
  2020-02-14 10:46     ` Jeff
@ 2020-02-17 14:45     ` Jeff
  2020-02-17 14:50       ` Jeff
  4 siblings, 1 reply; 64+ messages in thread
From: Jeff @ 2020-02-17 14:45 UTC (permalink / raw)
  To: supervision

12.02.2020, 22:54, "Colin Booth" <colin@heliocat.net>:
> 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 ?


^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-17 14:45     ` Jeff
@ 2020-02-17 14:50       ` Jeff
  0 siblings, 0 replies; 64+ messages in thread
From: Jeff @ 2020-02-17 14:50 UTC (permalink / raw)
  To: supervision

17.02.2020, 15:45, "Jeff" <sysinit@yandex.com>:
> 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 ?


^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-17 10:00         ` innerspacepilot
@ 2020-02-17 15:13           ` Jeff
  2020-02-18  9:39             ` Laurent Bercot
  0 siblings, 1 reply; 64+ messages in thread
From: Jeff @ 2020-02-17 15:13 UTC (permalink / raw)
  To: supervision

17.02.2020, 11:00, "innerspacepilot" <innerspacepilot@gmx.com>:
> 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.



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
       [not found]             ` <20200214182241.15614126@mydesk.domain.cxm>
@ 2020-02-17 19:46               ` Cameron Nemo
  2020-02-23 16:11                 ` Jeff
  0 siblings, 1 reply; 64+ messages in thread
From: Cameron Nemo @ 2020-02-17 19:46 UTC (permalink / raw)
  To: Steve Litt; +Cc: supervision

On Fri, Feb 14, 2020 at 3:22 PM Steve Litt <slitt@troubleshooters.com> wrote:
>
> On Fri, 14 Feb 2020 05:18:33 -0800
> Cameron Nemo <camerontnorman@gmail.com> wrote:
>
> > On Fri, Feb 14, 2020 at 4:45 AM Steve Litt
> > <slitt@troubleshooters.com> 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


^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-17 15:13           ` Jeff
@ 2020-02-18  9:39             ` Laurent Bercot
  2020-02-20 20:39               ` Serge E. Hallyn
                                 ` (2 more replies)
  0 siblings, 3 replies; 64+ messages in thread
From: Laurent Bercot @ 2020-02-18  9:39 UTC (permalink / raw)
  To: supervision

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


>sorry Laurent, this is absolutely ridicolous.
>we are talking about using s6 as Linux process #1

No, that's not what we were talking about. We were talking about using
runit as pid 1 in a container. I just used s6 and SIGPWR-as-sent-by-lxd
as an illustration of why patching software is always more complicated
than using configuration switches. And I stand by my point.

Now, *as a separate conversation*, you can say that s6-svscan should
be able to handle every signal that the kernel can throw at it, no
matter how unportable. And it is a reasonable request: there are good
arguments for it. But the case for SIGPWR *is not* "that is the signal
sent by lxd when it wants to shut down a container"! The case for SIGPWR
is "the kernel may send this in the event of a power failure".

You may find that the difference is asinine, and that I'm splitting
hairs; but I'm really not, and the difference is subtle but important.

In the latter case, the kernel takes precedence over init, the kernel
decides what the API is and init must adapt. If the kernel says "when
I get a power failure, I send you SIGPWR", init cannot say "uh, no,
I wish you'd send SIGUSR2 instead". Shut up and handle SIGPWR.

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.signal.stop configuration switch exists!

Now, "stop the machine" is not a signal that a kernel would send on
its own. The decision to power off the machine comes from the admin,
usually via a "shutdown" command or equivalent. And here's the thing:
there is *no universal convention* on the API that a "shutdown"
command must follow. None.
Some inits use SIGTERM for that. Others use SIGUSR1. Others use SIGUSR2.
Others use a totally different mechanism and don't send a signal to
init at all. systemd, always being a special snowflake, uses SIGRTMIN+3
and SIGRTMIN+4, because any other choice made way too much sense.

None of them uses SIGPWR, and for a good reason: SIGPWR does not mean
"the admin requested a system shutdown", it means "power failure". And
it is very possible that the action implemented by the system in case
of a power failure is very different from a shutdown: it could be a
suspend-to-disk, for instance (which is faster than a full shutdown, and
when the power fails you want to save your data *fast*). So, even for
inits that actually understand SIGPWR - and most of them actually do -
SIGPWR is a *terrible* default choice of signal to send as a shutdown
request. It already has a use, and the use is not a normal shutdown.
Arguably, lxc.signal.halt should *always* be set to something else, be
it SIGTERM, SIGUSR1, SIGUSR2, or even lolSIGRTMIN+3.

So, if you're asking me to implement SIGPWR support in s6 because that's
what lxd sends by default to signal a container shutdown, I will laugh
at you, because you are being, uh, "ridicolous". On the other hand, if
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.

--
Laurent



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-18  9:39             ` Laurent Bercot
@ 2020-02-20 20:39               ` Serge E. Hallyn
  2020-02-23 16:51               ` Jeff
  2020-02-23 17:31               ` Jeff
  2 siblings, 0 replies; 64+ messages in thread
From: Serge E. Hallyn @ 2020-02-20 20:39 UTC (permalink / raw)
  To: Laurent Bercot; +Cc: supervision

On Tue, Feb 18, 2020 at 09:39:14AM +0000, 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.signal.stop configuration switch exists!

Yes, it is.  And for the most part, container creation templates should
know what sort of distro, and hence init, they are setting up, so they
can add the right lxc.signal.stop.  But it *is* too bad that there is no
way really to query "hey, for this init that's running in this container,
what *should* I send it?" I suspect that's where some users get annoyed.
If you're creating and destroying a lot containers with a lot if
different distros, I can see where having to guess this for yourself can
be a bit of a blocker.  So since you can't query, a convention would be
nice.  But that ship too has sailed.

-serge


^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-17 19:46               ` Cameron Nemo
@ 2020-02-23 16:11                 ` Jeff
  0 siblings, 0 replies; 64+ messages in thread
From: Jeff @ 2020-02-23 16:11 UTC (permalink / raw)
  To: supervision

> 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 does less than runit since it does not respawn any subprocess,
so this may not be a good choice for runit fans.

the only solution here is to patch runit's unmaintained code and
add support for SIGPWR (similar to the way it reacts to SIGINT
(secure attention key/ctrl-alt-del)) and SIGWINCH (keyboard request).
when you are at it you can also handle other signals (e. g. the
real time signals in a way compatible with systemd).

this is highly linux-specific of course but no real problem.

> Lastly I want to mention that lxc.signal.halt is not available with LXD.

that means SIGPWR cannot be replaced by another signal ?



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-18  9:39             ` Laurent Bercot
  2020-02-20 20:39               ` Serge E. Hallyn
@ 2020-02-23 16:51               ` Jeff
  2020-02-23 23:53                 ` Laurent Bercot
  2020-02-23 17:31               ` Jeff
  2 siblings, 1 reply; 64+ messages in thread
From: Jeff @ 2020-02-23 16:51 UTC (permalink / raw)
  To: supervision

18.02.2020, 10:39, "Laurent Bercot" <ska-supervision@skarnet.org>:
> 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*, you can say that s6-svscan should
> be able to handle every signal that the kernel can throw at it, no
> matter how unportable. And it is a reasonable request: there are good
> arguments for it.

indeed.

> In the latter case, the kernel takes precedence over init, the kernel
> decides what the API is and init must adapt. If the kernel says "when
> I get a power failure, I send you SIGPWR", init cannot say "uh, no,
> I wish you'd send SIGUSR2 instead". Shut up and handle SIGPWR.

right.

> 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.signal.stop configuration switch exists!

really ? a process #1 in a namespace is not the "real" process #1,
hence there is no requirement to use a "real" init program here.
instead it is required to react to all signals lxd may sent if said process
#1 was spawned by it. of course things would be easier for everybody
if lxd could follow exsiting conventions on the linux platform, i cannot
see why it does not use TERM, USR1/2 and so on instead to notify
the process #1 it started. but it has no obligation to do so.

i guess the only case with a special meaning for SIGPWR is when the
real kernel notifies the real process #1 of a power shortage.
hence lxd is free to abuse this signal for its own purposes.
but this default choice looks indeed quite strange.


> systemd, always being a special snowflake, uses SIGRTMIN+3
> and SIGRTMIN+4, because any other choice made way too much sense.

why should it not use the RT sigs for this ? this is absolutely ok as linux
provides them anyway (unlike OpenBSD).

> None of them uses SIGPWR, and for a good reason: SIGPWR does not mean
> "the admin requested a system shutdown", it means "power failure". And
> it is very possible that the action implemented by the system in case
> of a power failure is very different from a shutdown: it could be a
> suspend-to-disk, for instance (which is faster than a full shutdown, and
> when the power fails you want to save your data *fast*). So, even for
> inits that actually understand SIGPWR - and most of them actually do -
> SIGPWR is a *terrible* default choice of signal to send as a shutdown
> request. It already has a use, and the use is not a normal shutdown.

right, agreed.

> Arguably, lxc.signal.halt should *always* be set to something else, be
> it SIGTERM, SIGUSR1, SIGUSR2, or even lolSIGRTMIN+3.

would have been a more obvious choice indeed, but they decided against
and this is also ok since this is not the kernel.

> So, if you're asking me to implement SIGPWR support in s6 because that's
> what lxd sends by default to signal a container shutdown, I will laugh
> at you, because you are being, uh, "ridicolous".

not really, catch it and let the user handle it, that way s6-svscan could be used
as process #1 in an LXC process namespace without problems.

> On the other hand, if
> 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.

right, it should be caught anyway and the user should decide via a hook
executable what to do about it (see if power returns after a while, sync and
suspend to disk if not naturally come to mind here).

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.

you are absolutely right that one should not abuse SIGPWR to signal poweroff
to the "real" process #1 started by the kernel, there exist enough other signals
for that purpose.



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-18  9:39             ` Laurent Bercot
  2020-02-20 20:39               ` Serge E. Hallyn
  2020-02-23 16:51               ` Jeff
@ 2020-02-23 17:31               ` Jeff
  2020-02-24  0:33                 ` Laurent Bercot
  2 siblings, 1 reply; 64+ messages in thread
From: Jeff @ 2020-02-23 17:31 UTC (permalink / raw)
  To: superstition

18.02.2020, 10:39, "Laurent Bercot" <ska-supervision@skarnet.org>:
> 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 on any other platform than Linux ?
i bet you have not even tried to do so on any of the BSDs.
so why are you sticking to all this "POSIX-correctness" ?
adding a few lines of code to support a specific platform (linux or any other
unix) looks not like a big problem to me.
sticking to POSIX features in the default case is a good way to
achieve portability, that's right.
but avoiding platform specific advantages at all costs seems
pretty strange to me.

solaris, AIX and even OS X are all POSIX platforms, hence it
would be interesting to see if s6 will work out of the box there
(as process #1; handling SIGPWR may be a requirement here).
i am sure it will since unlike systemd it is portable.

those platforms cannot be "POSIX-correct" if not.
hence their kernels should be made "POSIX-correct" to run the
"POSIX-correct" s6 unchanged as process #1.

so who has to adapt, s6 or those kernels ?



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-23 16:51               ` Jeff
@ 2020-02-23 23:53                 ` Laurent Bercot
  2020-02-24  6:31                   ` innerspacepilot
  2020-02-24 21:13                   ` Guillermo
  0 siblings, 2 replies; 64+ messages in thread
From: Laurent Bercot @ 2020-02-23 23:53 UTC (permalink / raw)
  To: supervision


>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 actually find a week-end to polish things and cut it.

--
  Laurent



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-23 17:31               ` Jeff
@ 2020-02-24  0:33                 ` Laurent Bercot
  0 siblings, 0 replies; 64+ messages in thread
From: Laurent Bercot @ 2020-02-24  0:33 UTC (permalink / raw)
  To: superstition

>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 components of a BSD distro.

Replacing a BSD's init is absolutely doable: it just requires knowing
exactly what sequence of BSD-specific system calls is needed to
achieve a correct boot, and perform those in a s6-$os-init sequence,
either in stage 1 or stage 2. The problem is that it's not supposed
to be a stable API, so the BSDs are free to change it and the work
would need to be done again.

I don't think that it's worth prioritizing until there is real
traction for s6 which means a chance to get the change upstreamed - and
even then, because for many reasons, most of them good, the BSDs are
extremely reluctant to change if it comes from an outsider. Until it
can be upstreamed, bsd-with-s6-as-pid-1 can't be anything more than a
fun hack. Some people have toyed with it in the #s6 channel though.

Also, s6 works fine on the BSDs as a simple supervisor that doesn't
substitute itself to init, so you can already have its advantages
without the drawbacks. You can even have a strong supervision guarantee
if you use /etc/gettys to start the supervision tree.


>so why are you sticking to all this "POSIX-correctness" ?
>adding a few lines of code to support a specific platform (linux or any other
>unix) looks not like a big problem to me.
>sticking to POSIX features in the default case is a good way to
>achieve portability, that's right.
>but avoiding platform specific advantages at all costs seems
>pretty strange to me.

I value reproducible behaviour very much. When software behaves
differently depending on the platform is run on, it can quickly become
a maintenance nightmare. So unless a nonportable feature is *vital* to
get correct behaviour, I'd rather not use it.

For the SIGPWR and SIGWINCH thing, I made an exception because 1.
correctness is more important than anything else and 2. the patch was
absolutely trivial, so the increase in complexity due to having
architecture-dependent code paths was extremely minor. But the cost
needs to be evaluated on a case-by-case basis.

Note that I'm not avoiding platform-specific advantages when they can
achieve the same functionality. For instance, skalibs declares a
getpeereid() function, which isn't standardized in POSIX. The BSDs all
provide that function in their libc, so skalibs defers to the direct
libc implementation. Linux does not provide it, but has the SO_PEERCRED
option to getsockopt() that provides equivalent functionality. Solaris
doesn't have either of those things, but it has a getpeerucred()
function, which once again allows for some getpeereid() implementation.


>solaris, AIX and even OS X are all POSIX platforms, hence it
>would be interesting to see if s6 will work out of the box there
>(as process #1; handling SIGPWR may be a requirement here).
>i am sure it will since unlike systemd it is portable.

You are making a disingenuous argument. /sbin/init, aka the first
process that is launched by the kernel at boot time, is inherently
non-portable, because the exact API between the kernel and init has
not been standardized and every system does it differently. However,
once the non-portable sequence has been run, there's nothing that
prevents s6 from being able to run as process 1. The separation
between /sbin/init and cruising phase pid 1 is the very reason for
the existence of s6-linux-init (which does the nonportable things
for Linux, then execs into the portable s6-svscan), and the package
is named s6-linux-init because it is implied that there could easily
be s6-freebsd-init, s6-openbsd-init, s6-solaris-init, s6-macos-init
and others in the same vein if someone wanted to write them.

Again, I have not prioritized this work, but that doesn't mean it's
impossible, or even difficult. It just has low value at the moment.

The point is that the s6 package, implementing the supervision
mechanism, should remain portable, because there's no reason at all
it should be OS-dependent. All the nonportable details have been
confined to the s6-$os-init package.


>those platforms cannot be "POSIX-correct" if not.
>hence their kernels should be made "POSIX-correct" to run the
>"POSIX-correct" s6 unchanged as process #1.
>
>so who has to adapt, s6 or those kernels ?

  *You* have to adapt. You need to stop making false dichotomies and
fallacious arguments, because they don't work here. :P

--
  Laurent



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-23 23:53                 ` Laurent Bercot
@ 2020-02-24  6:31                   ` innerspacepilot
  2020-02-24 10:23                     ` Laurent Bercot
  2020-02-24 21:13                   ` Guillermo
  1 sibling, 1 reply; 64+ messages in thread
From: innerspacepilot @ 2020-02-24  6:31 UTC (permalink / raw)
  To: supervision

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 life stop throwing things at me and I
> can actually find a week-end to polish things and cut it.
>
> --
>  Laurent
>
SIGRTMIN+3 should also be caught and processed.




^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-24  6:31                   ` innerspacepilot
@ 2020-02-24 10:23                     ` Laurent Bercot
  2020-02-24 13:00                       ` Jeff
                                         ` (2 more replies)
  0 siblings, 3 replies; 64+ messages in thread
From: Laurent Bercot @ 2020-02-24 10:23 UTC (permalink / raw)
  To: supervision

>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



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-24 10:23                     ` Laurent Bercot
@ 2020-02-24 13:00                       ` Jeff
  2020-02-24 19:53                         ` Laurent Bercot
  2020-02-24 13:12                       ` innerspacepilot
  2020-02-25  8:39                       ` Jonathan de Boyne Pollard
  2 siblings, 1 reply; 64+ messages in thread
From: Jeff @ 2020-02-24 13:00 UTC (permalink / raw)
  To: superstition

24.02.2020, 11:23, "Laurent Bercot" <ska-supervision@skarnet.org>:
>> 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 <signal.h>

...

#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

...



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-24 10:23                     ` Laurent Bercot
  2020-02-24 13:00                       ` Jeff
@ 2020-02-24 13:12                       ` innerspacepilot
  2020-02-24 15:26                         ` Serge E. Hallyn
  2020-02-25  8:39                       ` Jonathan de Boyne Pollard
  2 siblings, 1 reply; 64+ messages in thread
From: innerspacepilot @ 2020-02-24 13:12 UTC (permalink / raw)
  To: supervision

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?




^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-24 13:12                       ` innerspacepilot
@ 2020-02-24 15:26                         ` Serge E. Hallyn
  2020-02-26  8:07                           ` innerspacepilot
  0 siblings, 1 reply; 64+ messages in thread
From: Serge E. Hallyn @ 2020-02-24 15:26 UTC (permalink / raw)
  To: innerspacepilot; +Cc: supervision

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.

<checks>  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-devel@lists.linuxcontainers.org)

-serge


^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-24 13:00                       ` Jeff
@ 2020-02-24 19:53                         ` Laurent Bercot
  0 siblings, 0 replies; 64+ messages in thread
From: Laurent Bercot @ 2020-02-24 19:53 UTC (permalink / raw)
  To: supervision


>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



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-23 23:53                 ` Laurent Bercot
  2020-02-24  6:31                   ` innerspacepilot
@ 2020-02-24 21:13                   ` Guillermo
  2020-02-24 22:25                     ` Laurent Bercot
  1 sibling, 1 reply; 64+ messages in thread
From: Guillermo @ 2020-02-24 21:13 UTC (permalink / raw)
  To: supervision

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.


^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-24 21:13                   ` Guillermo
@ 2020-02-24 22:25                     ` Laurent Bercot
  2020-02-24 22:49                       ` Laurent Bercot
                                         ` (2 more replies)
  0 siblings, 3 replies; 64+ messages in thread
From: Laurent Bercot @ 2020-02-24 22:25 UTC (permalink / raw)
  To: supervision


  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



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-24 22:25                     ` Laurent Bercot
@ 2020-02-24 22:49                       ` Laurent Bercot
  2020-02-24 23:08                         ` Guillermo
  2020-02-24 23:03                       ` Guillermo
  2020-03-16 12:31                       ` Jeff
  2 siblings, 1 reply; 64+ messages in thread
From: Laurent Bercot @ 2020-02-24 22:49 UTC (permalink / raw)
  To: supervision

>  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



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-24 22:25                     ` Laurent Bercot
  2020-02-24 22:49                       ` Laurent Bercot
@ 2020-02-24 23:03                       ` Guillermo
  2020-03-16 12:31                       ` Jeff
  2 siblings, 0 replies; 64+ messages in thread
From: Guillermo @ 2020-02-24 23:03 UTC (permalink / raw)
  To: supervision

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.


^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-24 22:49                       ` Laurent Bercot
@ 2020-02-24 23:08                         ` Guillermo
  2020-02-25  1:48                           ` Laurent Bercot
  0 siblings, 1 reply; 64+ messages in thread
From: Guillermo @ 2020-02-24 23:08 UTC (permalink / raw)
  To: supervision

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.


^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-24 23:08                         ` Guillermo
@ 2020-02-25  1:48                           ` Laurent Bercot
  2020-02-25  9:08                             ` Jonathan de Boyne Pollard
  0 siblings, 1 reply; 64+ messages in thread
From: Laurent Bercot @ 2020-02-25  1:48 UTC (permalink / raw)
  To: supervision


>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



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-24 10:23                     ` Laurent Bercot
  2020-02-24 13:00                       ` Jeff
  2020-02-24 13:12                       ` innerspacepilot
@ 2020-02-25  8:39                       ` Jonathan de Boyne Pollard
  2 siblings, 0 replies; 64+ messages in thread
From: Jonathan de Boyne Pollard @ 2020-02-25  8:39 UTC (permalink / raw)
  To: supervision

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

(-:


^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-25  1:48                           ` Laurent Bercot
@ 2020-02-25  9:08                             ` Jonathan de Boyne Pollard
  2020-02-25 18:38                               ` Guillermo
                                                 ` (2 more replies)
  0 siblings, 3 replies; 64+ messages in thread
From: Jonathan de Boyne Pollard @ 2020-02-25  9:08 UTC (permalink / raw)
  To: supervision

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 console device, which is not necessarily a KVT.  Second: The 
mechanism does not require an open file descriptor.  It requires that 
the target process never terminate, because there's no symmetrical 
kernel API function to disable the mechanism once it has been enabled, 
but it does not require that that process have any particular file 
descriptors open.



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-25  9:08                             ` Jonathan de Boyne Pollard
@ 2020-02-25 18:38                               ` Guillermo
  2020-03-16 12:49                               ` Jeff
  2020-03-16 17:13                               ` Jeff
  2 siblings, 0 replies; 64+ messages in thread
From: Guillermo @ 2020-02-25 18:38 UTC (permalink / raw)
  To: supervision

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 |
O_NOCTTY) + ioctl() + fd_close() sequence to s6-linux-init.c right
after the reboot(RB_DISABLE_CAD) call, specifying SIGQUIT as the
argument of the KDSIGACCEPT ioctl (to use a signal 'divertable' by
s6-2.9.0.1's s6-svscan), and the SIGQUIT handler does get called
indeed when I press Alt + Up Arrow.

The file descriptor specified in the ioctl() call, as far as I can
tell, is only used by the kernel to check permissions. The ioctl is
allowed if the FD corresponds to the process' control terminal, or if
the process has CAP_KILL or CAP_SYS_TTY_CONFIG capabilities. But the
kernel just seems to record the PID of the invoking process and the
requested signal number. (vt_ioctl() in drivers/tty/vt/vt_ioctl.c).

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

Yeah, I overlooked this. I suppose it'll work on /dev/console as long
as it is a kernel virtual terminal, but it won't always be the case.
sysvinit and systemd use /dev/tty0 for the ioctl (and sysvinit falls
back to its standard input if that fails), so I used that for the
(second) test.

G.


^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-24 15:26                         ` Serge E. Hallyn
@ 2020-02-26  8:07                           ` innerspacepilot
  2020-02-28  6:39                             ` Jan Braun
  2020-02-29 18:20                             ` Guillermo
  0 siblings, 2 replies; 64+ messages in thread
From: innerspacepilot @ 2020-02-26  8:07 UTC (permalink / raw)
  To: supervision

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 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.
> <checks>  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-devel@lists.linuxcontainers.org)
>
> -serge




^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-26  8:07                           ` innerspacepilot
@ 2020-02-28  6:39                             ` Jan Braun
  2020-02-28  9:45                               ` Alex Suykov
  2020-02-29 18:20                             ` Guillermo
  1 sibling, 1 reply; 64+ messages in thread
From: Jan Braun @ 2020-02-28  6:39 UTC (permalink / raw)
  To: innerspacepilot; +Cc: supervision

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

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 difference to "please shutdown the system", even if
(current versions of) busybox and openrc choose to shutdown the system
when told about an imminent power failure.

Laurent (imho correctly) argues that e.g. suspend-to-disk would be a
better reaction when faced with an imminent power failure, and therefore
refuses to declare that his init will shutdown the system when getting
SIGPWR.

The people who think adjusting lxc.signal.halt is too much effort would
like inits to standardize on a signal for initiating shutdown. That
would indeed be nice.
But the only (catchable) signal that's out of the question for that
purpose is, indeed, SIGPWR. Because the most relevant realworld
software, the Linux kernel itself, has already fixed SIGPWR for a
different purpose.

cheers,
    Jan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-28  6:39                             ` Jan Braun
@ 2020-02-28  9:45                               ` Alex Suykov
  2020-02-28 23:50                                 ` fungal-net
  2020-02-29 13:44                                 ` Jonathan de Boyne Pollard
  0 siblings, 2 replies; 64+ messages in thread
From: Alex Suykov @ 2020-02-28  9:45 UTC (permalink / raw)
  To: supervision

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 imminent power failure.

The Linux kernel never sends SIGPWR to init on most platforms.

Grepping the source, there are only about two places where SIGPWR can be
sent to the init process from the kernel: machine check exception on S390,
and some power-related hardware failure indication on SGI workstations.
I'm not familiar with either of those but I suspect in both cases
the signal is expected to initiate immediate shutdown. Otherwise, why
would they signal init.

Just for reference, I checked apcupsd sources. It does include an example
of sending SIGPWR to init when some UPS event arrives, but it's just an
example, and in that setting spawning some script would be a better approach
anyway. The same applies to pretty much anything else in userspace that might
be monitoring power supply. It should not be signalling init, it should
have some sort of a configuration event handler.

Unless it's matter of principle, hard-coding SIGPWR as a shutdown signal
sounds like a decent idea to me, at least on Linux. LXD and similar
containers might be the only class of applications for which signalling
init like that actually makes sense. The distinction between SIGINT for
reboot and SIGPWR for shutdown does not sound awful either.


^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-28  9:45                               ` Alex Suykov
@ 2020-02-28 23:50                                 ` fungal-net
  2020-02-29 13:44                                 ` Jonathan de Boyne Pollard
  1 sibling, 0 replies; 64+ messages in thread
From: fungal-net @ 2020-02-28 23:50 UTC (permalink / raw)
  To: supervision

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 kernel signal and direct it to any
designed chosen process is still open without it.


^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-28  9:45                               ` Alex Suykov
  2020-02-28 23:50                                 ` fungal-net
@ 2020-02-29 13:44                                 ` Jonathan de Boyne Pollard
  1 sibling, 0 replies; 64+ messages in thread
From: Jonathan de Boyne Pollard @ 2020-02-29 13:44 UTC (permalink / raw)
  To: supervision

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 conventionally described as "power fail/restart".  The "something" 
can include *that the power has been restored*.  And indeed, this has 
been its long-time use, on AT&T Unix and on Linux.   Miquel van 
Smoorenbug's original powerd daemon (which later became Tom Webster's 
genpowerd), for just one example, sent a SIGPWR to process 1 and 
beforehand wrote *what that meant* into /etc/powerstatus, which could be 
"LOW", "FAIL", or "OK".  A. B. Prasad's powerh, a trap handler for 
snmptrapd, did the same.  And there are several others over the years.

* https://linuxgazette.net/issue83/prasad.html

(Indeed, on several operating systems, including HP-UX and SunOS, SIGPWR 
sent to a process other than process #1 *only* meant "power has been 
restored", and did not have the power fail meaning at all.  Programs 
were expected to reinitialize after power comes back in their SIGPWR 
handlers.  A full-screen TUI program would re-draw its UI, for example, 
on the assumption that the local terminals had lost power as well and 
were currently showing blank screens.)

It is quite wrongheaded to think that this can be completely changed 
into a "shut down and power off" command, for that reason and others 
besides.  Other reasons include that existing systems *already define 
different signals to mean that*.  There is an existing mechanism 
already.  Several, in fact.  They need more than one signal, too.  
systemd (and the nosh toolset's system-manager which has compatible 
signalling here) uses two of the real-time signals to mean "shut down 
and power off", one to trigger the service changes, and the other to 
finalize the procedure.  There's no convincing case for either the 
systemd authors or me to change, given that SIGPWR has already meant 
something else for a long time and changing it would conflict with 
existing programs that we want to interoperate with.  There's a strongly 
convincing case to *avoid* changing SIGPWR, in fact.

The simple truth is that if you are using SIGPWR to mean only a "power 
failed" event, you aren't using it correctly.  van Smoorenburg init went 
and looked into /etc/powerstatus and acted accordingly, and still does 
so *to this day*, albeit that the file is now located under /var/run.  
(The systemd people and I both provide infrastructure only.  We define a 
target that is activated, but not what services that target invokes; and 
we leave it up to the third-party services to determine what the power 
change event actually is.)  Send a SIGPWR to process 1 without writing 
/run/powerstatus means that you'll get the last power change event set 
by the person that *did* use the signal properly.

Moreover, not only is there an existing mechanism in such programs, 
there are *several* existing mechanisms.  And they don't even all use 
signals.  The program being run could be anything, not just 
system-manager, or runit-init, or systemd, or finit, or even one of the 
several specialized programs designed solely to be process #1 of a 
container.  *Even just those* do not all use signals.

* https://unix.stackexchange.com/a/191875/5132

In the case of van Smoorenburg init and Joachim Nilsson's finit, there 
is a private API for commanding system state changes, idiosyncratic to 
just those softwares (and not compatible even across the twain), 
involving sending messages along a FIFO that process #1 is reading the 
other end of.  Ironically, Karl M. Hegbloom augmented genpowerd back in 
1998 to optionally use this API, which is more expansive than the 
comparatively small signal API that van Smoorenburg init has.  To 
properly use van Smoorenburg init or Nilsson finit in a container, you 
have to configure the container manager to *do something else instead of 
sending signals at all* to send it system management commands such as 
"shut down and halt/restart/poweroff/powercycle", as the API for 
commanding these is not signals.  The right place to handle all of these 
variances is in the container manager's configuration settings.

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=23007#25

If you want to have some sort of "shut down and 
halt/restart/poweroff/powercycle" API between a container manager and 
process #1 inside a container, slightly absurd that the idea is for 
something that isn't a fully-fledged virtual machine with a virtual 
power supply, it is the program that is run that dictates the protocol 
to you, *not* you that dictates to the program being run.  The correct 
course of action is to tailor the container manager to the particular 
program, not try to make all programs, decades after the fact, suddenly 
discard and incompatibly overwrite the long-established, event not 
command, meaning of SIGPWR.



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-26  8:07                           ` innerspacepilot
  2020-02-28  6:39                             ` Jan Braun
@ 2020-02-29 18:20                             ` Guillermo
  2020-03-06 20:07                               ` innerspacepilot
  2020-03-06 20:09                               ` innerspacepilot
  1 sibling, 2 replies; 64+ messages in thread
From: Guillermo @ 2020-02-29 18:20 UTC (permalink / raw)
  To: Supervision

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, it does not support SIGPWR.
At least, not openrc-init from upstream OpenRC. It only reacts to
SIGINT (reboot) and SIGCHLD (reap). And if OpenRC is used only as a
service manager, behaviour of SIGPWR will be defined by the program
that happens to be running as process 1.

G.


^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-29 18:20                             ` Guillermo
@ 2020-03-06 20:07                               ` innerspacepilot
  2020-03-06 20:09                               ` innerspacepilot
  1 sibling, 0 replies; 64+ messages in thread
From: innerspacepilot @ 2020-03-06 20:07 UTC (permalink / raw)
  To: supervision

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.




^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-29 18:20                             ` Guillermo
  2020-03-06 20:07                               ` innerspacepilot
@ 2020-03-06 20:09                               ` innerspacepilot
  1 sibling, 0 replies; 64+ messages in thread
From: innerspacepilot @ 2020-03-06 20:09 UTC (permalink / raw)
  To: supervision

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-init running as process 1, then no, it does not support SIGPWR.
> At least, not openrc-init from upstream OpenRC. It only reacts to
> SIGINT (reboot) and SIGCHLD (reap). And if OpenRC is used only as a
> service manager, behaviour of SIGPWR will be defined by the program
> that happens to be running as process 1.
>
> G.

Yes, I mean "support" in context of current discussion, meaning "it is
mentioned in source code".

thanks for your info.







^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-24 22:25                     ` Laurent Bercot
  2020-02-24 22:49                       ` Laurent Bercot
  2020-02-24 23:03                       ` Guillermo
@ 2020-03-16 12:31                       ` Jeff
  2020-03-16 18:03                         ` Laurent Bercot
  2 siblings, 1 reply; 64+ messages in thread
From: Jeff @ 2020-03-16 12:31 UTC (permalink / raw)
  To: supervision

24.02.2020, 23:25, "Laurent Bercot" <ska-supervision@skarnet.org>:
> 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/stage 2) ?

the ioctl code has to be placed in s6-svscan if not.



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-25  9:08                             ` Jonathan de Boyne Pollard
  2020-02-25 18:38                               ` Guillermo
@ 2020-03-16 12:49                               ` Jeff
  2020-03-16 17:13                               ` Jeff
  2 siblings, 0 replies; 64+ messages in thread
From: Jeff @ 2020-03-16 12:49 UTC (permalink / raw)
  To: supervision

25.02.2020, 10:08, "Jonathan de Boyne Pollard" <j.deboynepollard-newsgroups@ntlworld.com>:
>>   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 console device, which is not necessarily a KVT. Second: The
> mechanism does not require an open file descriptor. It requires that
> the target process never terminate, because there's no symmetrical
> kernel API function to disable the mechanism once it has been enabled,
> but it does not require that that process have any particular file
> descriptors open.

so /dev/tty0 should be open(2)ed instead of /dev/console since it is
the tty master.

and again:
will the by the ioctl(2) call achieved arrangement survive exec chaining
into another binary (the stage2 executable s6-svscan in case of s6) ?



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-02-25  9:08                             ` Jonathan de Boyne Pollard
  2020-02-25 18:38                               ` Guillermo
  2020-03-16 12:49                               ` Jeff
@ 2020-03-16 17:13                               ` Jeff
  2 siblings, 0 replies; 64+ messages in thread
From: Jeff @ 2020-03-16 17:13 UTC (permalink / raw)
  To: supervision

25.02.2020, 10:08, "Jonathan de Boyne Pollard" <j.deboynepollard-newsgroups@ntlworld.com>:
> 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 descriptor. It requires that
> the target process never terminate, because there's no symmetrical
> kernel API function to disable the mechanism once it has been enabled,
> but it does not require that that process have any particular file
> descriptors open.

how is all this handled on the BSDs ?

their inits do not provide configuration hooks like the "ctrlaltdel"
and "kbrequest" inittab stanzas. does that mean there exist no
BSD equivalents for the "secure attention key" and "keyboard request"
Linux events ? or are the corresponding responses just hardcoded into
their inits and cannot be altered by configuration ?

do the BSD kernels signal process #1 on occurence of certain events ?
do they even know events triggered by user input on the console ?



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
  2020-03-16 12:31                       ` Jeff
@ 2020-03-16 18:03                         ` Laurent Bercot
  0 siblings, 0 replies; 64+ messages in thread
From: Laurent Bercot @ 2020-03-16 18:03 UTC (permalink / raw)
  To: supervision


>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 device state changes not survive execve() would be a very
unfriendly, un-Unixy design. I don't doubt there are some of those
out there, but apparently this isn't one of them.

--
  Laurent



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: runit SIGPWR support
@ 2020-04-14 16:57 Maxim Vetsalo
  0 siblings, 0 replies; 64+ messages in thread
From: Maxim Vetsalo @ 2020-04-14 16:57 UTC (permalink / raw)
  To: supervision

[-- Attachment #1: Type: text/plain, Size: 229 bytes --]

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: bod-0001-enable-immediate-shutdown-on-pwr-signal.diff --]
[-- Type: text/x-diff; name="bod-0001-enable-immediate-shutdown-on-pwr-signal.diff", Size: 6981 bytes --]

diff -Naur --new-file a/runit-2.1.2/man/runit.8 b/runit-2.1.2/man/runit.8
--- a/runit-2.1.2/man/runit.8	2020-03-13 23:11:44.080623026 +0300
+++ b/runit-2.1.2/man/runit.8	2020-03-13 23:21:48.188070643 +0300
@@ -75,6 +75,12 @@
 .B runit
 is told to shutdown the system.
 .P
+If
+.B runit
+receives a PWR signal,
+.B runit
+is told to start shutdown process immediately.
+.P
 if
 .B runit
 receives an INT signal, a ctrl-alt-del keyboard request is triggered.
diff -Naur --new-file a/runit-2.1.2/src/Makefile b/runit-2.1.2/src/Makefile
--- a/runit-2.1.2/src/Makefile	2020-03-13 23:11:44.099622788 +0300
+++ b/runit-2.1.2/src/Makefile	2020-03-13 23:13:44.983111536 +0300
@@ -226,6 +226,9 @@
 hasmkffo.h: choose compile hasmkffo.h1 hasmkffo.h2 load trymkffo.c
 	./choose cl trymkffo hasmkffo.h1 hasmkffo.h2 > hasmkffo.h
 
+hassgpwr.h: choose compile hassgpwr.h1 hassgpwr.h2 load trysgpwr.c
+	./choose cl trysgpwr hassgpwr.h1 hassgpwr.h2 > hassgpwr.h
+
 hassgact.h: choose compile hassgact.h1 hassgact.h2 load trysgact.c
 	./choose cl trysgact hassgact.h1 hassgact.h2 > hassgact.h
 
@@ -311,7 +314,7 @@
 sgetopt.o: buffer.h compile sgetopt.c sgetopt.h subgetopt.h
 	./compile sgetopt.c
 
-sig.o: compile sig.c sig.h
+sig.o: compile sig.c sig.h hassgpwr.h
 	./compile sig.c
 
 sig_block.o: compile hassgprm.h sig.h sig_block.c
@@ -373,12 +376,13 @@
 
 sysdeps: compile direntry.h hasflock.h hasmkffo.h hassgact.h \
 hassgprm.h hasshsgr.h haswaitp.h iopause.h load select.h systype \
-uint64.h reboot_system.h uw_tmp.h socket.lib
+uint64.h reboot_system.h uw_tmp.h socket.lib hassgpwr.h
 	rm -f sysdeps
 	cat systype compile load socket.lib >>sysdeps
 	grep sysdep direntry.h >>sysdeps
 	grep sysdep haswaitp.h >>sysdeps
 	grep sysdep hassgact.h >>sysdeps
+	grep sysdep hassgpwr.h >>sysdeps
 	grep sysdep hassgprm.h >>sysdeps
 	grep sysdep select.h >>sysdeps
 	grep sysdep uint64.h >>sysdeps
diff -Naur --new-file a/runit-2.1.2/src/TARGETS b/runit-2.1.2/src/TARGETS
--- a/runit-2.1.2/src/TARGETS	2018-10-18 12:34:41.000000000 +0300
+++ b/runit-2.1.2/src/TARGETS	2020-03-13 23:13:44.985111511 +0300
@@ -68,6 +68,7 @@
 hasmkffo.h
 hassgact.h
 hassgprm.h
+hassgpwr.h
 hasshsgr.h
 haswaitp.h
 iopause.h
diff -Naur --new-file a/runit-2.1.2/src/hassgpwr.h1 b/runit-2.1.2/src/hassgpwr.h1
--- a/runit-2.1.2/src/hassgpwr.h1	1970-01-01 03:00:00.000000000 +0300
+++ b/runit-2.1.2/src/hassgpwr.h1	2020-03-13 23:13:44.986111499 +0300
@@ -0,0 +1,3 @@
+/* Public domain. */
+
+/* sysdep: -sigpwr */
diff -Naur --new-file a/runit-2.1.2/src/hassgpwr.h2 b/runit-2.1.2/src/hassgpwr.h2
--- a/runit-2.1.2/src/hassgpwr.h2	1970-01-01 03:00:00.000000000 +0300
+++ b/runit-2.1.2/src/hassgpwr.h2	2020-03-13 23:13:44.988111474 +0300
@@ -0,0 +1,4 @@
+/* Public domain. */
+
+/* sysdep: +sigpwr */
+#define HASSIGPWR 1
diff -Naur --new-file a/runit-2.1.2/src/runit.c b/runit-2.1.2/src/runit.c
--- a/runit-2.1.2/src/runit.c	2020-03-13 23:11:44.050623401 +0300
+++ b/runit-2.1.2/src/runit.c	2020-03-13 23:13:44.990111449 +0300
@@ -5,6 +5,7 @@
 #include <signal.h>
 #include <unistd.h>
 #include <fcntl.h>
+#include "hassgpwr.h"
 #include "runit.h"
 #include "sig.h"
 #include "strerr.h"
@@ -30,6 +31,7 @@
 int selfpipe[2];
 int sigc =0;
 int sigi =0;
+int sigp =0;
 
 void sig_cont_handler (void) {
   sigc++;
@@ -39,6 +41,10 @@
   sigi++;
   write(selfpipe[1], "", 1);
 }
+void sig_pwr_handler (void) {
+  sigp++;
+  write(selfpipe[1], "", 1);
+}
 void sig_child_handler (void) { write(selfpipe[1], "", 1); }
 
 void sync_if_needed() {
@@ -73,6 +79,11 @@
   sig_catch(sig_int, sig_int_handler);
   sig_block(sig_pipe);
   sig_block(sig_term);
+#ifdef HASSIGPWR
+  sig_block(sig_pwr);
+  sig_catch(sig_pwr, sig_pwr_handler);
+#endif
+
 
   /* console */
   if ((ttyfd =open_write("/dev/console")) != -1) {
@@ -136,6 +147,10 @@
       sig_uncatch(sig_int);
       sig_unblock(sig_pipe);
       sig_unblock(sig_term);
+#ifdef HASSIGPWR
+      sig_unblock(sig_pwr);
+      sig_ignore(sig_pwr);
+#endif
             
       strerr_warn3(INFO, "enter stage: ", stage[st], 0);
       execve(*prog, (char *const *)prog, envp);
@@ -150,6 +165,9 @@
       sig_unblock(sig_child);
       sig_unblock(sig_cont);
       sig_unblock(sig_int);
+#ifdef HASSIGPWR
+      sig_unblock(sig_pwr);
+#endif
 #ifdef IOPAUSE_POLL
       poll(&x, 1, 14000);
 #else
@@ -161,6 +179,9 @@
       sig_block(sig_cont);
       sig_block(sig_child);
       sig_block(sig_int);
+#ifdef HASSIGPWR
+      sig_block(sig_pwr);
+#endif
       
       while (read(selfpipe[0], &ch, 1) == 1) {}
       while ((child =wait_nohang(&wstat)) > 0)
@@ -211,7 +232,7 @@
       }
 
       /* sig? */
-      if (!sigc  && !sigi) {
+      if (!sigc  && !sigi && !sigp) {
 #ifdef DEBUG
         strerr_warn2(WARNING, "poll: ", &strerr_sys);
 #endif
@@ -219,7 +240,7 @@
       }
       if (st != 1) {
         strerr_warn2(WARNING, "signals only work in stage 2.", 0);
-        sigc =sigi =0;
+        sigc =sigi =sigp =0;
         continue;
       }
       if (sigi && (stat(CTRLALTDEL, &s) != -1) && (s.st_mode & S_IXUSR)) {
@@ -244,7 +265,7 @@
         sigi =0;
         sigc++;
       }
-      if (sigc && (stat(STOPIT, &s) != -1) && (s.st_mode & S_IXUSR)) {
+      if (sigp || (sigc && (stat(STOPIT, &s) != -1) && (s.st_mode & S_IXUSR))) {
         int i;
         /* unlink(STOPIT); */
         chmod(STOPIT, 0);
@@ -280,13 +301,13 @@
           if (wait_pid(&wstat, pid) == -1)
             strerr_warn2(WARNING, "wait_pid: ", &strerr_sys);
         }
-        sigc =0;
+        sigc =sigp =0;
         strerr_warn3(INFO, "leave stage: ", stage[st], 0);
 
         /* enter stage 3 */
         break;
       }
-      sigc =sigi =0;
+      sigc =sigi =sigp =0;
 #ifdef DEBUG
       strerr_warn2(WARNING, "no request.", 0);
 #endif
diff -Naur --new-file a/runit-2.1.2/src/sig.c b/runit-2.1.2/src/sig.c
--- a/runit-2.1.2/src/sig.c	2018-10-18 12:34:41.000000000 +0300
+++ b/runit-2.1.2/src/sig.c	2020-03-13 23:13:44.991111436 +0300
@@ -1,6 +1,7 @@
 /* Public domain. */
 
 #include <signal.h>
+#include "hassgpwr.h"
 #include "sig.h"
 
 int sig_alarm = SIGALRM;
@@ -11,5 +12,9 @@
 int sig_pipe = SIGPIPE;
 int sig_term = SIGTERM;
 
+#ifdef HASSIGPWR
+int sig_pwr = SIGPWR;
+#endif
+
 void (*sig_defaulthandler)() = SIG_DFL;
 void (*sig_ignorehandler)() = SIG_IGN;
diff -Naur --new-file a/runit-2.1.2/src/sig.h b/runit-2.1.2/src/sig.h
--- a/runit-2.1.2/src/sig.h	2018-10-18 12:34:41.000000000 +0300
+++ b/runit-2.1.2/src/sig.h	2020-03-13 23:13:44.993111411 +0300
@@ -11,6 +11,10 @@
 extern int sig_pipe;
 extern int sig_term;
 
+#ifdef HASSIGPWR
+extern int sig_pwr;
+#endif
+
 extern void (*sig_defaulthandler)();
 extern void (*sig_ignorehandler)();
 
diff -Naur --new-file a/runit-2.1.2/src/trysgpwr.c b/runit-2.1.2/src/trysgpwr.c
--- a/runit-2.1.2/src/trysgpwr.c	1970-01-01 03:00:00.000000000 +0300
+++ b/runit-2.1.2/src/trysgpwr.c	2020-03-13 23:13:44.994111399 +0300
@@ -0,0 +1,8 @@
+/* Public domain. */
+
+#include <signal.h>
+
+main()
+{
+    int sg = SIGPWR;
+}

^ permalink raw reply	[flat|nested] 64+ messages in thread

end of thread, other threads:[~2020-04-14 16:57 UTC | newest]

Thread overview: 64+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <1beb6e35-d4be-60b8-fc52-af666c4fffe3@gmx.com>
2020-02-12 14:25 ` runit SIGPWR support innerspacepilot
2020-02-12 21:54   ` Colin Booth
2020-02-12 22:16     ` Dewayne Geraghty
2020-02-14  9:38     ` Jeff
2020-02-14 12:38       ` Steve Litt
2020-02-15 10:47       ` fungal-net
2020-02-14 10:08     ` Jeff
2020-02-14 10:46     ` Jeff
2020-02-14 12:29       ` innerspacepilot
2020-02-14 12:45         ` Steve Litt
     [not found]           ` <CALZWFRLvtofWfP4kzxJ8_8_K3nzebPjCR-NsJ2MU22cSuaOLng@mail.gmail.com>
     [not found]             ` <20200214182241.15614126@mydesk.domain.cxm>
2020-02-17 19:46               ` Cameron Nemo
2020-02-23 16:11                 ` Jeff
2020-02-17 14:39         ` Jeff
2020-02-14 14:02       ` Casper Ti. Vector
2020-02-17 14:45     ` Jeff
2020-02-17 14:50       ` Jeff
2020-02-14 13:15   ` Casper Ti. Vector
2020-02-14 13:39     ` innerspacepilot
2020-02-14 13:57       ` Casper Ti. Vector
2020-02-14 14:06         ` innerspacepilot
2020-02-14 14:25           ` Casper Ti. Vector
2020-02-14 18:30       ` Laurent Bercot
2020-02-17 10:00         ` innerspacepilot
2020-02-17 15:13           ` Jeff
2020-02-18  9:39             ` Laurent Bercot
2020-02-20 20:39               ` Serge E. Hallyn
2020-02-23 16:51               ` Jeff
2020-02-23 23:53                 ` Laurent Bercot
2020-02-24  6:31                   ` innerspacepilot
2020-02-24 10:23                     ` Laurent Bercot
2020-02-24 13:00                       ` Jeff
2020-02-24 19:53                         ` Laurent Bercot
2020-02-24 13:12                       ` innerspacepilot
2020-02-24 15:26                         ` Serge E. Hallyn
2020-02-26  8:07                           ` innerspacepilot
2020-02-28  6:39                             ` Jan Braun
2020-02-28  9:45                               ` Alex Suykov
2020-02-28 23:50                                 ` fungal-net
2020-02-29 13:44                                 ` Jonathan de Boyne Pollard
2020-02-29 18:20                             ` Guillermo
2020-03-06 20:07                               ` innerspacepilot
2020-03-06 20:09                               ` innerspacepilot
2020-02-25  8:39                       ` Jonathan de Boyne Pollard
2020-02-24 21:13                   ` Guillermo
2020-02-24 22:25                     ` Laurent Bercot
2020-02-24 22:49                       ` Laurent Bercot
2020-02-24 23:08                         ` Guillermo
2020-02-25  1:48                           ` Laurent Bercot
2020-02-25  9:08                             ` Jonathan de Boyne Pollard
2020-02-25 18:38                               ` Guillermo
2020-03-16 12:49                               ` Jeff
2020-03-16 17:13                               ` Jeff
2020-02-24 23:03                       ` Guillermo
2020-03-16 12:31                       ` Jeff
2020-03-16 18:03                         ` Laurent Bercot
2020-02-23 17:31               ` Jeff
2020-02-24  0:33                 ` Laurent Bercot
2020-02-14 19:08   ` John W Higgins
2020-02-14 23:18     ` Laurent Bercot
2020-02-14 23:38       ` John W Higgins
2020-02-15  2:15         ` Laurent Bercot
2020-04-14 16:57 Maxim Vetsalo
  -- strict thread matches above, loose matches on Subject: below --
2020-01-23 20:44 innerspacepilot
2020-01-31  4:39 ` Colin Booth

supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/supervision

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 supervision supervision/ http://inbox.vuxu.org/supervision \
		subscribe@list.skarnet.org
	public-inbox-index supervision

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.supervision.general


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git