Re: s6-rc:

From: Laurent Bercot <ska-skaware_at_skarnet.org>
Date: Fri, 27 Jan 2017 14:32:09 +0000

> # Precreate the control FIFO
> s6-mkfifo -m 0600 $S6_SCANDIR/.s6-svcan/control
>
> background {
> if {
> # Block until s6-svscan starts reading its control FIFO
> redir -w 8 $S6_SCANDIR/.s6-svcan/control
> # Do not leak the fd
> fdclose 8
> s6-rc-init -c $S6_RC_COMPILED -l $S6_RC_LIVE $S6_SCANDIR
> }
> s6-rc $VERBOSE -l $S6_RC_LIVE -u change session
> }
>
> s6-svscan -st 0 $S6_SCANDIR
>
>This is a bit "dirty" because it depends on s6-svscan internal, i.e. it
>creates a FIFO named "control" in its .s6-svscan directory.

  Yes, that should work, and yes, that's dirty, but you can't really do
any better. s6-rc(-init) assumes that an instance of s6-svscan is
already running on a scandir, and s6-svscan does not send any readiness
notification, so there will be a small race indeed, unless you use
such a pipe trick.
  Adding readiness notification would be more bloat than it's worth,
since having to synchronize between s6-svscan and s6-rc-init only
happens
once.

  The stage 1 script created by s6-linux-init-maker does something
comparable to your pipe trick, but it uses the fifo that s6-svscan's
logger reads from. When that fifo unblocks, not only is s6-svscan
already running, but it's also in its main loop and has already created
at least one service (its own logger), so it's a better readiness
guarantee.

--
  Laurent
Received on Fri Jan 27 2017 - 14:32:09 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC