wt/finit
1
0 Fork 0
mirror of https://github.com/troglobit/finit.git synced 2026-10-26 12:14:37 +00:00
Code Issues Packages Projects Releases Wiki Activity

doc: update text on conditions to reflect new world

Browse Source
This commit is contained in:
Joachim Wiberg committed 2021-02-21 00:57:12 +01:00
1 parent e941a510c1
commit 346320f669
1 file changed
+27 -28
Download Patch File Download Diff File Expand all files Collapse all files
doc/conditions.md
+27 -28
View File
@@ -17,8 +17,8 @@ Conditions are a new addition to Finit, introduced in v3, with the
intention of providing a mechanism for common synchronization problems.
For example:
- *"do not start this service until another process has started"*, or
- *"do not starty until basic network access is available"*
- *"wait for service A to start before starting service B"*, or
- *"wait for basic network access to be available"*
Conditions are similar in syntax to declaring runlevels per service.
They are specified within angle brackets `<>` and can be applied to any
@@ -30,14 +30,12 @@ service to run.
### Example
```shell
service [2345] <pid/setupd,pid/zebra> /sbin/netd -- Network monitor
```
service [2345] <pid/setupd,pid/zebra> /sbin/netd -- Network monitor
In this example the Network monitor daemon `netd` is not started until
both the `pid/sbin/setupd` *and* `pid/sbin/zebra` conditions are
satisfied. An `svc` condition is satisfied by the corresponding
service's PID file being created.
both the `pid/setupd` *and* `pid/zebra` conditions are satisfied. A
`pid/` condition is satisfied by the corresponding service's PID file
being created.
**NOTE:** Conditions also stop services when a condition is no longer
asserted. I.e., if the Zebra process above stops or restarts, netd
@@ -56,28 +54,29 @@ on this, see [Internals](#internals).) Thus, after a reconfiguration it
is up to the "owner" of the condition to convey the new (or possibly
unchanged) state of it.
> **Note:** For `pid/` conditions it is expected that services "touch"
> or recreate their PID file on `SIGHUP`.
Built-in Conditions
-------------------
Finit is distributed with a `pidfile` and `netlink` plugin. If enabled,
the `pidfile` plugin watches `/var/run/` for PID files created by the
monitored services, and sets a corresponding condition in the `pid/`
namespace. Similarily, the `netlink` plugin provides basic conditions
for when an interface is brought up/down and when a default route
(gateway) is set, in the `net/` namespace.
Finit comes with a `pidfile` and `netlink` plugin. When enabled, the
`pidfile` plugin watches `/var/run/` (recursively) for PID files created
by the monitored services, and sets a corresponding condition in the
`pid/` namespace. Similarily, the `netlink` plugin provides basic
conditions for when an interface is brought up/down and when a default
route (gateway) is set, in the `net/` namespace.
With the example listed above, finit does not start the `/sbin/netd`
daemon until `setupd` and `zebra` has started *and* created their PID
files. Which they do when they have completed their initial set up and
are ready to receive signals.
The full path to the dependency is needed by finit to match the PID file
to a monitored process. Finit expects monitored services to touch their
PID files, i.e. update the mtime, when they reload their configuration
files after a `SIGHUP`. Some services do not support `SIGHUP` and are
instead restarted, which is a crude but effective way to have the PID
file touched (re-created).
Finit expects monitored services to touch their PID files, i.e. update
the mtime, when they reload their configuration files after a `SIGHUP`.
Some services do not support `SIGHUP` and are instead restarted, which
is a crude but effective way to have the PID file touched (re-created).
Built-in conditions:
@@ -107,9 +106,9 @@ the daemon and the empty string.
| /usr/bin/dbus-daemon | pid/dbus-daemon |
| :222 dropbear -p 222 | pid/dropbear:222 |
The condition is asserted when `pidfile.so` receives an inotify event for a file
matching `/run/*.pid`, `/run/**/*.pid`, or `/run/**/pid`, which contains the
PID of the service Finit has started.
The condition is asserted when `pidfile.so` receives an inotify event
for a file matching `/run/*.pid`, `/run/**/*.pid`, or `/run/**/pid`,
which contains the PID of the service Finit has started.
When Finit configuration files are changed and the `initctl reload`
command is called, it is expected of services to touch their PID files
@@ -140,10 +139,10 @@ conditions that are not satisfied. Listed as `off` below.
```shell
~ # initctl cond show
PID Service Status Condition (+ on, ~ flux, - off)
===============================================================================
1419 /sbin/netd on <+pid/sbin/setupd,+pid/sbin/zebra>
0 /sbin/udhcpc off <-net/vlan1/exist>
PID IDENT STATUS CONDITION (+ ON, ~ FLUX, - OFF)
=======================================================================
1419 /sbin/netd on <+pid/setupd,+pid/zebra>
0 /sbin/udhcpc off <-net/vlan1/exist>
```
Here we can see that `netd` is allowed to run since both its conditions
@@ -165,7 +164,7 @@ from `initctl cond show` again. The client will likely have failed to
start, but at least the condition is now satisfied.
There is also the `initctl cond dump` command, which dumps all known
conditions and their current status.
conditions, their current status, and their origin.
Internals