Joachim Wiberg
00794d41bc
The block conversion changed the bodies of the reference sections but left every "**Syntax:**" header spelling the line-based format, so each page opened by teaching the format it then stopped using. Six files were missed entirely: runparts, files, capabilities, requirements, runlevels, and switchroot. runparts had no block spelling written down anywhere, though the parser has read `runparts`, `runparts-progress`, and `runparts-sysv` all along. tty gains a table per variant. Its three syntax lines carried nine positional fields between them, which no longer describes anything the parser accepts. Fixes #148 Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
3.3 KiB
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 details on the syntax and options, see below.
Note
On
initctl reloadconditions are set in "flux", while figuring out which services to stop, start or restart. Services that need to be restarted have theirreadycondition 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 writeREADY=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<!>in its condition statement.)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.