The general idea is that when a unit file is "linked" (i.e. installed by
symlinking from outside of the search paths), the *destination* name is
irrelevant. It doesn't even have to be a valid unit name, or to match the type
or instance value. The obvious collorary is that we shouldn't look at the
symlink destination name to derive the unit name, instance value, or anything
else at all.
When building the name map, when we find a linked unit (possibly at the end
of a series of alias redirects), store the *source* of the final symlink as the
fragment path. This has two effects:
- we stop looking at the *target* file name to derive unit info, i.e. actually
implement the stuff described in the first paragraph.
- we load the unit fragment through the symlink. If someone were to remove the
symlink, we'll not load the unit. This seems like the right thing.
Fixes#18058.
Before this change, we were generally quite confused about unit alises for
linked units. Fortunately most poeple use the same symlink source and target,
so in practice we wouldn't hit this too often.
In unit_load_fragment() a comment is added to explain what we're doing there.
Docker doesn't set $container, so it cannot be detected that way. Instead, we
check for presence of /.dockerinit, which it creates. Podman does set
$container, but some Red Hat images (in particular, Fedora images) override
$container to equal "oci". So to correctly detect Podman containers, we check
for presence of /run/.containerenv, which is created by Podman and is now the
official way to get information about the container from within the container.
Fixes https://github.com/systemd/systemd/issues/15393
We'd return -1 (-EPERM), even though we have a general rule to use real errno
values. The particular case that caught my attention was:
$ sudo udevadm control -l asdf
Failed to parse log priority 'asdf': Operation not permitted
... but "git grep 'r =.*_from_string' src/" return 110 hits. Confusingly, some
of the _from_string functions already return a proper errno value, so not all
of those are broken, but probably quite a few.
As suggested in https://github.com/systemd/systemd/pull/11484#issuecomment-775288617.
This does not touch anything exposed in src/systemd. Changing the defines there
would be a compatibility break.
Note that tests are broken after this commit. They will be fixed in the next one.
There may be situations where a cgroup should be protected from killing
or deprioritized as a candidate. In FB oomd xattrs are used to bias oomd
away from supervisor cgroups and towards worker cgroups in container
tasks. On desktops this can be used to protect important units with
unpredictable resource consumption.
The patch allows systemd-oomd to understand 2 xattrs:
"user.oomd_avoid" and "user.oomd_omit". If systemd-oomd sees these
xattrs set to 1 on a candidate cgroup (i.e. while attempting to kill something)
AND the cgroup is owned by root, it will either deprioritize the cgroup as
a candidate (avoid) or remove it completely as a candidate (omit).
Usage is restricted to root owned cgroups to prevent situations where an
unprivileged user can set their own cgroups lower in the kill priority than
another user's (and prevent them from omitting their units from
systemd-oomd killing).
sd-boot has a copy of a subset of codes from libbasic. This makes
sd-boot share the code with libbasic, and dedup the code.
Note, startswith_no_case() is dropped from sd-boot, as
- it is not used,
- the previous implementation is not correct,
- gnu-efi does not have StrniCmp() or so.
Let's tighten the logic behind path_extract_filename() a bit: first of
all, refuse all cases of invalid paths with -EINVAL. More importantly
though return a recognizable error when a valid path is specified that
does not contain any filename. Specifically, "/" will now result in
-EADDRNOTAVAIL.
This changes API, but none of the existing callers care about the return
value, hence the change should be fine.
CLI tools may be used in a script. E.g., a script for monitoring a
service may use `systemctl`. Previously, if the kernel command line has
e.g. systemd.log-level=debug, then systemctl in the script produces
debugging logs when the script is invoked by a .service unit, but does
not when the script is running in a terminal. Then,
https://github.com/systemd/systemd/pull/18281#discussion_r561697482,
> I expect users to be (negatively) surprised.
In the previous commit, $SYSTEMD_EXEC_PID= is introduced. Then, we can
now detect whether a command is directly invoked by systemd or through
a script. Let's skip reading the kernel command line when a command is
invoked through a script.
This effectively reverts 41d1f469cf.
Before this, e.g., `networkctl reload` invoked by `systemctl reload systemd-networkd.service`
does not produce debugging logs even if systemd.log-level=debug is set. This fixes
the issue.
The target is update-syscall-tables, so let's call the script
update-syscall-tables.sh to reduce the cognitive overhead when
trying to find the right file.
Upstream uses .text, but this is rather unusual. Let's use .txt as the usual
suffix for text files. This tells various editors and such that the file should
be treated as plain text. I also want to a script to summarize license status,
and having an easy-to-recognize suffix makes this easier.
Even though many of those scripts are very simple, it is easier to include
the header than to try to say whether each of those files is trivial enough
not to require one.
If the file was always generated on the fly, the header would be pointless.
But since we distribute it, it should be there. C.f.
a0e150b2f4.
This was forgotten in 35b42e5600.
Lennart Poettering
Pierre Dubouilh
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Luca Boccassi
Sergey Bugaev
Anita Zhang
Deepak Rawat
Susant Sahani