Due to an unfortunate name clash with the DirectFB project LiTE, the
libite (-lite) project had to change its header namespace from
lite/*.h -> libite/*.h
This patch adds support for the new namepace in Finit, triggered by the
define _LIBITE_LITE, from the .pc file read by pkg-config. This should
only be needed on systems that install libite without the compatibility
symlink lite -> libite/ in the staging include directory.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
- Use _PATH_foo for all condition paths, *with* trailing /
- Read condition file first, may not exist, in which case we save time
- Change from libte makepath() to mkpath(), this changes from hard-coded
0777 perms on all cond dirs to 0755 -- possible security fix
Signed-off-by: Joachim Wiberg <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>
- Increase size of resulting path buffer, unlikely a real problem
- Check return value from snprintf() to detect errors and truncation
- Add logit() function wrapper to initctl, maps to _e()/_d()/_pe()
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 most modern Linux systems /run is a tmpfs that replaces /var/run.
The latter is set up as a symlink to /run by the bootmisc.so plugin.
However, Finit conditions rely on the /var/run/finit/cond prefix, which
does not exist until bootmisc.so has run, which is *after* `mount -a`
has run. Therefore, to have working conditions before we run `mount -a`
we must normalize the path constructed by cond_path() to use either the
/run or /var/run (default) prefix.
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.
Time comparision should be >= not just >. May seem a bit silly to
nitpick like this since we're comparing nano seconds, but on systems
with no high-res timers this happens more often than you would like.
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
Joachim Wiberg