wt/finit
1
0
Fork 0
mirror of https://github.com/troglobit/finit.git synced 2026-10-02 05:52:48 +07:00
Code Issues Packages Projects Releases Wiki Activity

doc: update section on pidfile.so plugin

Browse Source 
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This commit is contained in:
Joachim Wiberg
2021-02-11 21:23:09 +01:00
parent 782da9d091
commit e843be4540
1 changed files with 35 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/conditions.md
+35 -21
View File
@@ -31,7 +31,7 @@ service to run.
### Example
```shell
service [2345] <pid/sbin/setupd,pid/sbin/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
@@ -95,20 +95,34 @@ Built-in conditions:
Composition
-----------
The `pid/` conditions can be quite tricky to understand. They are
generated by the Finit `pidfile.so` plugin and are composed from the
daemon's path and the pidfile name (and path).
The `pid/` conditions are generated by the Finit `pidfile.so` plugin and
composed from a service's `name:` and `:id`. By default the basename of
the daemon and the empty string.
| **service** | **pid:** | **pidfile path** | **svc condition** |
|--------------------------------------|-----------------|------------------|-------------------|
| /sbin/foo | | /run/foo.pid | pid/sbin/foo |
| /sbin/bar -p /run/baz.pid | pid:baz | /run/bas.pid | pid/sbin/baz |
| lxc-start -n foo -p /run/lxc/foo.pid | pid:lxc/foo.pid | /run/lxc/foo.pid | pid/lxc/foo |
| /usr/bin/dbus-daemon | pid:dbus/pid | /run/dbus/pid | pid/usr/bin/dbus |
| **service** | **condition** |
|----------------------------------------------------|------------------|
| /sbin/foo | pid/foo |
| /sbin/bar -p /run/baz.pid | pid/bar |
| name:lxc :foo lxc-start -n foo -p /run/lxc/foo.pid | pid/lxc:foo |
| /usr/bin/dbus-daemon | pid/dbus-daemon |
| :222 dropbear -p 222 | pid/dropbear:222 |
Omitting the `pid:` to run/task/service/sysv stanza means Finit will
guess the pidfile path based on `/run/` and the basename(1) of the
program.
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
for Finit to reassert their conditions.
Daemons that don't create PID files, or fail to touch them on reload,
can be worked around by using the `pid:/path/to/file.pid` syntax in
the service stanza for the daemon. It is far from optimal since any
synchronization of depending services may fail due to the daemon not
having reinitialized/created their IPC sockets, or similar.
> **Note:** in versions of Finit prior to v4, the PID conditions were
> called 'svc' conditions, and they were far more complex.
Debugging
@@ -125,11 +139,11 @@ conditions that are not satisfied. Listed as `off` below.
**Example:**
```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>
~ # 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>
```
Here we can see that `netd` is allowed to run since both its conditions
@@ -141,9 +155,9 @@ To fake interface `vlan1` suddenly appearing, and test what happens to
`udhcpc` we can enable debug mode and assert the condition, like this:
```shell
~ # initctl debug
~ # mkdir -p /var/run/finit/cond/net/vlan1
~ # cp /var/run/finit/cond /var/run/finit/cond/net/vlan1/exist
~ # initctl debug
~ # mkdir -p /var/run/finit/cond/net/vlan1
~ # cp /var/run/finit/cond /var/run/finit/cond/net/vlan1/exist
```
Then watch the console for the debug messages and then check the output