This is a generic implementation of a client-side logic of waiting until
a unit enters or leaves some state.
This is a more generic implementation of the WaitContext logic currently
in systemctl.c, and is supposed to replace it (a later commit does
this). It's similar to bus-wait-for-jobs.c and we probably should fold
that one into it later on.
This code is more powerful and cleaner than the WaitContext logic
however. In addition to waiting for a unit to exit this also allows us
to wait for a unit to leave the "maintainance" state.
This commit only implements the generic logic, and adds no users of it
yet.
timer units maintain state on disk (the persistent touch file), hence
let's expose cleaning it up generically with the new cleaning operation
for units.
This is a much simpler implementation as for the service unit type:
instead of forking out a worker process we just remove the touch file
directly. That should be OK since we only need to remove a single
(empty) file, instead of a recursive user-controlled directory tree.
Fixes: #4930
The implementation is pretty straight-foward: when we get a request to
clean some type of resources we fork off a process doing that, and while
it is running we are in the "cleaning" state.
This adds basic infrastructure to implement a "clean" operation for unit
types. This "clean" operation is supposed to remove on-disk resources of
units, and is supposed to be used in a later commit to clean our
RuntimeDirectory=, StateDirectory= and so on of service units.
Later commits will open this up to the bus, and hook up service units
with this.
This also adds a new generic ActiveState called UNIT_MAINTENANCE. It's
supposed to cover all kinds of "maintainance" state of units.
Specifically, this is supposed to cover the "cleaning" operations later
added for service units which might take a bit of time. This high-level,
generic, abstract state is called UNIT_MAINTENANCE instead of the
more specific "UNIT_CLEANING", since I think this should be kept open
for different operations possibly later on that could be nicely subsumed
under this (for example, maybe a recursive chown()ing operation could be
covered by this, and similar).
This new flag suppresses error if the top-level path specified doesn't
exist. This is useful since suppressing this on the caller side isn't
easy, since ENOENT migh be propagate for some reason from further inside
and we can't distuingish that.
While we are at it, also be a bit more careful witht the various
combinations of flags.
(Note that in some cases rm_rf() was already ignoring ENOENT from
unlink() or rmdir(), however that was pretty useless, since we always
open() the top-level path with O_DIRECTORY and if that hit ENOENT we
didn't ignore the failure).
This tweaks match installation a bit: the match callbacks are now only
called for messages read after the AddMatch() reply was received and
never anything already read before. Thus, installing a match gives you a
time guarantee: only messages received after it will be matched.
This is useful when listening to PropertiesChanged signals as an example
to ensure that only changes after the point the match was installed are
honoured, nothing before.
If AddMatch() doesn't work, let's destroy the slot for it too as soon as
we received the failure for it.
This way the mere existance of the slot tells us whether the AddMatch()
method call is still pending or is complete.
Let's count incoming messages and attach the current counter when we
first read them to the message objects. This allows us to nicely order
messages later on.
