Redesign condition subsystem

[troglobit]

Condition System Redesign

The condition system introduced in v1.x has gathered quite a bit of cruft and is very difficult to grasp, not only for newcomers to Finit, but also to the maintainer.

This is an attempt to redesign them.

First we present the current state of affairs up to Finit v3.2-rc3. Then we detail the proposed new design for Finit 4.

Before

The service condition name is constructed from the 'pid/' prefix, the dirname of the svc->cmd, e.g., '/usr/bin/teamd' => 'usr/bin', and the service's pid:filename, including an optional subdirectory, without the .pid extension.

The following example uses the team (aggregate) service:

service pid:!/run/teamd/lag1.pid /usr/bin/teamd -f /etc/teamd/lag1.conf

=> svc/' + 'usr/bin' + 'teamd/lag1' => <svc/usr/bin/teamd/lag1>

The next example uses the dbus-daemon:

service pid:!/run/dbus/pid /usr/bin/dbus-daemon

=> svc/' + 'usr/bin' + 'dbus' => <svc/usr/bin/dbus>

The last example uses lxc-start to start container foo:

service pid:!/run/lxc/foo.pid lxc-start -n foo -F -p /run/lxc/foo.pid -- Container foo

=> svc/' + '' + 'lxc/foo' => <svc/lxc/foo>

After

Monitored services in Finit are identified using the tuple (NAME,ID), where NAME is the basename of the path to a service and ID is optional :ID string.

The pidfile plugin scans all files with the .pid in /run and all its subdirectories. For each PID found the plugin pairs it with the registered service (if any). A service may of course already have specified a custom path to the PID file using the existing syntax:

pid[:[!][/path/to/]filename[.pid]]

If that is specified Finit will only use that for the service, even if turns out to be wrong. Conditions for the service will then not be asserted properly.

The new conditions use <pid/...> instead of the old <svc/...> and, compared to previously, are formed using the unique tuple mentioned previously.

The following example uses the team (aggregate) service:

service teamd -f /etc/teamd/lag1.conf

=> pid/' + 'teamd => <pid/teamd>

Adding a second aggregate lag2 requires using the finit :ID syntax to facilitate differentiating between the two teamd instances. For the sanity of the sysadmin it is recommended to extend the lag1 .conf as
well:

service :1 teamd -f /etc/teamd/lag1.conf
service :2 teamd -f /etc/teamd/lag2.conf

=> <pid/teamd:1>
=> <pid/teamd:2>

The next example uses the dbus-daemon:

service pid:!/run/dbus/pid /usr/bin/dbus-daemon

=> pid/' + 'dbus-daemon' => <pid/dbus-daemon>

Same lxc-start example as above to start container foo:

service :foo lxc-start -n foo -F -p /run/lxc/foo.pid -- Container foo

=> pid/' + 'lxc-start:foo' => <pid/lxc/foo>

Another real-world example is to run both FRR and Quagga on the same system. In both cases we start ripd only when the zebra routing daemon has started up properly:

service log                     zebra -A 127.0.0.1 -- Quagga Zebra routing daemon
service log <pid/zebra>         ripd  -A 127.0.0.1 -- Quagga RIP daemon

service log                 frr-zebra -A 127.0.0.1 -- Frr Zebra routing daemon
service log <pid/frr-zebra> frr-ripd  -A 127.0.0.1 -- Frr RIP daemon

The Quagga daemons create their PID files in /run/quagga/, and the FRR daemons in /run/frr. If the daemon's didn't have an exec prefix (here frr-) to differentiate, instead relying on different install paths.
Then the example would have to be changed like this:

service log               :1 /quagga/zebra -A 127.0.0.1 -i /run/quagga/zebra.pid
service log <pid/zebra:1> :1 /quagga/ripd  -A 127.0.0.1 -i /run/quagga/ripd.pid

service log               :2 /frr/zebra    -A 127.0.0.1 -i /run/frr/zebra.pid
service log <pid/zebra:2> :2 /frr/ripd     -A 127.0.0.1 -i /run/frr/ripd.pid