Previously, we did not set lifetime for redirect route, and redirect
routes were removed only when received a RA from the target address.
Thus, routes that redirect on-link addresses were never removed.
RFCs mention nothing about the lifetime of redirection. But the previous
implementation does not pass the IPv6 Core Conformance Tests.
This makes
- remember all received RAs and manage them by the sender address
(previously, remembered only one with the highest preference),
- then use the router lifetime as one for redirect route,
- remove redirect route also when the router corresponds to the sender
address is dropped (previously, considered only target address).
Note, even if we recieve a new RA, we do not update existing redirect
routes. The lifetime of the redirect route is updated only when a new
Redirect message is received.
Closes#32527.
An existing route with lifetime can be always updated with a new
finite lifetime. As the comment in the code says, we cannot disable the
lifetime. So, the condition must be '==', rather than '!='.
Fixes#33210.
It has been mentioned in IPv4Forwarding= and IPv6Forwarding=,
but let's also explain in the settings who imply these settings.
Follow-up for 3976c43092 and
485f5148b3.
PID1 may invoke a helper process, e.g. sd-close, during the test.
So, processes other than networkd and PID1 may be shown.
```
testtap99: tap pi multi_queue vnet_hdr persist filter
Attached to processes:systemd-network(2852)(sd-close)(2863)systemd(1)
```
Closes#33055.
"journalctl -u foo.service" may not work as expected, especially entries
for _TRANSPORT=stdout, for short-living services or when the service manager
generates debugging logs. Instead, SYSLOG_IDENTIFIER= should be reliable for
stdout. Let's use it.
An example case:
```
__CURSOR=s=06278e3bf011458e973c81d370a8f7a5;i=1e4dc;b=1b0258a5c78341609bf462c72d4541c3;m=308de65;t=6194c3895a13f;x=50c7e9af5b8cfc37
__REALTIME_TIMESTAMP=1716665017803071
__MONOTONIC_TIMESTAMP=50912869
_BOOT_ID=1b0258a5c78341609bf462c72d4541c3
SYSLOG_FACILITY=3
_UID=0
_GID=0
_MACHINE_ID=d3490e076ab24968bfa19a6aab26beb3
_HOSTNAME=H
_RUNTIME_SCOPE=system
_TRANSPORT=stdout
PRIORITY=6
_PID=2668
_STREAM_ID=3f9b8855636041988d003a9c63379b8a
SYSLOG_IDENTIFIER=echo
MESSAGE=foo
```
As you can see, there is no unit identifier.
After soft-reboot, /var/log/journal may be initially read-only,
and becomes writable a bit later. In such case, runtime journal is
initially opened by journald. Hence, we need to flush to /var when it is
ready.
If the runtime journal is opened, we will anyway write journal entries
to the runtime journal, even if the persistent journal is writable.
Hence, we need to flush the runtime journal file later.
So, we need to try to read timezone several times.
Also, on failure, show journal of timedated instead of hostnamed,
as the timezone is handled by timedated.
Hopefully fixes#33007.
If an initrd has an empty or uninitialized /etc/machine-id file,
then PID1 write a valid machine ID. So, the logic is important only on
soft-reboot. Let's mention that explicitly.
Follow-up for 16718dcf78.
- mention that /run/machine-id is used if exist.
- mention system.machine_id credential,
- credential, VM uuid, and container uuid are not read when --root=
is specified or running in a chroot environment.
This effectively reverts ba540e9f1c.
https://github.com/systemd/systemd/pull/32915#discussion_r1608258136
> In many cases we allow --root=/ as a mechanism for forcing an "offline" mode,
> while still operating on the root dir. if we do the getenv_for_pid() thing
> below I'd claim this is very much an "online" operation, and hence --root=/
> should really disable that.
Typically, soft-reboot.target is never reached. So, without this change,
systemd-journald may be killed by PID1 on soft-reboot, and may cause
journal corruption.
This reverts commit 4263d7617f.
Still I think this is the way to go. But the change was merged after -rc2,
and still discussion is continued. So, at least now let's revert it,
and do that after v256-final is released if approved.
Recently, for slow test environments, journalctl --sync was added to the
loop in the timeout. However, journalctl --sync may be slow in such systems,
and timeout easily triggered during syncing.
Hopefully, reading journal with --follow and grep the output with an expected
line should be efficient.
Hopefully fixes#32712.
On running cryptsetup, udevd detects two inotify events for the
underlying device. Running the test on enough fast host, the expected
symlinks based on UUID and disk label are created by the second event.
During processing a uevent for a device, udevd disables the inotify
watch for the device. If the test runs on slow system, the second
inotify event may comes during a udev worker processing the synthesized
uevent triggered by the first inotify event. Hence, no synthesized
uevent for the second inotify event will be generated, and the expected
symlinks will be never created.
To prevent the issue, we need to lock the device during cryptsetup
command is running.
Fixes#32913.
Otherwise, when stopping the service, the last command may not be
started yet, and the service manager may not send SIGTERM signal to the
last command, but send SIGKILL on timeout.
===
May 21 08:23:24 test19-exit-cgroup.sh[437]: + disown
May 21 08:23:24 test19-exit-cgroup.sh[438]: + sleep infinity
May 21 08:23:24 test19-exit-cgroup.sh[437]: + systemd-notify --ready
May 21 08:23:24 test19-exit-cgroup.sh[437]: + sleep infinity
May 21 08:23:24 test19-exit-cgroup.sh[441]: + systemctl stop one
May 21 08:23:24 test19-exit-cgroup.sh[443]: + sleep infinity
(snip)
May 21 08:23:24 systemd[1]: one.service: Changed running -> stop-sigterm
May 21 08:23:24 systemd[1]: Stopping one.service - /tmp/test19-exit-cgroup.sh "systemctl stop one"...
May 21 08:23:24 systemd[1]: Received SIGCHLD from PID 441 (systemctl).
May 21 08:23:24 systemd[1]: Child 437 (bash) died (code=killed, status=15/TERM)
May 21 08:23:24 systemd[1]: one.service: Child 437 belongs to one.service.
May 21 08:23:24 systemd[1]: one.service: Main process exited, code=killed, status=15/TERM (success)
May 21 08:23:24 systemd[1]: Child 439 (bash) died (code=killed, status=15/TERM)
May 21 08:23:24 systemd[1]: one.service: Child 439 belongs to one.service.
May 21 08:23:24 systemd[1]: Child 441 (systemctl) died (code=killed, status=15/TERM)
May 21 08:23:24 systemd[1]: one.service: Child 441 belongs to one.service.
May 21 08:23:24 systemd[1]: Child 442 (bash) died (code=killed, status=15/TERM)
May 21 08:23:24 systemd[1]: one.service: Child 442 belongs to one.service.
(snip)
May 21 08:24:54 systemd[1]: one.service: State 'stop-sigterm' timed out. Killing.
May 21 08:24:54 systemd[1]: one.service: Killing process 443 (sleep) with signal SIGKILL.
May 21 08:24:54 systemd[1]: one.service: Changed stop-sigterm -> stop-sigkill
May 21 08:24:54 systemd[1]: Received SIGCHLD from PID 443 (sleep).
May 21 08:24:54 systemd[1]: Child 443 (sleep) died (code=killed, status=9/KILL)
May 21 08:24:54 systemd[1]: one.service: Child 443 belongs to one.service.
May 21 08:24:54 systemd[1]: one.service: Control group is empty.
May 21 08:24:54 systemd[1]: one.service: Failed with result 'timeout'.
May 21 08:24:54 systemd[1]: one.service: Service restart not allowed.
May 21 08:24:54 systemd[1]: one.service: Changed stop-sigkill -> failed
May 21 08:24:54 systemd[1]: one.service: Job 738 one.service/stop finished, result=done
May 21 08:24:54 systemd[1]: Stopped one.service - /tmp/test19-exit-cgroup.sh "systemctl stop one".
May 21 08:24:54 systemd[1]: one.service: Unit entered failed state.
May 21 08:24:54 systemd[1]: one.service: Releasing resources...
===
Fixes#32947.
Fixes https://github.com/systemd/systemd/issues/32680#issuecomment-2120974685.
===
May 21 02:45:08 TEST-74-AUX-UTILS.sh[2475]: + mountpoint /tmp/tmp.eaRV7lSbX2/mnt
May 21 02:45:08 TEST-74-AUX-UTILS.sh[2476]: /tmp/tmp.eaRV7lSbX2/mnt is not a mountpoint
May 21 02:45:08 TEST-74-AUX-UTILS.sh[2449]: + systemd-mount /dev/loop0 /tmp/tmp.eaRV7lSbX2/mnt
May 21 02:45:08 systemd-mount[2477]: Failed to start transient mount unit: Unit tmp-tmp.eaRV7lSbX2-mnt.mount was already loaded or has a fragment file.
===
If machine ID is previously stored at /run/machine-id, then let's reuse
it. This is important on switching root and /etc/machine-id was previously
a mount point.
Fixes#32908.
Fixes a bug introduced by 1ddb263d21.
Note, this requires the previous two commits, and cannot backport without them.
Note, before the previous commit, the use-after-free could be triggered
only by Rename() DBus method, and could not by RenameImage(), as we did not
cache Image object when RenameImage() method is called. And machinectl
always uses RenameImage(). Hence, the issue could be triggered only when
Rename() DBus method is explicitly called by e.g. busctl.
With the previous commit, the Image object passed to the function is
always cached. Hence, the issue could be triggered even with machinectl
command, and this fix is important.
Previously, Image objects were only cached when reading properties or
methods in the org.freedesktop.machine1.Image interface are called.
This makes that, when a method in the main interface (org.freedesktop.machine1)
for an image is called, also acquire the Image object from the cache,
and if not cached, create Image object and put into the cache, like we
do for org.freedesktop.machine1.Image.
Otherwise, if some properties of an image are updated by methods in the main
interface, e.g. MarkImageReadOnly(), the changes do not applied to the cached
Image object, and subsequent read of proerties through the interface for the
image, e.g. ReadOnly property, may provide outdated values.
Follow-up for 1ddb263d21.
Fixes#32888.
Otherwise, ReadOnly DBus property in org.freedesktop.machine1.Image or
org.freedesktop.portable1.Image will not be updated by MarkReadOnly DBus
method.
Follow-up for 6c2d47d6d3.
Fixes the following unexpected skip:
```
[ 6.163670] TEST-64-UDEV-STORAGE.sh[596]: + modinfo btrfs
[ 6.164102] TEST-64-UDEV-STORAGE.sh[726]: /usr/lib/systemd/tests/testdata/units/TEST-64-UDEV-STORAGE.sh: line 726: modinfo: command not found
[ 6.164683] TEST-64-UDEV-STORAGE.sh[727]: + echo 'This test requires the btrfs kernel module but it is not installed, skipping the test'
[ 6.165069] TEST-64-UDEV-STORAGE.sh[728]: + tee --append /skipped
[ 6.166801] TEST-64-UDEV-STORAGE.sh[728]: This test requires the btrfs kernel module but it is not installed, skipping the test
[ 6.167177] TEST-64-UDEV-STORAGE.sh[596]: + exit 77
```
Fixes following failure:
===
May 17 04:12:04 TEST-74-AUX-UTILS.sh[2684]: + systemd-mount --owner=testuser /dev/loop0 /tmp/tmp.DVQdo2ou53/mnt
(snip)
May 17 04:15:04 systemd[1]: dev-loop0.device: Job dev-loop0.device/start timed out.
May 17 04:15:04 systemd[1]: dev-loop0.device: Job 5812 dev-loop0.device/start finished, result=timeout
May 17 04:15:04 systemd[1]: Timed out waiting for device dev-loop0.device - /dev/loop0.
May 17 04:15:04 systemd[1]: tmp-tmp.DVQdo2ou53-mnt.mount: Job 5804 tmp-tmp.DVQdo2ou53-mnt.mount/start finished, result=dependency
May 17 04:15:04 systemd[1]: Dependency failed for tmp-tmp.DVQdo2ou53-mnt.mount - /tmp/tmp.DVQdo2ou53/mnt.
May 17 04:15:04 systemd[1]: tmp-tmp.DVQdo2ou53-mnt.mount: Job tmp-tmp.DVQdo2ou53-mnt.mount/start failed with result 'dependency'.
May 17 04:15:04 systemd[1]: systemd-fsck@dev-loop0.service: Job 5805 systemd-fsck@dev-loop0.service/start finished, result=dependency
May 17 04:15:04 systemd[1]: Dependency failed for systemd-fsck@dev-loop0.service - File System Check on /dev/loop0.
May 17 04:15:04 systemd[1]: systemd-fsck@dev-loop0.service: Job systemd-fsck@dev-loop0.service/start failed with result 'dependency'.
May 17 04:15:04 systemd[1]: dev-loop0.device: Job dev-loop0.device/start failed with result 'timeout'.
(snip)
May 17 04:15:04 systemd-mount[2856]: A dependency job for tmp-tmp.DVQdo2ou53-mnt.mount failed. See 'journalctl -xe' for details.
Otherwise, at the time systemd-soft-reboot.service succeeds,
services which has Conflicts= and Before=soft-reboot.target may
not be stopped yet, and may be SIGKILLed.
Especially, systemd-journald.service has the dependencies, thus
journal may be corrupted. See #32223.
Follow-up for 13ffc60749.
Fixes#32834.
The service deos not have DefaultDependencies=no. Hence it has dependencies
of shutdown.target, and dependencies of soft-reboot.target are not
necessary.
Follow-up for f89985ca49.
Yu Watanabe