supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: "Laurent Bercot" <>
To: "Carlos Eduardo" <>,
Subject: Re: Readiness notification using signals
Date: Wed, 29 Sep 2021 16:14:05 +0000	[thread overview]
Message-ID: <emc9c9d9d7-b077-4a6f-9b09-d08569c7b197@elzian> (raw)
In-Reply-To: <>

  Hi Carlos,

>I'm supervising an instance of an X Server using s6.
>X.Org has a built-in readiness notification mechanism: it sends a USR1
>to its parent process once it's ready. From what I know, it would be

  This... 😱 this is appalling.

  This mechanism is a terrible way to notify readiness.
  1. It forces the program reading readiness information to be the
direct parent of the daemon.
  2. This is not a concern for X, but if the daemon has dropped
privileges, it is very possible that it does not have the rights to
signal its parent anymore.
  3. It forces the parent to use the siginfo_t structure, and more
complex signal management, in order to detect what process is sending
the signal. This can work, but is by no means a common use of signals.
  4. Signals can be lost if several signals of the same value are
received by a process. So if two processes are notifying readiness at
the same time to a unique supervisor via SIGUSR1, it is possible that
the supervisor only gets one of them.

>However, after reading the documentation, there doesn't seem to be a
>way to set up custom USR1 handlers for s6-supervise.

  Indeed, there isn't. Signals are meant to be a control mechanism from
above, not from below: the administrator is supposed to be able to send
signals to s6-supervise, but the supervised process *definitely is not*.

>  As far as I know,
>this leaves me with two, not quite ideal solutions: make the run
>script spawn X and do readiness notification on its behalf (which
>lengthens the supervision chain), or poll it (which is what I've been
>doing). Is there a way to not let the information from this USR1 not
>"go to waste"?

  Let this "information" go to waste: it should never be sent in the
first place, and if patching were to happen, it should be to delete
that chunk of code from the Xorg server. We should consider ourselves
lucky that s6-supervise is not using SIGUSR1 for its own purposes and
is happily ignoring it as is.

  Fortunately, there is a different solution for you: the -displayfd 
to the X command will print the display number, followed by a newline,
to the (argument of -displayfd) file descriptor, when X has found a
display. This only happens when X is ready - unless it only starts
listening to its socket later, but the window should be super small; and
it has the correct format for an s6 notification.
  So, using displayfd as your notification fd will work.
  For instance, if you have 3 in your notification-fd file, starting
X -displayfd 3 should properly (or *almost* properly) notify readiness.
Some people already use that mechanism, and are happy with it. :)

  Good luck,


      reply	other threads:[~2021-09-29 16:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-29 12:24 Carlos Eduardo
2021-09-29 16:14 ` Laurent Bercot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=emc9c9d9d7-b077-4a6f-9b09-d08569c7b197@elzian \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).