In Finit v4.5 we've moved the start of rc.local and runparts to the
transtion from bootstrap to multi-user, so we must give it time to
finish.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This odd little feature makes it possible to declare run/tasks with a
condition that does not block Finit transitioning from bootstrap to the
next runlevel.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Regression in v4.5 release cycle, no changelog notice needed.
Reported as part of issue #378 by Alexander Zangerl.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This change allows us to support constructs like this:
RUNDIR=/var/run/somesvc
DAEMON_ARGS=--workdir $RUNDIR --other-args...
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Introduced back in v4.3-rc2, 82cc10be8, the support for automatic
service conditions have had a weird and unintended behavior. Any
change in state (see doc/svc-machine.png) caused Finit to clear
out *all* previously acquired service conditions.
However, when moving between RUNNING and PAUSED states, a service
should not have its conditions cleared. The PAUSED state, seen
also by all conditions moving to FLUX, is only temporary while an
`initctl reload` is processed. If a service has no changes to be
applied it will move back to RUNNING.
Also, we cannot clear the service conditions because other run/task
or services may depend on it and clearing them would cause Finit to
SIGTERM these processes (since they are no longer eligible to run).
This patch not only adds this pre-condition to `cond_clearn()`, it
also clarifies which state (before or after) the particular code
is interested in.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Renamed .conf file for udev/mdev etc. caused 'mdev -df' to start in
tests. This fix closes that again since none of that is needed in
our small namespaced world.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Alexander Zangerl reports that <service/foo/STATE> conditions seem to be
removed when calling `initctl reload`, even though no .conf changes have
been made.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The delayed matcehd works when all run/task/services provide their own
unique identity, but for replacements this is sometimes not the case.
Example from system/10-hotplug.conf.in:
run nowarn conflict:udevd,mdev cgroup.init name:coldplug <service/mdevd/ready> \
[S] mdevd-coldplug -- Cold plugging system
vs
run nowarn conflict:udevd,mdevd cgroup.init name:coldplug if:!mdevd <service/mdev/running> \
[S] @pkglibexecdir@/coldplug -- Cold plugging system
Here they both provide the <run/coldplug/*> conditions, and if the first
is loaded, because we found mdevd, then we should not attempt to load
this one.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The updated 10-hotplug.conf now ensures modules are loaded, so we no
longer need the modprobe.so plugin to be enabled by default.
Also, update the hotplug "plugin" description, it is kept entirely
for backwards compatibility reasons after the plugin was converted
to 10-hotplug.conf.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This commit replaces the `mdev -s` call to populate the device tree with
the "new" `mdev -df` daemon mode, introduced in BusyBox 1.31.0, 2019.
In daemon mode mdev listens to kernel uevents, replacing the hotplug use
of mdev. After creating the netlink socket, 'mdev -df' performs the same
initial scan as 'mdev -s' did.
To perform device (re)discovery, module loading and setup, including any
firmware loading, a coldplug operation is typically required. This is
done by the new /libexec/finit/coldplug script, by Alexander Zangerl.
Unlike 'mdevadm settle', mdev does not offer any mechanism to detect when
the discovery operation is done: on slower systems the triggering side,
the coldplug script, often completes quite a bit earlier than mdev's
uevent processing. I.e., depending on <run/coldplug/success> is not an
indicator of all devices having been (re)discovered and fully set up.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
On some systems udev may very well take more than five seconds to complete.
Probing modules, loading firmware, etc. Note, the timeout only sets the
maximum wait time.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The directory may hold various custom generated conditions that are not
managed by Finit. Not being able to remove the directory is not a
critical error.
finit[1]: cond_delpath():Failed removing condition path /var/run/finit/cond/: Directory not empty
Therefore, ignore ENOENT and ENOTEMPTY and log everything/anything else.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This fixes the regression in the tests, which runs in a very stripped
down world without tmpfiles.d etc.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This adds a new function conf_save_service() replacing service_register() for
plugins and bundled services like watchdogd, keventd, runparts, etc.
The benefits to this change are several:
- Plugin/Bundled services no longer risk starting before udev or other
critical services/task have started
- Definitions can be overridden by an administrator (see docs)
- Increases visibility (user: where are all these services coming from?)
Previously the origin (file the service was loaded from) was NULL.
- Adds another level of extensibility to Finit
The most notable change is that dbus is no longer started before udevd.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The system/10-hotplug.conf needs to index its calls to udevadm for all
calls to udevadm, not just the trigger calls. Otherwise the first
udevadm is overloaded with all subseequent (unindexed) udevamd stanzas.
Also, make sure all udevadm calls to settle/reload are hidden.
Fix#372
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The if: statement, introduced in v4.4, allows for discarding run/task/services
that depend on other services, based on that service's name, or condition.
Discarding in this context means unloading from the configuration.
At runtime, however, it has proven quite useful to be able to conditionally
qualify a run/task/service based on a condition. Consider this example from
the Infix operating system:
run name:startup log:prio:user.notice \
[S] <pid/sysrepo> confd -b --load startup-config -- Loading startup-config
run name:failure log:prio:user.critical if:<usr/fail-startup> \
[S] <pid/sysrepo> confd --load failure-config -- Loading failure-config
The two run statements reside in the same .conf file so Finit runs them in true
sequence. If loading the file `startup-config` fails confd sets the condition
usr/fail-startup, thus allowing the next run statement to load `failure-config`.
Notice the difference between <pid/sysrepo> condition and if:<usr/fail-startup>.
The former is a condition for starting and the latter is a condition to check if
a run/task/service is qualified to even be considerered. The best comparison is
with the [runlevel] option, it too is used to qualify.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Joachim Wiberg