Service Synchronization

Finit was created for fast booting systems. Faster than a regular SysV Init based system at the time. Early on the need for a guaranteed start order of services (daemons) arose. I.e., service A must be guaranteed to have started (and be ready!) before B. The model that was chosen to determine this was very simple: PID files.

Early on in UNIX daemons were controlled with basic IPC like signals, and the way for a user to know that a daemon was ready to respond to signals (minimally having set up its signal handler), was to tell the user;

"Hey, you can send signals to me using the PID in this file: /var/run/daemon.pid".

Since most systems run fairly unchanged after boot, Finit could rely on the PID file for A being created before launching B. This method has worked well for a long time, and for systems based on Open Source it was easy to either add PID file support to a daemon without support for it, or fix ordering issues (PID file created before signal handler is set up) in existing daemons.

However, with the advent of other Init systems (Finit is rather old), most notably systemd and s6, other methods for signaling "readiness" arrived and daemons were adapted to these new schemes to a larger extent.

As of Finit v4.4 partial support for systemd and s6 style readiness notification is available, and the native PID file mode of operation is, as of Finit v4.6 optional, by default it is still enabled, but this can be changed in finit.conf:

readiness = "none"

This will be made the default in Finit 5.0. In this mode of operation, every service needs to explicitly declare their readiness notification, like this:

service watchdogd { notify = "pid"      command = "watchdogd" }
service foo       { notify = "systemd"  command = "foo"       }
service bar       { notify = "s6"       command = "bar"       }
service qux       { notify = "none"     command = "qux"       }

The notify = "none" setting is for completeness in systems which run in readiness = "pid" mode (default). Services declared with notify = "none" will transition to ready as soon as Finit has started them, e.g., service/qux/ready.

To synchronize two services the following condition can be used:

service watchdogd {
    notify  = "pid"
    command = "watchdogd"
}

service stress-ng {
    conditions = { "service/watchdogd/ready" }
    command    = "stress-ng --cpu 8"
}

For the full list of conditions, see Finit Conditions.

Note

On initctl reload conditions are set in "flux", while figuring out which services to stop, start or restart. Services that need to be restarted have their ready condition removed before Finit issue a SIGHUP (if they support that), or stop-starting them. A daemon is expected to reassert its readiness, e.g. systemd style daemons to write READY=1\n.

However, the s6 notify mode does not support this because in s6 you are expected to close your notify descriptor after having written \n. This means s6 style daemons currently must be stop-started. (Declare the service with reload-signal = "none".)

For default, PID file style readiness notification, daemons are expected to either create their PID files, or touch it using utimensat() to reassert readiness. Triggering both the <pid/> and <.../ready> conditions.