Re: s6-linux-init: SIGUSR1 and SIGUSR2

[Guillermo]

2016-08-22 7:15 GMT-03:00 Laurent Bercot:
>
>  The next s6+friends version release will have major version bumps all
> around, so compatibility is moot anyway. If you really think it's worth it
> to swap SIGUSR1 and SIGUSR2, I'll do it.

It would be more aesthetically pleasing if s6-halt sent SIGUSR1,
s6-poweroff sent SIGUSR2, and s6-reboot sent SIGTERM, in the sense
that it would make a couple of init systems almost agree, but that's
it. At this point, reassigning the 'reboot' meaning to SIGTERM would
probably more useful than swapping SIGUSR1 and SIGUSR2, because it
frees SIGINT, an therefore CTRL + Alt + Del, to do whatever the
administrator or distribution pleases, like in the
/etc/s6-init/ctrlaltdel example I gave.

But from a user's point of view, as long as s6-halt, s6-poweroff and
s6-reboot "just work" and do what they say they do, everything is OK.
Which means that 'out of the box' s6-linux-utils programs have to
agree with 'out of the box' s6-linux-init handlers, and this happens
already. Also, the way s6-svscan implements signal diversion is
flexible, so one can rearrange or modify s6-linux-init's handlers to
align with a different convention than s6-linux-utils' current one.

So, in conclusion: alignment with BusyBox init's convention is nicer,
but if you feel you'd rather use the time for something else, or if
changing the convention would break too many things, then I'd say
don't bother.

> I can also add SIGWINCH support to s6-svscan, but only when it's diverted,
> because there's no possible portable default semantics.

This would be nice to have, with the same treatment SIGUSR1 and
SIGUSR2 currently have: completely ignore them with -S, divert them
with -s. Last time I checked with a 3.14-series kernel, loadkeys(1)
and a suitable keymap file, the 'keyboard request' still worked (it is
usually mapped to Alt + Up arrow). And besides the init systems I
mentioned, systemd supports it too. So yeah.

The only additional requirement to use it is a Linux-specific
'ioctl(fd, KDSIGACCEPT, SIGWINCH)' call to turn 'keyboard request' on,
because last time I experimented, I found it to be off by default when
the kernel starts. s6-svscan can't do the ioctl itself without losing
portability, but a separate chainloading program in stage1 can.

Thanks,
G.

Re: s6-linux-init: SIGUSR1 and SIGUSR2

[Martin "eto" Misuth]

Colin Booth  wrote:
>Lower case -s causes s6-svscan to execute a script on receipt of:
>TERM, INT, HUP, QUIT, USR1, USR2.

As currently I am killing most time messing with my ugly s6 jails, it's some
time I messed with PID1. As we know, quite few of the rc scripts would need to
be ported. I noticed signal handling capability in s6-svscan, and figured it is
inteded for init-like operations, but as soon as my PID1 started to run I moved
bit "below" that into userland, and I didn't try it.

Jan Bramkamp  wrote:
> I can upload my /etc/service and /etc/s6-rc/source if you're interested.

Yes ofc I would be very interested in your "favorite hacks", just to
learn from it. If you don't mind.

I would be especialy interested in how you do your intial s6-svscan bootstrap as
PID1, and how you solved intial logger fifo pipe problem.

  eto

Re: s6-linux-init: SIGUSR1 and SIGUSR2

[Colin Booth]

