If both literal and signed PCR bindings are not used then we won't
determine a PCR bank to use, and hence we shouldnt attempt to serialize
it either.
Hence, if the bank is zero, skip serialization.
(And while we are at it, also skip serialization of the primary
algorithm if not set, purely to make things systematic).
[This effectively results in little change, as previously we'd then
seralize a json "null", while now we simply won't genreate the field]
We so far derived the PCR bank to use from the PCR values specified fr
literal PCR binding. However, when that's not used then we left the bank
uninitialized – which will break if signed PCR binds are used (where we
need to pick a bank too after all).
Hence, let's explicitly pick a bank to use if literal PCR values are not
used, to make things just work.
Fixes: #32946
We want to avoid reinitialization of our global variables with static
storage duration in case we get dlopened multiple times by the same
application. This will avoid potential resource leaks that could have
happened otherwise (e.g. leaking journal socket fd).
In varlink.c we generally do not make failing callback functions fatal,
since that should be up to the app. Hence, in case of varlinkctl (where
we want failures to be fatal), make sure to propagate the error back
explicitly.
Before this change a failing call to "varlinkctl --more call …" would result in
a zero exit code. With this it will correctly exit with a non-zero exit
code.
When running in LXC with AppArmor we'll most likely get an error when creating
a network namespace due to a kernel regression in < v6.2 affecting AppArmor,
resulting in denials. Like other tests, avoid failing in case of permission
issues and handle it gracefully.
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.
As per the documentation, EACCES is only returned when F_SETLK is
used, and only on some platforms, which doesn't seem to include
Linux:
https://github.com/torvalds/linux/blob/master/fs/locks.c
F_OFD_SETLK is documented to only return EAGAIN, and F_SETLKW/F_OFD_SETLKW
are blocking operations so this logic doesn't apply to them in the
first place.
Hence, only automatically convert EACCES into EAGAIN for F_SETLK
operations, and propagate the original error in the other cases.
This is important because in some cases we catch permission errors
and gracefully fallback, which is not possible if the original error
is lost.
This is an issue in practice because, due to a kernel bug present
before v6.2, AppArmor denies locking on file descriptors to LXC
containers. We support all currently maintained LTS kernels,
including v6.1, where despite a lot of effort and attempts over almost
a year, the bugfix still hasn't been backported, as it is complex and
requires large changes to AppArmor.
On affected kernels, all services running with PrivateNetwork=yes
fail and do not recover, instead of the normal behaviour of gracefully
downgrading to PrivateNetwork=no.
The integration tests in the Debian CI fail due to this issue:
https://ci.debian.net/packages/s/systemd/testing/arm64/46828037/
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.
Coverity gets confused since the iterator change, so add an
assert to indicate that this is allocated if n_old_groups is > 0
CID#1545922
Follow-up for 125cca1b51
src.opensuse.org switched to SHA256, which means it can no longer be
used as a submodule in a SHA1 repository. Switch to a fork on Pagure
that gets synced across and is still SHA1:
https://code.opensuse.org/package/systemd.git
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.
===
Follow-up for ade0789fab
The change in behavior was partly intentional, as I think
if both --wait and --pty are used, manually disconnecting
from PTY forwarder should not result in systemd-run exiting
with "Finished with ..." log. But we should check for
--wait here.
Closes#32953
systemd-analyze runs the generators in a sandbox, which makes gcov
unhappy since it can't update its counters. Let's "silence" gcov in this
particular case by telling it to look for gcov note files in /tmp (where
shouldn't be any, so gcov won't try to update any counters).
