Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

V255 stable batch #386

Merged
merged 5 commits into from
Apr 24, 2024
Merged

V255 stable batch #386

merged 5 commits into from
Apr 24, 2024

Conversation

keszybz
Copy link
Member

@keszybz keszybz commented Apr 24, 2024

No description provided.

DaanDeMeyer and others added 5 commits April 24, 2024 08:48
This also fixes bugs in the previous code where we pass the server
object as userdata to sd_event_add_signal which means that sd-event
tries to use the value of the server pointer as its exit code when
a signal is triggered.

(cherry picked from commit dcd332a)
Currently, if unmount initiated by us fails, we record
that in result. Later, if we tried again and succeeded,
or someone else successfully unmounted it, the unit
state is still considered failed. Let's be more tolerant
instead, and forget about previous failure.

Alternative to #32002

(cherry picked from commit e378306)
Currently the associated units fail if full tpm support is not available
on the system. Similar to systemd-pcrextend, let's add a --graceful option
that exits gracefully if no full TPM support is detected and use it in both
units.

(cherry picked from commit 966e05a)
Currently, when downgrading from a version with pidfd support to a
version without pidfd support, all information about running processes
is lost as the newer systemd will serialized pidfds which are not recognized
by the older systemd when deserializing.

To improve the situation, let's serialize both the pid and the pidfd.
This is safe because existing versions will either replace the first
deserialized pidref with the second one or discard the second one in
favor of the first one depending on the unit and field. Older versions
that don't support pidfd's will silently discard any fields that contain
a pidfd as those will try to parse the field as a pid and since a pidfd
field will start with '@', those versions will debug error log and ignore
the value.

To make sure we reuse the existing pidfd as much as possible, the pidfd
is serialized first. Both for scopes and service main pids, if the same
pid is seen multiple times, the first pidref is kept. So by serializing
the pidfd first we make sure the original pidfd is used instead of the
new one which is opened when deserializing the first pid field.

For other control units, older versions with pidfd support will discard
the first pidfd and replace it with a new pidfd from the second pid field.
This is a slight regression on downgrades, but we make sure it doesn't
happen for future versions (and older versions when this commit is
backported) by modifying the logic to only use the first successfully
deserialized pidref so that the raw pid without pidfd is discarded instead
of it replacing the existing pidfd.

(cherry picked from commit aaa872a)
If we try to deserialize only a pidfd that points to a process that
has been reaped, creating the pidref object will fail, which means that
we'll try to create a pidref object from the serialized pid that comes
next. If the pid has already been reused, this will succeed and we'll
now have a pidref that points to a different process.

Let's avoid this issue by serializing both the pidfd and the pid and
creating the pidref object directly from both. This means we'll reuse
the deserialized pidfd instead of opening a new one. We'll then immediately
notice the pidfd is dead and do the appropriate follow up depending on
the unit type.

(cherry picked from commit 7072777)
@keszybz
Copy link
Member Author

keszybz commented Apr 24, 2024

mkosi/ci (centos 9) failed when downloading repos.

@mrc0mmand
Copy link
Member

Btw, for #385 (comment) and #383 (comment) you could backport just the test skip commit - 8ed7800 - to reduce the noise in CI.

@bluca
Copy link
Member

bluca commented Apr 24, 2024

I'll do another PR after this, with that and systemd/systemd#31311

@keszybz keszybz merged commit 0df675e into v255-stable Apr 24, 2024
39 of 45 checks passed
@keszybz keszybz deleted the v255-stable-batch branch April 24, 2024 09:15
@keszybz
Copy link
Member Author

keszybz commented Apr 24, 2024

Merged. We don't want to wait for ubuntuautopkgtests, and the rest passed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

5 participants