On Mon, Aug 22, 2016 at 7:29 AM, Martin "eto" Misuth  wrote:
> On Mon, 22 Aug 2016 07:26:12 -0700
>
> Colin Booth  wrote:
>> My own $0.02 is that s6-svscan -S should ignore power state signals
>> (including SIGINT which it currently doesn't ignore).
>
> I haven't really understood this thread, but I think I am starting to
> understand.
>
> Correct me, if I am wrong, but is this about signals, which generate various
> cleanup paths to end normal machine operations aka "curuising" mode?
Yes.
>
> Because if so, there is problem I hit before, but thought it was PEBKAC on my
> part.
>
> Currently on FreeBSD, when s6-svscan runs as PID1, native "reboot" command 
> makes
> s6-svscan do proper cleanup (I guess it sends signal which is
> correctly interpreted by s6-svscan as shutdown signal). While shutdown does
> "nothing". I guess on that box I need to add -S switch and introduce signal
> handling scripts?
>
Lower case -s causes s6-svscan to execute a script on receipt of:
TERM, INT, HUP, QUIT, USR1, USR2. If the script doesn't exist, nothing
happens. Most likely, you need to find which signal the shutdown
command sends, and write a handler script in .s6-svscan to do
something with it.

This is documented here:
http://www.skarnet.org/software/s6/s6-svscan.html

Cheers!



-- 
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
  --  William Blake

Re: s6-linux-init: SIGUSR1 and SIGUSR2

[Jan Bramkamp]

On 22/08/16 16:29, Martin "eto" Misuth wrote:

On Mon, 22 Aug 2016 07:26:12 -0700

Colin Booth  wrote:

My own $0.02 is that s6-svscan -S should ignore power state signals
(including SIGINT which it currently doesn't ignore).


I haven't really understood this thread, but I think I am starting to
understand.

Correct me, if I am wrong, but is this about signals, which generate various
cleanup paths to end normal machine operations aka "curuising" mode?

Because if so, there is problem I hit before, but thought it was PEBKAC on my
part.

Currently on FreeBSD, when s6-svscan runs as PID1, native "reboot" command makes
s6-svscan do proper cleanup (I guess it sends signal which is
correctly interpreted by s6-svscan as shutdown signal). While shutdown does
"nothing". I guess on that box I need to add -S switch and introduce signal
handling scripts?


FreeBSD has a different convention.

SIGHUP: Reload /etc/ttys. Since s6 doesn't start getty etc. from 
/etc/ttys there no need to handle this signal. I just log it to the 
default logger.


SIGINT: Reboot the system. I implemented it as `s6-rc -a -d change` 
followed by `s6-svscanctl -i /run/service`.


SIGQUIT: Not used by FreeBSD init. Just log and otherwise ignore the signal.

SIGUSR1: Halt the system. Use `s6-rc -a -d change` to stop all services 
and `s6-svscanctl -st /run/service` to halt.


SIGUSR2: Poweroff the system. Use `s6-rc -a -d change` to stop all 
services and `s6-svscanctl -pt /run/service` to power down.


It's also a good idea to kill all remaining processes, update the 
/entropy file and sync the disks from the s6-svscan ./finish script.


I can upload my /etc/service and /etc/s6-rc/source if you're interested.

Re: s6-linux-init: SIGUSR1 and SIGUSR2

[Martin "eto" Misuth]

On Mon, 22 Aug 2016 07:26:12 -0700

Colin Booth  wrote:
> My own $0.02 is that s6-svscan -S should ignore power state signals
> (including SIGINT which it currently doesn't ignore). 

I haven't really understood this thread, but I think I am starting to
understand.

Correct me, if I am wrong, but is this about signals, which generate various
cleanup paths to end normal machine operations aka "curuising" mode?

Because if so, there is problem I hit before, but thought it was PEBKAC on my
part.

Currently on FreeBSD, when s6-svscan runs as PID1, native "reboot" command makes
s6-svscan do proper cleanup (I guess it sends signal which is
correctly interpreted by s6-svscan as shutdown signal). While shutdown does
"nothing". I guess on that box I need to add -S switch and introduce signal
handling scripts?

  eto

Re: s6-linux-init: SIGUSR1 and SIGUSR2

[Colin Booth]

On Mon, Aug 22, 2016 at 6:35 AM, Laurent Bercot
 wrote:
> On 22/08/2016 14:02, Casper Ti. Vector wrote:
>>
>> Are SIGUSR1 and SIGUSR2 not just silently ignored in -S mode?
>
>
>  Uuuuh, yes, my bad, they are.
>  Sigh. I'm not sure what the right thing even is. Should they be ignored
> in -S mode? Should they do something? ISTR I kept them ignored *precisely*
> to avoid hardcoding policy into s6-svscan; it should probably remain that
> way.
My own $0.02 is that s6-svscan -S should ignore power state signals
(including SIGINT which it currently doesn't ignore). As for which
scheme s6-linux-init-maker supports when signals are redirected, I
think using busybox is an ok default since sysvinit is on the outs and
sysvinit's use of SIGUSR1 strikes me as an unfortunate misfeature.

Cheers!

-- 
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
  --  William Blake

Re: s6-linux-init: SIGUSR1 and SIGUSR2

[Laurent Bercot]

On 22/08/2016 14:02, Casper Ti. Vector wrote:

Are SIGUSR1 and SIGUSR2 not just silently ignored in -S mode?


 Uuuuh, yes, my bad, they are.
 Sigh. I'm not sure what the right thing even is. Should they be ignored
in -S mode? Should they do something? ISTR I kept them ignored *precisely*
to avoid hardcoding policy into s6-svscan; it should probably remain that way.

--
 Laurent

Re: s6-linux-init: SIGUSR1 and SIGUSR2

[Casper Ti. Vector]

Are SIGUSR1 and SIGUSR2 not just silently ignored in -S mode?

On Mon, Aug 22, 2016 at 12:15:59PM +0200, Laurent Bercot wrote:
> If you really think it's worth it to swap SIGUSR1 and SIGUSR2, I'll do
> it. (I'd change the non-diverted meanings in s6-svscan, so that they
> remain in sync with the diverted ones.)

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

Re: s6-linux-init: SIGUSR1 and SIGUSR2

[Laurent Bercot]

On 21/08/2016 23:17, Guillermo wrote:

Yeah, it seems it has come to that :) But the funny thing is a few of
the init systems for [GNU/]Linux are, or can be made to be, *almost*
(to different degrees) compatible with this signal set:

a) SIGTERM for reboot
b) SIGUSR1 for halt
c) SIGUSR2 for poweroff
d) SIGINT for a programmable CTRL + ALT + Del action
e) SIGWINCH for a programmable 'keyboard request' action


 The next s6+friends version release will have major version bumps all
