The advantage is that is the name is mispellt, cpp will warn us.
$ git grep -Ee "conf.set\('(HAVE|ENABLE)_" -l|xargs sed -r -i "s/conf.set\('(HAVE|ENABLE)_/conf.set10('\1_/"
$ git grep -Ee '#ifn?def (HAVE|ENABLE)' -l|xargs sed -r -i 's/#ifdef (HAVE|ENABLE)/#if \1/; s/#ifndef (HAVE|ENABLE)/#if ! \1/;'
$ git grep -Ee 'if.*defined\(HAVE' -l|xargs sed -i -r 's/defined\((HAVE_[A-Z0-9_]*)\)/\1/g'
$ git grep -Ee 'if.*defined\(ENABLE' -l|xargs sed -i -r 's/defined\((ENABLE_[A-Z0-9_]*)\)/\1/g'
+ manual changes to meson.build
squash! build-sys: use #if Y instead of #ifdef Y everywhere
v2:
- fix incorrect setting of HAVE_LIBIDN2
We would not consider symlinks in /etc/systemd/user/*.{wants,requires}/
towards the user unit being "enabled", because the symlinks were not
located in "config" paths. But this is confusing to users, since those units
are clearly enabled and will be started. So let's muddle the definition of
enablement a bit to include the paths only accessible to root when looking for
enabled user units.
Fixes#4432.
When running through systemd-analyze verify or with --test, we would
not run generators (environment or unit). But at the end, we would nuke
the generator dirs anyway.
Simplify things by actually running generators of both types, but redirecting
their output to a temporary directory. This has the advantage that we test more
code, and the verification is more complete.
Since now we are not touching the real generator directories, we also don't
delete them, which fixes#5609.
Why the strange name: the prefix is necessary to follow our own advice that
environment generators should have numerical prefixes. I also put -d- in the
name because otherwise the name was very easy to mistake with
systemd.environment-generator. This additional letter clarifies that this
on special generator that supports environment.d files.
So far, if either $HOME or $XDG_RUNTIME_DIR is not set we wouldn't use
either, and fail acquire_config_dirs() and acquire_control_dirs() in
their entireties. With this change, let's make use of the variables we
can acquire, and don't bother with the other.
Specifically this means: in both acquire_config_dirs() and
acquire_control_dirs() handle ENXIO from user_config_dir() and
user_runtime_dir() directly, instead of propagating it up and handling
it in the caller.
Let's use get_home_dir() for figuring out the home directory, so that
there's a good chance we succeed figuring out unit locations even if
$HOME isn't set.
Fixes: #5260
CID #1354671: char **l would be leaked.
Also rename l to paths, to make the code easier to read,
and do strv deduplication immediately when extending. No need to allocate
strings to remove them a few lines down.
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.
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.
Let's modernize these calls a bit.
Also, don't call them from user_dirs() anymore, as we already have both dirs in
the list a second time via the persistent_config and runtime_config function
parameters.
Previously, transient units were created below the normal runtime directory
/run/systemd/system. With this change they are created in a special transient
directory /run/systemd/transient, which only contains data for transient units.
This clarifies the life-cycle of transient units, and makes clear they are
distinct from user-provided runtime units. In particular, users may now
extend transient units via /run/systemd/system, without systemd interfering
with the life-cycle of these files.
This change also adds code so that when a transient unit exits only the
drop-ins in this new directory are removed, but nothing else.
Fixes: #2139
We use the root directory parameter while putting together the LookupPaths
structure, hence let's also store it in the structure as-is. That way we can
drop a parameter from half of the functions in install.c
Also, let's move the validation of the root paths into lookup_paths_init() so
that we can drop even more code from install.c
Previously, we had two enums ManagerRunningAs and UnitFileScope, that were
mostly identical and converted from one to the other all the time. The latter
had one more value UNIT_FILE_GLOBAL however.
Let's simplify things, and remove ManagerRunningAs and replace it by
UnitFileScope everywhere, thus making the translation unnecessary. Introduce
two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking
if we are running in one or the user context.
Let's add a seperate fields for the directories where we place runtime and
persistent configuration, so that we can use this in install.c (to be added in
a later commit), and we store path information in the same place everywhere.
A long time ago – when generators where first introduced – the directories for
them were randomly created via mkdtemp(). This was changed later so that they
use fixed name directories now. Let's make use of this, and add the genrator
dirs to the LookupPaths structure and into the unit file search path maintained
in it. This has the benefit that the generator dirs are now normal part of the
search path for all tools, and thus are shown in "systemctl list-unit-files"
too.
There are more than enough calls doing string manipulations to deserve
its own files, hence do something about it.
This patch also sorts the #include blocks of all files that needed to be
updated, according to the sorting suggestions from CODING_STYLE. Since
pretty much every file needs our string manipulation functions this
effectively means that most files have sorted #include blocks now.
Also touches a few unrelated include files.
get_current_dir_name() can return a variety of errors, not just ENOMEM,
hence don't blindly turn its errors to ENOMEM, but return correct errors
in path_make_absolute_cwd().
This trickles down into a couple of other functions, some of which
receive unrelated minor fixes too with this commit.
This adds support for caching harddisk passwords in the kernel keyring
if it is available, thus supporting caching without Plymouth being
around.
This is also useful for hooking up "gdm-auto-login" with the collected
boot-time harddisk password, in order to support gnome keyring
passphrase unlocking via the HDD password, if it is the same.
Any passwords added to the kernel keyring this way have a timeout of
2.5min at which time they are purged from the kernel.
It's primarily just a property of the Manager object after all, and we
try to refer to PID 1 as "manager" instead of "systemd", hence let's to
stick to this here too.
With debugging on, sysv-generator would print the full set of
lookup paths for *every* sysv script.
While at it, pass LookupPaths as a pointer in sysv-generator,
and constify it everywhere.
This patch removes includes that are not used. The removals were found with
include-what-you-use which checks if any of the symbols from a header is
in use.
Generators are different than unit files: they are never automatically
generated, so there's no point in allowing /etc to override /run. On
the other hand, overriding /etc might be useful in some cases.
Sometimes it is necessary to stop a generator from running. Either
because of a bug, or for testing, or some other reason. The only way
to do that would be to rename or chmod the generator binary, which is
inconvenient and does not survive upgrades. Allow masking and
overriding generators similarly to units and other configuration
files.
For the systemd instance, masking would be more common, rather than
overriding generators. For the user instances, it may also be useful
for users to have generators in $XDG_CONFIG_HOME to augment or
override system-wide generators.
Directories are searched according to the usual scheme (/usr/lib,
/usr/local/lib, /run, /etc), and files with the same name in higher
priority directories override files with the same name in lower
priority directories. Empty files and links to /dev/null mask a given
name.
https://bugs.freedesktop.org/show_bug.cgi?id=87230
