When using the cgroups IO controller, the device that is controlled
should always be the toplevel block device. This did not get resolved
correctly for an LVM volume inside a LUKS device, because the code would
only resolve one level of indirection.
Fix this by recursively looking up the originating block device for DM
devices.
Resolves: #15008
Possible alternative to #14819.
For me, setting RemainAfterExit=yes would be OK, but if people think that it
might cause issues, then this could be a reasonable alternative that still
let's us skip the invocation of the separate binary.
As in 2a5fcfae02
and in 3e67e5c992
using /usr/bin/env allows bash to be looked up in PATH
rather than being hard-coded.
As with the previous changes the same arguments apply
- distributions have scripts to rewrite shebangs on installation and
they know what locations to rely on.
- For tests/compilation we should rather rely on the user to have setup
there PATH correctly.
In particular this makes testing from git easier on NixOS where do not provide
/bin/bash to improve compose-ability.
UnitStatusMessageFormats.finished_job, if present,
will be called with the same arguments as
job_get_done_status_message_format() to provide a format string
appropriate for the context
This commit replaces "Started" with "Finished" for started oneshot
units, as mentioned in the referenced issue
Closes#2458.
This reverts the second part of 8125e8d38e.
The first part was reverted in 750e550eba.
The problem starts when s-v-s.s is pulled in by something that is then pulled
in by sysinit.target. Every time a unit is started, systemd recursively checks
all dependencies, and since sysinit.target is pull in by almost anything, we'll
start s-v-s.s over and over. In particular, plymouth-start.service currently
has Wants=s-v-s.s and After=s-v-s.s.
This minus has been there since the unit was added in
d42d27ead9. I think the idea was not cause things
to fail if the user instance doesn't work. But ignoring the return value
doesn't seem to be the right way to approach the problem. In particular, if
the program fails to run, we'll get a bogus fail state, see
https://bugzilla.redhat.com/show_bug.cgi?id=1727895#c1:
with the minus:
$ systemctl start user@1002
Job for user@1002.service failed because the service did not take the steps required by its unit configuration.
See "systemctl status user@1002.service" and "journalctl -xe" for details.
without the minus:
$ systemctl start user@1002
Job for user@1002.service failed because the control process exited with error code.
See "systemctl status user@1002.service" and "journalctl -xe" for details.
Build option "link-timesyncd-shared" to build a statically linked
systemd-timesyncd by using
-Dlink-udev-shared=false -Dlink-timesyncd-shared=false
on systems with full systemd stack except systemd-timesyncd, such
as RHEL/CentOS 8.
We're operating on known paths in root-owned directories here, so the detour
through toctou-safe methods that require /proc to be mounted is not necessary.
Should fix https://bugzilla.redhat.com/show_bug.cgi?id=1807768.
See https://bugzilla.redhat.com/show_bug.cgi?id=1807768. It turns
out that sysusers cannot query if the group exists:
Failed to check if group dnsmasq already exists: No such process
...
Failed to check if group systemd-timesync already exists: No such process
When the same command is executed later, the issue does not occur. Not sure why
the behaviour in the initial transaction is different. But let's accept all
errors that the man pages list. We check if the user/group exists before creating
anyway, so this seems pretty safe.
