They already were mostly ordered alphabetically, but some disorder
snuck in.
Also, fix formatting. Some options were described using "--" prefixes, which
looks like the text was just copied from crypttab(8).
Normally this happens automatically, but if it happened that both targets were
pulled in, even though there were no cryptsetup units, they could be started
in reverse order, which would be somewhat confusing. Add an explicit ordering
to avoid this potential issue.
Seems to be some kind of confusion in gcc. Insteading of playing whack-a-mole and
adding work-arounds in code, let's adjust the compilation options instead.
Fixes#6119, replaces #6657.
Newer kernels will emit uevents with "bind" and "unbind" actions. These
uevents will be issued when driver is bound to or unbound from a device.
"Bind" events are helpful when device requires a firmware to operate
properly, and driver is unable to create a child device before firmware
is properly loaded.
For some reason systemd validates actions and drops the ones it does not
know, instead of passing them on through as old udev did, so we need to
explicitly teach it about them.
If a path passes though an autofs filesystem, then accessing
the path might trigger and automount. As systemd-tmpfiles is run before
the network is up, and as automounts are often used for networked
filesystems, this can cause a deadlock.
So chase_symlinks is enhance to accept a new flag which tells it
to check for autofs, and return -EREMOTE if autofs is found.
tmpfiles is changed to check just before acting on a path so that it
can avoid autofs even if a symlink was created earlier by tmpfiles
that would send this path through an autofs.
This fixes a deadlock that happens when /home is listed in /etc/fstab as
x-systemd.automount for an NFS directory.
If a unit file contains multiple CapabilityBoundingSet= or
AmbientCapabilities= lines, e.g.,
===
CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=~CAP_B CAP_C
===
before this commit, it results all capabilities except CAP_C are set to
CapabilityBoundingSet=, as each lines are always merged by OR.
This commit makes lines prefixed with ~ are merged by AND. So, for the
above example only CAP_A is set.
This makes easier to drop capabilities with drop-in config files.
systemctl would try to load the properties of the unit, which is impossible
for template names, and the whole operation would fail. It seems that this
regression was introduced in 00c83b4300.
Export the part of unit_find_paths() responsible for locating instance unit
fragments and reuse it from unit_exists() to fix the handling of template
units.
Fixes#6412.
On thinkpads there are two rfkill devices for bluetooth. The first is an
ACPI switch which powers down the USB dongle and the second one is the
USB dongle itself. So when userspace decides to enable rfkill on all
devices systemd would randomly save the soft block state of the USB
dongle. This later causes issue when re-enabling the devie as
systemd-rfkill would put the USB dongle into soft block state right
after the ACPI rfkill switch is unblocked by userspace.
The simple way to avoid this is to not store rfkill changes for devices
that disappear shortly after. That way only the "main" ACPI switch will
get stored and systemd-rfkill will not end up blocking the device right
after it is being added back again.
Let's clean up the checking for the various ExecOutput values a bit,
let's use IN_SET everywhere, and the same concepts for all three bools
we pass to dprintf().
913c1916 changed _ACTION_INVALID to negative, changing the enum to a
signed type. Take care to avoid comparing it with an unsigned type.
../src/systemctl/systemctl.c: In function ‘start_unit’:
../src/systemctl/systemctl.c:3107:35: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
assert(arg_action < ELEMENTSOF(action_table));
Now we don't support tunnels to be created without a .network file
that is we need a interface index.
This work allows tunnel to be created without a ifindex.
Closes#6695
The irreversible job mode is required to ensure that shutdown is not
interrupted by the activation of a unit with a conflict.
We already used the correct job mode for `ctrl-alt-del.target`. But not
for `exit.target` (SIGINT of user manager). The SIGRT shutdown signals
also needed fixing.
Also change SIGRTMIN+0 to isolate default.target, instead of starting
it. The previous behaviour was documented. However there was no reason
given for it, nor can we provide one. The problem that isolate is too
aggressive anywhere outside of emergency.target (#2607) is orthogonal.
This feature is "accessible by different means and only really a safety
net"; it is confusing for it to differ from `systemctl default` without
explanation.
`AllowIsolate=yes` is retained on poweroff.target etc. for backwards
compatibility.
`sigpwr.target` is also an obvious candidate for linking to a shutdown
target. Unforunately it is also a possible hook for implementing some
logic like system V init did, reading `/etc/powerstatus`. If we switched
to starting `sigpwr.target` with REPLACE_IRREVERSIBLY, attempts to run
`systemctl shutdown` from it would fail, if they had not thought to set
`DefaultDependencies=no`. We had provided no examples for `sigpwr`, and
the whole idea is cruft to keep legacy people happy. For the moment, I
leave `sigpwr` alone, with no risk of disrupting anyone's
previously-working, half-working, or untested setup.
Fixes#6484. See also #6471
The comment here was misleading: the job can fail to enqueue for reasons
other than the target not existing.
The fallback caused an error to be logged, and dates back to when the
"user" directory was named "session". units/session/exit.target was added
later the same year.
This is consistent with the documentation (man systemd), and the handling
of similar signals. It's also consistent with `systemctl exit`, which is
what most people would expect.
It's like Manager.PowerOff(), which does not start poweroff.target.
Instead, the dbus methods are used for `systemctl --force exit`
or `systemctl --force poweroff`. They shut down the system without
processing individual unit's ExecStop or TimeoutStopSec.
If true randomness is needed before udev is triggered, which would load
virtio_rng, reading /dev/random takes forever and the boot stalls for a
long time.
start_unit() is a little tangled. There's an easy part we can untangle,
then readers can concentrate on the more necessary complexity.
* Derive (method, action, mode) more clearly, as disjoint cases based on
the command. Don't rely on action_table[_ACTION_INVALID].target being
implicitly initialized to NULL.
verb_to_method() is now only used on one case, but not because I strongly
object to the implicit "StartUnit" cases. It's more a syntax problem.
I think the old code takes me longer to understand, because the call
comes just above a similar-looking call to verb_to_action(), but the
results of the two functions are used in different ways. It also helps
that the new code ends up having a more regular form, for the 4 different
cases.
These changes cost 6 extra lines.
* Add an assertion to confirm that we do not pass mode=NULL.
tmpfiles.d option "e" when run through systemd-tmpfiles --create should
apply configured permissions (uid,gid) only to already existing
files. When file doesn't exist we bail out with error. Instead we should
silently ignore non-existing files.
$ useradd test
$ cat /etc/tmpfiles.d/foobar.conf
e /tmp/test - test test 1d
$ ls -l /tmp/test
ls: cannot access '/tmp/test': No such file or directory
Before:
$ systemd-tmpfiles --create /etc/tmpfiles.d/foobar.conf
Adjusting owner and mode for /tmp/test failed: No such file or directory
$ echo $?
1
After:
$ systemd-tmpfiles --create /etc/tmpfiles.d/foobar.conf
$ echo $?
0
