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
core: first step towards a pidfd focused future #29142
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
build-system
util-lib
meson
please-review
PR is ready for (re-)review by a maintainer
labels
Sep 9, 2023
YHNdnzj
reviewed
Sep 9, 2023
YHNdnzj
added
ci-fails/needs-rework 🔥
Please rework this, the CI noticed an issue with the PR
and removed
please-review
PR is ready for (re-)review by a maintainer
labels
Sep 9, 2023
Let's start with the conversion of PID 1 to pidfds. Let's add a simple structure with just two fields that can be used to maintain a reference to arbitrary processes via both pid_t and pidfd. This is an embeddable struct, to keep it in line with where we previously used a pid_t directly to track a process. Of course, since this might contain an fd on systems where we have pidfd this structure has a proper lifecycle. (Note that this is quite different from sd_event_add_child() event source objects as that one is only for child processes and collects process results, while this infra is much simpler and more generic and can be used to reference any process, anywhere in the tree.)
The first conversion to PidRef. It's mostly an excercise of search/replace, but with some special care taken for life-cycle (i.e. we need to destroy the structure properly once done, to release the pidfd). It also uses pidfd based killing for some of the killing but leaves most as it is to make the conversion minimal.
Just like the previous commit, but for socket rather than service units.
Let's stop manually destroying the timers when we fail to spawn a child. We don't do this in any of the similar codepaths in any of the unit types, only in two specific ones in socket/swap. Destroying the timer is unnecessary, since this is done anyway in the _set_state() call of each unit type if not appropriate, and every failure path here runs through that anyway. This brings all these similar codepaths into sync.
github-actions
bot
added
please-review
PR is ready for (re-)review by a maintainer
and removed
ci-fails/needs-rework 🔥
Please rework this, the CI noticed an issue with the PR
labels
Sep 9, 2023
YHNdnzj
approved these changes
Sep 9, 2023
YHNdnzj
added
good-to-merge/with-minor-suggestions
and removed
please-review
PR is ready for (re-)review by a maintainer
labels
Sep 9, 2023
bluca
approved these changes
Sep 9, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice stuff
This was referenced Sep 11, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the first step towards putting pidfds front and center for service process tracking. It doesn't move all process operations done by PID 1 over to it, but at least the basic tracking is now via pidfd. Further infra should be moved over too, but can happen in separate steps, already to make this PR not ridiculously large.