Currently, when running "systemctl preset-all --root=xxx" in mkosi
to enable/disable units for initrds, the system presets are used.
The problem with this approach is that the system presets are written
for the system, and that is not necessarily ideal for an initrd, but we
still want to use the same packages in the initrd that we install in the
system, so let's introduce a separate directory for initrd presets which
is used to pick up preset files from when we detect that we're configuring
an initrd (by looking for /etc/initrd-release).
We also introduce a systemd preset file for the initrd, which is based on
the system one, except with all the stuff unnecessary for the initrd removed.
For libsystemd's headers, the changes made depend on whether the
header is installed or not. For installed headers, the only change
made is that commonly included headers were moved to _sd-common.h.
For these headers, there should be no noticeable change in behavior
when including them. For non-installed headers, includes were replaced
with forward declarations where possible as usual.
Split out of #37344.
Now that the necessary functions from log.h have been moved to macro.h,
we can stop including log.h in macro.h. This requires modifying source
files all over the tree to include log.h instead.
This is a minor compat break, but given the slow adoption of the
sd-path.h APIs I think it's one we should take. Basically, the idea is
that if the user provides a suffix path with a trailing slash (thus
encoding in the path that the last element must be a dir), we should
keep it in place, and not suppress it, in order to not willy nilly
reduce the amount of information contained in the path.
Simplifications that do not alter meaning, and do not suppress
information should be fine to apply to a path, but otherwise we really
should be conservative on this.
This is the only place where xdg_user_dir() is needed and
makes sense. All other invocations have been replaced with
user_search_dirs() - see previous commits for details.
* Rename user_dirs() -> user_unit_search_dirs() and port to
user_search_dirs()
* Use STRV_IFNOTNULL to guard paths that could be NULL,
assert otherwise
xdg_user_dirs() doesn't seem well-organized currently.
In all other xdg_user_*() funcs we assume /etc/xdg/systemd
to be a symlink to /etc/systemd/, hence it is the odd one out.
Also, when the relevant envvar is unset, it only returns
the global search dirs.
sd_path_lookup() actually covers this nicely with SD_PATH_SEARCH_*,
where the combined search paths (from user home and system) are used.
Therefore, let's introduce a wrapper for that, and deprecate xdg_user_dirs()
(would be removed in later commits).
Note that -ENXIO reported by xdg_user_config_dir() is now properly
propagated rather than ignored, as unlike XDG_RUNTIME_DIR, XDG_CONFIG_HOME
has a default value hence ENXIO is not really expected.
I'm working on the transition to merged sbin in Fedora. While the transition is
happening (and probably for a while after), we need to compile systemd with
split-bin=true to support systems upgraded from previous versions. But when the
system has been upgraded and already has /usr/sbin that is a symlink, be nice
and give $PATH without sbin.
We check for both /usr/sbin and /usr/local/sbin. If either exists and is not a
symlink to ./bin, we retain previous behaviour. This means that if both are
converted, we get the same behaviour as split-bin=false, and otherwise we
get the same behaviour as before.
sd-path uses the same logic. This is not a hot path, so I got rid of the nulstr
macros that duplicated the logic.
In various tools and services we have a per-system and per-user concept.
So far we sometimes used a boolean indicating whether we are in system
mode, or a reversed boolean indicating whether we are in user mode, or
the LookupScope enum used by the lookup path logic.
Let's address that, in introduce a common enum for this, we can use all
across the board.
This is mostly just search/replace, no actual code changes.
The naming of variables is very inconsistent. I tried to use more
modern style naming (UNDERSCORED_TITLE_CASE), but I didn't change existing
names too much. Only SYSTEM_DATA_UNIT_PATH is renamed to SYSTEM_DATA_UNIT_DIR
to match SYSTEM_CONFIG_UNIT_DIR.
We generally don't support prefix being != /usr, and this is hardcoded
all over the place. In the systemd.pc file it wasn't so far. Let's
adjust this to match the rest of the codebase.
Clean up the naming of the sd-path enums. Previously, the more recently
added fields where named in the form SD_PATH_xyz_DIR and
SD_PATH_xyz_PATH, while the older fields where called just SD_PATH_xyz
and SD_PATH_SEARCH_xyz. Let's clean this up, to come to a more unified
way how we name this stuff.
I opted to stick to the old naming, i.e. dropthe suffixes. It's a bit of
a bike-shedding question of course, but I think there's a good reason to
avoid the additional DIR and PATH suffixes: the enum prefix contains
"PATH" anyway (i.e. "SD_PATH_"), so including PATH twice in each name is
redundant. Moreover, the key difference between the enums with the "dir"
and the "path" in the name is that the latter are *seach* paths, and I
think this is better emphasized by sticking to the "SEARCH" in the name.
Moreover dropping the suffixes makes the identifiers a lot shorter, in
particular in the "systemd-path" list output. And that's always good.
This means the naming pkgconfig file and in sd-path slightly deviate
(though the mapping is very simple), but I think that's OK, given that
this is developer facing and not user facing.
ROOTPREFIX doesn't include the trailing /, hence add it in where needed.
Also, given that sysctl.d/, binfmt.d/, sysusers.d/ are generally
accessed before /var/ is up they should use ROOTPREFIX rather than
PREFIX. Fix that.
So far we had various ad hoc APIs to query search paths:
systemd-analyze unit-paths, lookup_paths_log(), the pkgconfig file,
debug logs emitted by systemd-analyze cat-config.
But answering a simple question "what is the search path for tmpfiles,
sysusers, .network files, ..." is surprisingly hard.
I think we should have an api that makes it easy to query this. Pkgconfig is
not bad, but it is primarily a development tool, so it's not available in many
context. Also it can't provide support for paths which are influenced by
environment variables, and I'd like to be able to answer the question "what is
the search path for ..., assuming that VAR_FOO=... is set?".
Extending sd-path to support more of our internal paths seems to be most
flexible solution. We already have systemd-path which provides a nice
way to query, and we can add stuff like optional descriptions later on.
We we essentially get a nice programmatic and commmandline apis for the price
of one.
The two functions were duplicating a lot of functionality and more
importantly, they both had explicit lists of types which are search
paths. I want to add more types, and I don't want to have to remember
to add them to both lists.
I think the two names were both pretty bad. They did not give a proper hint
what the difference between the two functions is, and sd_path_home sounds like
it is somehow related to /home or home directories or whatever, when in fact
both functions return the same set of paths as either a colon-delimited string
or a strv. "_strv" suffix is used by various functions in sd-bus, so let's
reuse that.
Those functions are not public yet, so let's rename.
DaanDeMeyer
Lennart Poettering
Mike Yuan
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
David Tardon
Yu Watanabe