Reason for s6-svscan -X

Reason for s6-svscan -X

[Paul Sopka]

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

Hey everyone,

a while ago I posted an init script here.
After fiddling with init a bit I wondered why
to not just redirect the stdout of s6-svscan-log
to /dev/console, instead of using s6-svscan -X.

I have used the configuration of s6-svscan without "-X"
and s6-svscan-log with something like:
"... fdmove -c 1 2 redirfd -a 1 /dev/console s6-log 1 ..."
and wonder if there is any drawback to that?

Regards,
Paul

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

Re: Reason for s6-svscan -X

[Laurent Bercot]

>a while ago I posted an init script here.
>After fiddling with init a bit I wondered why
>to not just redirect the stdout of s6-svscan-log
>to /dev/console, instead of using s6-svscan -X.
>
>I have used the configuration of s6-svscan without "-X"
>and s6-svscan-log with something like:
>"... fdmove -c 1 2 redirfd -a 1 /dev/console s6-log 1 ..."
>and wonder if there is any drawback to that?

  The reason for -X is that s6-svscan and the s6-supervise process for
s6-svscan-log need to keep an fd to the real console as well (we cannot
hardcode /dev/console because on some systems it has another name).

  s6-svscan needs to restore its stdout and stderr to the real console
if it exits/panic. It also needs to spawn the supervisor for 
s6-svscan-log
with stderr pointing to the real console, because that supervisor cannot
assume that the s6-svscan-log fifo is always open for reading (and in
fact, at spawn time, it is not) so this s6-supervise instance also needs
to write its error messages to the real console.

  In short: the catch-all logger isn't the only process that needs to 
know
the real console, all its ancestors in the supervision tree do as well,
because they're "lower level" than the catch-all logger.

--
  Laurent

Re: Reason for s6-svscan -X

[Paul Sopka]

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

> 
>   The reason for -X is that s6-svscan and the s6-supervise process for
> s6-svscan-log need to keep an fd to the real console as well (we cannot
> hardcode /dev/console because on some systems it has another name).
> 
With my scripted approach I need to do "... redirfd -a 3 /dev/console s6-svscan -X3 ...",
so I need to write a special "compatible" script for all kernels anyway.

>   s6-svscan needs to restore its stdout and stderr to the real console
> if it exits/panic. It also needs to spawn the supervisor for 
> s6-svscan-log
> with stderr pointing to the real console, because that supervisor cannot
> assume that the s6-svscan-log fifo is always open for reading (and in
> fact, at spawn time, it is not) so this s6-supervise instance also needs
> to write its error messages to the real console.
> 
>   In short: the catch-all logger isn't the only process that needs to 
> know
> the real console, all its ancestors in the supervision tree do as well,
> because they're "lower level" than the catch-all logger.
> 
> --
>   Laurent
> 
Thank you for explaining,
Paul

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