around, so compatibility is moot anyway. If you really think it's worth it
to swap SIGUSR1 and SIGUSR2, I'll do it. (I'd change the non-diverted
meanings in s6-svscan, so that they remain in sync with the diverted ones.)
I can also add SIGWINCH support to s6-svscan, but only when it's diverted,
because there's no possible portable default semantics.

 What do you think?

--
 Laurent

Re: s6-linux-init: SIGUSR1 and SIGUSR2

[Jonathan de Boyne Pollard]

Guillermo:
> a) SIGTERM for reboot
> b) SIGUSR1 for halt
> c) SIGUSR2 for poweroff
> d) SIGINT for a programmable CTRL + ALT + Del action
> e) SIGWINCH for a programmable 'keyboard request' action
> 
> nosh's system-manager supports e) via the 'kbrequest' target. But for
> compatibility reasons, supports d) on [GNU/]Linux via the
> 'secure-attention-key' target, but not on the BSDs, where SIGINT means
> 'halt'. Supports a) and b) on the BSDs, but not a), because SIGTERM
> means 'enter rescue mode'. And doesn't support a) to c) on
> [GNU/]Linux, because it follows the systemd signal convention (signals
> above SIGRTMIN) there instead.

Or, to put it another way:

On FreeBSD, PC-BSD, and OpenBSD, the nosh system-control and system-manager
tools use (b) and (c) for compatibility with existing BSD tools. But for further
compatibility with existing BSD tools, SIGINT means (orderly shutdown and)
reboot and SIGTERM means bring up rescue mode. To the current FreeBSD/PC-BSD
init and OpenBSD init and accompanying toolset, SIGINT means reboot (indivisibly
from Ctrl+Alt+Del) and SIGTERM means single-user mode. The FreeBSD/PC-BSD and
OpenBSD kernels send SIGINT but don't send SIGWINCH in the first place. If they
did, though, it would be regarded as (e).

On Linux, the nosh system-control and system-manager are designed to use the
Linux kernel and systemd signalling conventions.  (d) and (e) are Linux kernel
conventions.  (a), (b), and (c) are BSDisms that as Guillermo noted have never
really been the case on Linux at all.  (b) actually outright conflicts with a
van Smoorenburg init convention (where it means "restart the initctl server").
 It also conflicts with an upstart convention (where it means "re-connect to
Desktop Bus").  Moreover, upstart and systemd have made the semantics of SIGTERM
into a mess, where for a system-wide systemd/upstart init it means one thing and
for a per-user systemd/upstart init it means something quite different.  Neither
meaning is reboot.  Orderly shutdown and halt/reboot/poweroff are various
real-time signals, instead.

The systemd real-time signals for orderly shutdown and halt/reboot/poweroff are
also available on FreeBSD and PC-BSD, in fact. Apart from this last, all of the
aforegiven is documented in the system-control and system-manager user manuals.

See https://jdebp.eu./FGA/emergency-and-rescue-mode-bootstrap.html for the
evolution of single-user mode into rescue mode.  The nosh system-manager can in
fact do both emergency and rescue modes on FreeBSD/PC-BSD and OpenBSD as well as
on Linux.  The BSD bootstraps themselves don't have two flags, though.

Re: s6-linux-init: SIGUSR1 and SIGUSR2

[Guillermo]

2016-08-21 6:15 GMT-03:00 Laurent Bercot:
>
> On 21/08/2016 06:18, Casper Ti. Vector wrote:
>>
>> It seems that the exchanging of SIGUSR1 and SIGUSR2 [1] in s6-linux-init
>> did not happen.  Is it just forgotten, or ...?
>
>  Well, by the point I remembered to make the change, I already had
> systems depending on the old behaviour :/

Heh. At the time this was brought up on the skaware ML, s6-rc had been
released a month before, s6-svscan had recently gained the signal
diversion feature (-s option), and s6-linux-init-maker (from
s6-linux-init), the ability to generate diverted signal handlers and
plug in a stage2_finish script, so that s6-rc could be added to the
init system. But what no skarnet.org packages provided at the time was
programs that sent signals to process 1. With the SIGUSR1/2 swap,
BusyBox's halt, poweroff and reboot applets would have been able do
the job. But s6-halt, s6-poweroff and s6-reboot (from s6-linux-utils
version >= 2.1.0.0) can now send signals to process 1, so the issue
was resolved, although in a different way.

>  It's purely a convention anyway, and busybox init, sinit and sysvinit all
> disagree - so I'm afraid there can't be a generic "shutdown" client;
> every init system must come with its own "shutdown" program, that honors
> its own convention.

Yeah, it seems it has come to that :) But the funny thing is a few of
the init systems for [GNU/]Linux are, or can be made to be, *almost*
(to different degrees) compatible with this signal set:

