V255 stable batch #386

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)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

V255 stable batch #386

V255 stable batch #386

Commits on Apr 24, 2024