If multiple RestrictAddressFamilies= settings, some of them are
whitelist and the others are blacklist, are sent to bus, then parsing
result was corrupted.
This fixes the parse logic, now it is the same as one used in
load-fragment.c
If multiple SystemCallFilter= settings, some of them are whitelist
and the others are blacklist, are sent to bus, then the parse
result was corrupted.
This fixes the parse logic, now it is the same as one used in
load-fragment.c
We need to connect to hostnamed, so a private bus connection is no good.
It'd be simpler to use the normal bus connection unconditionally, but
that'd mean that e.g. systemd-analyze set-log-level might not work in
emergency mode. So let's keep trying to use the private connection except
for "plot".
Fixes#7667.
Since systemd v236, several Arch users complained that
systemd-cryptsetup-generator exits with an OOM error and that it
prevents the boot from continuing.
Investigating the diff of cryptsetup-generator between v235 and v236 I
noticed that create_disk allowed for the `password` and `filtered`
variables to be NULL (they're handled with `strempty()`) but not their
`*_escaped` versions, and returned OOM errors in those cases.
Fix this by checking that the input string is non-NULL before deciding
that `specifier_escape` had an OOM error.
I could not test this fix myself, but some users have reported success.
Downstream bug: https://bugs.archlinux.org/task/56733
Translated taint message.
Also added a blank line before "Current system is tagged" for better
visual separation between current system state and tags description.
Up until now, the behaviour in systemd has (mostly) been to silently
ignore failures to action unit directives that refer to an unavailble
controller. The addition of AssertControlGroupController and its
conditional counterpart allow explicit specification of the desired
behaviour when such a situation occurs.
As for how this can happen, it is possible that a particular controller
is not available in the cgroup hierarchy. One possible reason for this
is that, in the running kernel, the controller simply doesn't exist --
for example, the CPU controller in cgroup v2 has only recently been
merged and was out of tree until then. Another possibility is that the
controller exists, but has been forcibly disabled by `cgroup_disable=`
on the kernel command line.
In future this will also support whatever comes out of issue #7624,
`DefaultXAccounting=never`, or similar.
Systemd services are permitted to be scripts, as well as binary
executables.
The same also applies to the underlying /sbin/mount and /sbin/swapon.
It is not necessary for the user to consider what type of program file
these are. Nor is it necessary with systemd-nspawn, to distinguish between
init as a "binary" v.s. a user-specified "program".
Also fix a couple of grammar nits in the modified sentences.
Otherwise, setting udev_log=debug in /etc/udev/udev.conf has no effects since
systemd-udevd is built with LOG_REALM=LOG_REALM_UDEV.
However using LOG_REALM_UDEV (for libudev_core) reveals another similar bug for
udevadm which should also define LOG_REALM_UDEV.
This code is executed before we parse command line/configuration
parameters, hence let's not use arg_system to figure our how to clean up
things, but instead PID == 1. Let's move that check inside of the
function, to make things a bit more robust abstract from the outside.
Also, let's add a log message about this, that was so far missing.
Let's place them in initialize_runtime(), where they appear to fit best.
Effectively this is just a move a little bit down, swapping places with
log_execution_mode(), which should require neither call to be done
first.
Note that changes the conditionalization a bit for these calls, from
(PID == 1) to (arg_system && arg_action == ACTION_RUN). At this point this is pretty much the same
however, as we don't allow PID 1 without ACTION_RUN and without
arg_system set, safety_checks() ensures that.
It's part of finalizing our runtime parameters, hence let's move this
into load_configuration() after we loaded everything else. This is safe,
since we don't use it between the location where it was and where we
place it now yet.
This just sets up some variables the loaded configuration will then
modify. Let's invoke it hence right before loading the configuration.
This moves the initialization just a tiny bit later, but that shouldn't
matter, since we never access it in-between.
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Felipe Sateler
Jan Alexander Steffens
Henrik Grindal Bakken
Sergey Ptashnick
Chris Down
Piotr Drąg
Alan Jenkins
Franck Bui