a) SIGTERM for reboot
b) SIGUSR1 for halt
c) SIGUSR2 for poweroff
d) SIGINT for a programmable CTRL + ALT + Del action
e) SIGWINCH for a programmable 'keyboard request' action

sysvinit a.k.a van Smoorenburg init supports d) and e) via lines with
the 'kbrequest' and 'ctrlaltdel' actions in /etc/inittab, but not a)
to c). That is handled instead by communication over the /dev/initctl
FIFO.

BusyBox init supports almost all, even d) via lines with the
'ctrlaltdel' action in /etc/inittab (if it was built with
FEATURE_USE_INITTAB enabled), but not e).

nosh's system-manager supports e) via the 'kbrequest' target. But for
compatibility reasons, supports d) on [GNU/]Linux via the
'secure-attention-key' target, but not on the BSDs, where SIGINT means
'halt'. Supports a) and b) on the BSDs, but not c), because SIGTERM
means 'enter rescue mode'. And doesn't support a) to c) on
[GNU/]Linux, because it follows the systemd signal convention (signals
above SIGRTMIN) there instead.

It should be noted that one can make s6 + s6-rc support a) to d) with
little effort by running s6-linux-init-maker, and then adapting the
diverted signal handlers instead of using them as-is:

* swapping $basedir/run-image/.s6-svscan/SIGUSR1 and
$basedir/run-image/.s6-svscanSIGUSR2
* moving $basedir/run-image/.s6-svscan/SIGINT to
$basedir/run-image/.s6-svscan/SIGTERM
* and writing a custom $basedir/run-image/.s6-svscan/SIGINT. E.g. one
that chains to, say, /etc/s6-init/ctrlaltdel if that file exists and
is executable, and returns 0 if not.

What can't be implemented is e), because s6-svscan can't currently
divert SIGWINCH. And even then, one would also need a (Linux-specific)
chainloading tool that does the KDSIGACCEPT ioctl for SIGWINCH on
/dev/console to enable the feature, so it could be insterted in the
stage1 script before it redirects stdin and chains to s6-svscan. But
that tool can be written without much effort either, I think.

G.

Re: s6-linux-init: SIGUSR1 and SIGUSR2

[Casper Ti. Vector]

Well...  That's understandable :|

On Sun, Aug 21, 2016 at 11:15:44AM +0200, Laurent Bercot wrote:
>   Well, by the point I remembered to make the change, I already had
> systems depending on the old behaviour :/
> 
>   So, all in all, I don't think I'll swap the default meaning after all.
> It's purely a convention anyway, and busybox init, sinit and sysvinit all
> disagree - so I'm afraid there can't be a generic "shutdown" client;
> every init system must come with its own "shutdown" program, that honors
> its own convention.
> 
>   Sorry about that.5

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

Re: s6-linux-init: SIGUSR1 and SIGUSR2

[Laurent Bercot]

On 21/08/2016 06:18, Casper Ti. Vector wrote:

It seems that the exchanging of SIGUSR1 and SIGUSR2 [1] in s6-linux-init
did not happen.  Is it just forgotten, or ...?


 Well, by the point I remembered to make the change, I already had
systems depending on the old behaviour :/
 So, all in all, I don't think I'll swap the default meaning after all.
It's purely a convention anyway, and busybox init, sinit and sysvinit all
disagree - so I'm afraid there can't be a generic "shutdown" client;
every init system must come with its own "shutdown" program, that honors
its own convention.

 Sorry about that.5

--
 Laurent

s6-linux-init: SIGUSR1 and SIGUSR2

[Casper Ti. Vector]

It seems that the exchanging of SIGUSR1 and SIGUSR2 [1] in s6-linux-init
did not happen.  Is it just forgotten, or ...?

[1] .

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