You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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
The text was updated successfully, but these errors were encountered:
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:
The next example uses the dbus-daemon:
The last example uses lxc-start to start container 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: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:
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 thelag1
.conf aswell:
The next example uses the dbus-daemon:
Same lxc-start example as above to start container 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:
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 (herefrr-
) to differentiate, instead relying on different install paths.Then the example would have to be changed like this:
The text was updated successfully, but these errors were encountered: