>I am curious, does anyone on this list know of examples of such daemons? I
>am considering creating and submitting patches for some daemon programs
>that I use that do *not* support this mechanism as yet, and am curious if
>it is as simple as it looks like it should be.
- I'm trying to make it so that all my long-lived programs that provide
a service support this. For instance, s6-log as Casper mentioned, but
also s6-[ipc|tcp]server[d], which are the basic building blocks for
simple service implementation.
- There is a non-negligible amount of existing daemons in the wild that
happen to print a line when they're ready, even though they're not
necessarily aware that printing such a line can be used as readiness
notification. For instance:
* dbus-daemon has the --print-address=fd option that can be used
to notify readiness (since the address of the bus is only known after
the bus socket is ready).
* Xorg has the -displayfd option that can also be used for the
same purpose (since it only knows its display once it is ready)
* Lots of daemons have an option to print a pidfile. If you run
them and give /dev/fd/3 (or whatever your notification-fd is) as a
pidfile, they will trigger the notification mechanism when attempting
to print their pidfile. Be aware, though, that it does not necessarily
mean they're ready; they *should* be, because they should not stamp
their pid once they're certain they're going to provide service, but
they don't have to, because they know their pid as soon as they're
running - and since they're designed badly enough to think a pidfile
is a good thing, it's also very possible that they're printing it too
early. So you have to check with the daemon's source before using the
pidfile option as a readiness check.
It is definitely as simple as it looks, it was designed to be able to
reuse existing daemon behaviours, and I strongly encourage you to submit
patches to spread the use of the mechanism :)
--
Laurent
Received on Wed Apr 01 2020 - 14:55:26 UTC