mirror of
https://github.com/troglobit/finit.git
synced 2026-10-14 10:19:36 +00:00
Joachim Wiberg
c584795202
Reference sections kept pointing at the line-based format they no longer
document. `sysv` and `task` sent the reader to Services for "<COND>",
the cgroups chapter opened by listing three legacy directives and then
explained further down that only two of them exist here, and the logging
chapter still gave "log:prio:facility.level,tag:ident" as the full
syntax.
Some claims were wrong independent of the format:
- a sysv is a supervised daemon, grouped with service in
SVC_TYPE_DAEMON, not a variation on task
- restart-max has no upper bound of 255, or any other
- the built-in rescue fallback runs in 12345789, not 12345
- conditional loading quotes system/10-hotplug.conf, not
system/hotplug.conf
- the key spells conflicts, not conflict
- the built-in getty no longer wants TERM last, it is a key
`if` takes either a service name or, in angle brackets, a condition,
decided in svc_ifthen(). Only the examples showed this, so it is now
said.
Terminology follows the split index.md already draws: a block is the new
format, a stanza the line-based one.
src/rescue.conf was still line-based, missed because it sits in src/
rather than system/ or contrib/.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
82 lines
3.4 KiB
Markdown
82 lines
3.4 KiB
Markdown
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](../conditions.md).
|
|
|
|
> [!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.
|