ExecStart= and friends for .service and .socket can be specified
multiple times.
This also checks all commands for .mount and .swap, not only for the
current control command.
If the target mount point is an automount, checking it for writeability
without triggering it first is iffy and yields different results based
on kernel version:
~# systemd-run --wait --pipe -p ProtectSystem=yes bash -xec 'uname -r; mount -l | grep boot; test ! -w /boot'
Running as unit: run-u36.service; invocation ID: f948ff4f3c8e4bcfba364ead94bd0ad9
+ uname -r
4.18.0-529.el8.x86_64
+ mount -l
+ grep boot
systemd-1 on /boot type autofs (rw,relatime,fd=43,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=356096)
+ test '!' -w /boot
Finished with result: exit-code
Main processes terminated with: code=exited/status=1
~# systemd-run --wait --pipe -p ProtectSystem=yes bash -xec 'uname -r; mount -l | grep boot; test ! -w /boot'
Running as unit: run-u274.service; invocation ID: ccc53ed63c3249348cf714f97a3a7026
+ uname -r
6.6.7-arch1-1
+ mount -l
+ grep boot
systemd-1 on /boot type autofs (rw,relatime,fd=95,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=730583)
+ test '!' -w /boot
Finished with result: success
Main processes terminated with: code=exited/status=0
One solution would be to use /boot/ instead of just /boot, which triggers
the automount during the check, but in that case the mount would happen
_after_ we apply the ProtectSystem= stuff, so the mount point would
be unexpectedly writable:
~# systemd-run --wait --pipe -p ProtectSystem=yes bash -xec 'uname -r; mount -l | grep boot; test ! -w /boot/ || mount -l | grep boot'
Running as unit: run-u282.service; invocation ID: 2154f6b4cbd34ddeb3e246cb7c991918
+ uname -r
6.6.7-arch1-1
+ mount -l
+ grep boot
systemd-1 on /boot type autofs (rw,relatime,fd=95,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=730583)
+ test '!' -w /boot/
+ mount -l
+ grep boot
systemd-1 on /boot type autofs (rw,relatime,fd=95,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=730583)
/dev/vda2 on /boot type vfat (rw,nosuid,nodev,noexec,relatime,nosymfollow,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
Let's just trigger the (possible) automounts explicitly before we do any
checks to avoid all this stuff.
Also, when at it, check that ProtectSystem=yes|full correctly protects
the ESP mount as well.
Follow-up for 97bbb9cfbd.
Otherwise we might occasionally hit the start rate limit, as we restart
the service a bunch of times:
[ 3702.280886] testsuite-75.sh[1135]: + tee /tmp/tmp.wUL8bkJwrt
[ 3702.283684] testsuite-75.sh[1135]: {}
[ 3702.284254] testsuite-75.sh[46]: + restart_resolved
[ 3702.284302] testsuite-75.sh[46]: + systemctl stop systemd-resolved.service
[ 3702.310678] testsuite-75.sh[1140]: + systemctl is-failed systemd-resolved.service
[ 3702.316766] testsuite-75.sh[1141]: inactive
[ 3702.316998] testsuite-75.sh[46]: + systemctl start systemd-resolved.service
[ 3702.322315] systemd[1]: systemd-resolved.service: Start request repeated too quickly.
[ 3702.322343] systemd[1]: systemd-resolved.service: Failed with result 'start-limit-hit'.
[ 3702.322609] systemd[1]: Failed to start systemd-resolved.service - Network Name Resolution.
[ 3702.323619] systemctl[1142]: Job for systemd-resolved.service failed.
[ 3702.323839] systemctl[1142]: See "systemctl status systemd-resolved.service" and "journalctl -xeu systemd-resolved.service" for details.
[ 3702.325035] systemd[1]: testsuite-75.service: Failed with result 'exit-code'.
[ 3702.325391] systemd[1]: Failed to start testsuite-75.service - Tests for systemd-resolved.
Follow-up for b1384db11b and 6ef512c0bb.
This patch enables IFNAME_VALID_ALTERNATIVE for checks guarding the
parsing of RestrictNetworkInterfaces=.
The underlying implementation for this option already supports
altnames.
Most of the integration tests have been made to not write to /usr
but some genuinely need to do so.
Because mkosi creates images with a read-only /usr
it is not normally writeable.
By mounting an overlayfs with /usr as the lower dir
and upper and working dirs in /var tests may write to /usr.
This test is for if devices transition from plugged -> dead -> plugged
on boot, but it is normal to see loop devices transition plugged -> dead
on first boot when systemd-repart adds the root partition.
The systemd-analyze integration test also tests chroots.
It builds its chroot by bind-mounting /,
but since /usr might be a separate mountpoint
it should create the chroot with --rbind.
It's pulled in by one of the udev rules (63-md-raid-arrays.rules) and it
fails every time, because there's no valid email address in
/etc/mdadm.conf:
[ 5.778153] testsuite-64.sh[403]: mdadm: array /dev/md/mdmirror started.
[ 5.819137] kernel: md/raid1:md127: not clean -- starting background reconstruction
[ 5.819141] kernel: md/raid1:md127: active with 2 out of 2 mirrors
[ 5.819159] kernel: md127: detected capacity change from 0 to 129024
[ 5.821950] kernel: md: resync of RAID array md127
...
[ 5.887192] mdadm[424]: mdadm: No mail address or alert command - not monitoring.
[ 5.890772] systemd[1]: Starting mdmonitor.service...
[ 5.891718] systemd[1]: Started mdmonitor.service.
[ 5.892570] systemd[1]: mdmonitor.service: Main process exited, code=exited, status=1/FAILURE
[ 5.892618] systemd[1]: mdmonitor.service: Failed with result 'exit-code'.
And as we (re)assemble the MD devices multiple times, this gets quite
noisy, especially since we later start hitting the service start rate
limit.
Fedora has the mdmonitor.service patched, so it won't start without
/etc/mdadm.conf being present, but Arch uses the upstream unit which
doesn't have such guard.
Let's just mask the service completely, which replaces all that noise
with one warning:
[ 6.553583] testsuite-64.sh[294]: + udevadm wait --settle ...
[ 6.580700] systemd[1]: sys-devices-virtual-block-md127.device: Failed to enqueue SYSTEMD_WANTS job, ignoring: Unit mdmonitor.service is masked.
Just use ExecParam directly, as these are all internal to sd-exec now
anyway. Avoids double close when execution fails after FDs are set up
for inheritance and were already re-arranged.
Fixes https://github.com/systemd/systemd/issues/30412
On Fedora systemd recently moved all of its configuration files to
/usr/lib/ [0], so make sure we account for this case as well.
[ 42.450325] testsuite-17.sh[800]: + mkdir -p /run/udev/rules.d
[ 42.466504] testsuite-17.sh[800]: + cp -f /etc/udev/udev.conf /etc/udev/udev.conf.bckp
[ 42.503348] testsuite-17.sh[802]: cp: cannot stat '/etc/udev/udev.conf': No such file or directory
[0] https://src.fedoraproject.org/rpms/systemd/c/29eb35530b29232eed65718d0cd96d67cd7ffd6b?branch=rawhide
Since we restart systemd-udevd here a couple of times, we might hit the
rate limit in later tests:
[ 26.028355] testsuite-17.sh[2074]: + udevadm control -e
[ 26.028355] testsuite-17.sh[2074]: + udevadm control -l emerg
[ 26.126160] systemd[1]: systemd-udevd.service: Start request repeated too quickly.
[ 26.126213] systemd[1]: systemd-udevd.service: Failed with result 'start-limit-hit'.
[ 26.140310] systemd[1]: Failed to start systemd-udevd.service.
[ 26.140897] systemd[1]: systemd-udevd-control.socket: Failed with result 'service-start-limit-hit'.
[ 26.141286] systemd[1]: systemd-udevd-kernel.socket: Failed with result 'service-start-limit-hit'.
[ 26.142225] testsuite-17.sh[2074]: + udevadm control -l alert
[ 26.149206] udevadm[2088]: Failed to send request to set log level: No such file or directory
Follow-up to: 6ef512c0bb
So far we created the target directory, and the source for bind mounts,
but not workdir/upperdir for overlays, so it has to be done separately
and strictly before the unit is started, which is annoying. Check the
options when creating directories, and if upper/work directories are
specified, create them.
If a unit is running in an image and wants to survive a soft-reboot,
then it can't be deactivated by the storage of the image going away.
Relax the dependency to a Wants=. Access to the image is not needed
when the unit is running anyway, so downgrade to Wants=.
When --after-cursor=/--cursor-file= is used together with a journal
filter, we still skipped over the first matching entry even if it wasn't
the entry the cursor points at, thus missing one "valid" entry
completely. Let's fix this by checking if the entry cursor after seeking
matches the user provided cursor, and skip to the next entry only when
the cursors match.
Resolves: #30288
Request with Range header like 'entries=<cursor>:' (with a colon at the end,
invalid syntax per the doc), is now rejected with error 400 Bad Request.
fix#4883
We can't use the systemd-journal-upload user here, since it's created
dynamically by DynamicUser=yes. However, we can use the group specified
in SupplementaryGroups=, so do exactly that.
Let's consider the following case:
- the direction is down,
- no cached entry,
- the array has 5 entry objects,
- the function test_object() reutns TEST_LEFT for the 1st object,
- the 2nd, 3rd, and 4th objects are broken, so generic_array_bisect_step()
returns TEST_RIGHT for the object.
Then, previously, generic_array_bisect_step() updated the values like the following:
0th: (m = 5, left = 0, right = 4, i = 4) -> (m = 4, left = 0, right = 3, RIGHT)
1st: (m = 4, left = 0, right = 3, i = 1) -> (m = 4, left = 2, right = 3, LEFT)
2nd: (m = 4, left = 2, right = 3, i = 2) -> (m = 2, left = 2, right = 1, RIGHT) <- ouch!!
So, assert(left < right) in generic_array_bisect() was triggered.
See issue #30210.
In such situation, there is no matching entry in the array. By returning
TEST_GOTO_PREVIOUS, generic_array_bisect() handles the result so.
Fixes a bug introduced by ab8f553d1e.
Fixes#30210.
The errors are valid, since the file system is indeed not writable, but
we don't care about the missing coverage data in this case.
Follow-up to 4a43c2b3a1.
The header and keyfile are necessary only for opening the device, not
for closing, so it is not necessary to deactivate the generated
cryptsetup unit when the header or keyfile backing store are removed.
This is especially useful in the case of softreboot, when the new
mount root is setup under /run/nextroot/ but we don't want to close
the cryptsetup devices for encrypted /var/ or so, and we simply
mount it directly on /run/nextroot/var/ before the soft-reboot.
Yu Watanabe
Frantisek Sumsal
Mike Yuan
Luca Boccassi
networkException
Lennart Poettering
Richard Maw
Zbigniew Jędrzejewski-Szmek
Samuel BF
Daan De Meyer