We already have support for pre: and post: scripts that run right before and right after a service. When a monitored daemon has completed its internal setup, and is ready to service requests, opinions differ on how to notify the rest of the world.
Traditional UNIX daemons create a PID file ("hey userspace, you can send signals to me on this PID", usually to send SIGHUP to ask a daemon to reload its .conf file(s)) -- this is the native default in Finit. Finit also expects daemons to touch the PID file when it has completed re-init after SIGHUP.
systemd provides the sd_notify() family of APIs, which supports many different commands that can be sent from a daemon to systemd, e.g. READY=1\n
s6 supports a /run/service/foo/notification-fd which the daemon is expected to send a \n and then close when it's ready. E.g., mdevd supports the -D fd option
The current support (PID file notification) can be the starting point for the ready: script feature. When #299 is completed it can hook into this mechanism as another trigger (and also a trigger for creating the PID file, if that is requested).
We already have support for pre: and post: scripts that run right before and right after a service. When a monitored daemon has completed its internal setup, and is ready to service requests, opinions differ on how to notify the rest of the world.
sd_notify()family of APIs, which supports many different commands that can be sent from a daemon to systemd, e.g.READY=1\n/run/service/foo/notification-fdwhich the daemon is expected to send a\nand then close when it's ready. E.g., mdevd supports the-D fdoptionThe current support (PID file notification) can be the starting point for the
ready:script feature. When #299 is completed it can hook into this mechanism as another trigger (and also a trigger for creating the PID file, if that is requested).See #298 for a background.