We don#t really support systems where XDG_RUNTIME_DIR is not supported for
systemd --user. Hence, let's always set our own XDG_RUNTIME_DIR for tests that
involve systemd --user, so that we know it is set, and that it doesn't polute
the user's actual runtime dir.
There's no point in first determining the drop-in file name path, then
forgetting it again, and then determining it again. Instead, just generated it
once, and then write to ti directly.
This allows dropping all user configuration and reverting back to the vendor
default of a unit file. It basically undoes what "systemctl edit", "systemctl
set-property" and "systemctl mask" do.
The code previously queries the state of a unit file, but was only interested
in the existance of it, hence let's use unit_file_exists() instead, the same
way the SysV compat code in systemctl does it.
The SysV compat code checks whether there's a native unit file before looking
for a SysV init script. Since the newest rework generated units will show up in
the unit path, and hence the checks ended up assuming that there always was a
native unit file for each init script: the generated one.
With this change the generated unit file directory is suppressed from the
search path when this check is done, to avoid the confusion.
Let's keep the code that manipulates LookupPaths together, and move
generator_binary_paths() to the end of the .h and .c files, since it is not
strictly related to that.
We should log about everything we don't expect.
Also, add a comment for one case were we do not log, on purpose, and make it
use a separate error code.
Move the search path check from the SysV service compat support into install.c
so that we can reuse the usual algorithm instead of rolling a private loop for
this.
Always warn if something fails, and clarify that the involved utility functions
do so in their name.
Drop the REBOOT_PARAM_FILE macro. We don't do this for other flag file paths
like this, so don't do this for this one either. The path isn't configurable
anyway, hence let's make this easier to read by avoiding this one indirection.
With this change the logic for placing transient unit files and drop-ins
generated via "systemctl set-property" is reworked.
The latter are now placed in the newly introduced "control" unit file
directory. The fomer are now placed in the "transient" unit file directory.
Note that the properties originally set when a transient unit was created will
be written to and stay in the transient unit file directory, while later
changes are done via drop-ins.
This is preparation for a later "systemctl revert" addition, where existing
drop-ins are flushed out, but the original transient definition is restored.
This patch adds a concept of a "control" unit file directory, which is supposed
to be used as place for unit file drop-ins created by "systemctl set-property"
(note that this directory is not actually hooked up to "systemctl set-property"
yet, that's coming in a later patch).
The rationale for this: previously changes made by the user and by "systemctl
set-property" were done in the same directory, which made semantics very
unclear: the changes made by "systemctl set-property" were applied instantly,
and their drop-ins only written to not lose settings on a later "systemctl
daemon-reload", while drop-ins made by the user would only be in effect after
"systemctl daemon-reload". This is particular problematic as the changes made
by "systemctl set-property" would really apply immediately without any respect
for the unit search path. This meant that using "set-property" could have an
effect that is lsot as soon as "daemon-reload" is issued, in case there was a
"later" drop-in already in place.
With this change the directories are seperated, and the "control" directory
always takes the highest priority of all, to avoid any confusion.
This is too confusing, as this funciton returns the paths to the generator
binaries, while usually when we refer to the just the "generator path" we mean
the generated unit files. Let's clean this up.
Previously, libxkbcommon was a compile-time option. When enabled the localed
binary would strictly depend on it, thus pulling in libxkbcommon and its
dependencies, which are non-trivial in size.
With this change we dlopen() libxkbcommon when it is available instead. If the
library is available behaviour is as before. However, if it isn't the system is
considered "headless", i.e. without local hardware and all attempts to set the
local keyboard configuration will be refused.
This is useful for general-purpose distributions which want to support
"headless" (such as container systems) and "full" systems with the same build.
