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
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.
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
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
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
The keyboard signal can actually be set to any signal less than or
equal to NSIG with the KDSIGACCEPT ioctl. sysvinit just happened to
pick SIGWINCH for that, and so did systemd and nosh, presumably for
compatibility.
El dom., 23 feb. 2020 a las 20:53, Laurent Bercot escribió:
>
> Both SIGPWR an
in this case systemd compatibility can be trivially achieved,
so there is no real reason to abstain from it.
"systemd compatibility" makes no sense here. We are talking about
runit or s6 as an init system: by definition, in that context, there
is no systemd, no interaction with systemd, nothi
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
On 24.02.2020 13:23, Laurent Bercot wrote:
SIGRTMIN+3 should also be caught and processed.
What piece of software sends SIGRTMIN+3 to pid 1 when you're not
running systemd?
--
Laurent
Looking at lxc sources (src/lxc/lxccontainer.c:2084) nothing will, until
you block SIGRTMIN+3 signal.
Eve
24.02.2020, 11:23, "Laurent Bercot" :
>> SIGRTMIN+3 should also be caught and processed.
why only this one and not ALL of the real time signals ?
> What piece of software sends SIGRTMIN+3 to pid 1 when you're not
> running systemd?
in this case systemd compatibility can be trivially achieved,
so
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
11 matches
Mail list logo