When registering a service there is the option to set a custom PID file,
and even tell Finit to maintain that PID file in case the daemon doesn't
Until now there hasn't been a way to create custom conditions though ...
This patch leverages the new 'name:foo' argument to tas/run/services to
trigger condition 'svc/foo' (notice lack of path!) when a custom name is
set and either the default, or the custom, PID file is created.
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
Services, like dbus and teamd for instance, may create their PID files
in a subdirectory of /var/run (today often /run). E.g.,
- /var/run/teamd/a1.pid -- For aggregate A1
- /var/run/dbus/pid
- /var/run/lxc/foo.pid -- For container foo
This patch adds support for dynamically adding inotify watchers to any
new subdirectory created in /var/run (discarding too deep directories).
To match services in this directory the run/task/service/sysv stanza
must contain the pid:!/path/to/pidfile.pid syntax. This pid file name
is also used to create the condition this service asserts using the
following formula:
svc/ + <dirname of service> + <subdir and file without .pid>
E.g., the case of teamd (above) gives condition 'svc/usr/bin/teamd/a1'
The special case of dbus is interesting, since it may not be a special
case, but rather the norm for services using a subdirectory. It is
handled as follows; when a new subdirectory is detected, the directory
is scanned for files matching *.pid. Matching files follow the teamd
case. The directory is also scanned for 'pid', which then gives us the
condition 'svc/usr/bin/dbus'
One last example, illustrated by lxc-start, where we want to track the
condition for the LXC container foo. The service stanza:
service pid:!/run/lxc/foo.pid lxc-start -n foo -F -p /run/lxc/foo.pid -- Container foo
This command has no leading path so the condition is composed entirely
from the PID file location:
svc/ + '' + lxc/foo => svc/lxc/foo
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
This patch adds initial support for starting a SysV init script in a
runlevel, and stopping it when leaving a runlevel.
sysv [LVLS] <COND> /path/to/script.sh -- Optional Description
The SysV /etc/inittab file, which may use /etc/init.d, or /etc/rcN.d,
is still not supported. A separate plugin would be required for this,
see the documentation for more information.
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
Instead of changing the API of service_step(), and relying on all the
different callers to step again, we can schedule another event to do
this for us.
In addition to handling the cond_update() case this also handles all
other callers of service_step(). Ensuring that nested conditions do
trigger changes.
Also, reverting dddd45e fixes a minor regression in service_monitor()
which caused it to not clean up collected bootstrap tasks.
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
Reassert condition when an unchanged/unmodified process goes from
WAITING state to RUNNING. I.e. it had a condition that went to flux
during `initctl reload`, which drove it to WAITING and was then sent
SIGSTOP during reconf.
Also, on condition update, loop through all services until no more state
changes are observed. This allows long dependency chains of services to
resolve and actually go back to RUNNING state as intended whenever any
condition changes at runtime.
Signed-off-by: Jonas Johansson <jonasj76@gmail.com>
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
On systems with the new /run hierarchy the compat symlink from /var/run
may be missing, or not yet be set up by bootmisc.so. This patch adds a
layer of safety to the condition layer, both set and get cond ops now
perform an adjustmed of the condition path if needed.
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
On `initctl reload` we reassert conditions, i.e. bring each still viable
condition back in sync with the new reconf generation. This patch fixes
an assumption in the reassert() callback that caused the following nasty
transformation:
/run/finit/cond/net/lo/up --> /run/finit/cond/lo/up
The transformation was caused by the reassert() code assuming a /var/run
prefix rather than /run. We must check the actual runpath, or like this
patch does, use a path neutral way to find the base condition string.
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
The cond_init() function is called before the bootmisc.so plugin has
run. It is responsble for setting up the /var/run symlink to /run on
systems with the new layout. Therefore we must wrap COND_PATH with
pid_runpath() to create the correct runtime path.
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
The SVC_RECONF, SVC_LOST, SVC_START, and RUNLEVEL_CHANGE hooks are not
one-shot, they are also not regular conditions since there exist no
mechanism to reset them from flux.
One idea was to turn them into actions, but the lost + start hooks need
to be called multiple times per trigger, e.g. `initctl reload`, which
turned out to be non-trivial to implement right now.
Therefore, for (at least) the Finit v3.1 release these conditions have
been disabled ("nop") and ignored by Finit. Only actual C-style plugins
will be called.
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
- Add newline to cond generation ID, like PID files, easier when
debugging. Does not affect fscanf() in cond_get_gen()
- Update copyright years
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
TIL, using mtimes for tracking event orderings is a monumentally bad
idea (queue the nodding UNIX-beards). Mtimes are in wallclock time which
is not necessarily monotonically increasing. A user may adjust the time,
an NTP daemon will continously tune the clock and so on.
Instead, store an explicit generation number in each condition file,
which will be monotonically increased by finit on each reconf.
If you have lots of service/run/tasks using the same cmd it's impossible
to tell them apart in debug mode. This patch logs description as well
as cmd to improve on this situation a bit.
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
Joachim Nilsson