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
