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

pid1: rework handoff timestamp #32441

Merged
merged 9 commits into from
Apr 25, 2024

Conversation

poettering
Copy link
Member

@poettering poettering commented Apr 23, 2024

Fixes: #32404

@github-actions github-actions bot added documentation tests please-review PR is ready for (re-)review by a maintainer labels Apr 23, 2024
src/core/exec-invoke.c Outdated Show resolved Hide resolved
src/core/exec-invoke.c Outdated Show resolved Hide resolved
@bluca bluca added reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks and removed please-review PR is ready for (re-)review by a maintainer labels Apr 24, 2024
@yuwata yuwata marked this pull request as draft April 24, 2024 04:02
Copy link
Member

@keszybz keszybz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks reasonable…

src/core/manager.c Outdated Show resolved Hide resolved
src/core/manager.c Outdated Show resolved Hide resolved
src/core/exec-invoke.c Outdated Show resolved Hide resolved
src/core/exec-invoke.c Outdated Show resolved Hide resolved
src/core/execute.c Outdated Show resolved Hide resolved
src/core/manager.c Outdated Show resolved Hide resolved
src/core/manager.c Outdated Show resolved Hide resolved
@poettering
Copy link
Member Author

I split out a bunch of commits into their own PRs now, so that they can be review/merged more quickly.

@poettering poettering added please-review PR is ready for (re-)review by a maintainer and removed needs-rebase labels Apr 25, 2024
@poettering
Copy link
Member Author

Posted a new version, addressing @YHNdnzj's comments. And I dropped the calendar time from the dump output if we can show the monotonic time diff instead, as mentioned.

Copy link
Member

@YHNdnzj YHNdnzj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, but still some comments

FORMAT_TIMESPAN(usec_sub_unsigned(s->exit_timestamp.monotonic, s->handoff_timestamp.monotonic), 1));
else if (dual_timestamp_is_set(&s->start_timestamp) && s->exit_timestamp.monotonic > s->start_timestamp.monotonic)
fprintf(f,
"%sExit Timestamp: %s since start\n",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I don't think Exit timestamp should be switched to only show delta?

The point of handoff timestamp is to measure the sd-executor latency and such, and that ought to be an extremely short period, hence it makes sense to only show timespan for that. But that reasoning doesn't apply to the exit timestamp?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, i agree, but the way i understood @keszybz is that he doesn't want to see the calendar time again.

at this point i really don't care anymore, let's just get this merged, i'll change the timestamp display on this to anything people are happy with.

i am happy to drop that commit btw, if it's so hard to agree on an outout acceptable to everyone.

src/core/manager.c Outdated Show resolved Hide resolved
src/core/manager.c Outdated Show resolved Hide resolved
src/core/service.c Outdated Show resolved Hide resolved
src/core/unit.h Outdated Show resolved Hide resolved
@YHNdnzj YHNdnzj added the rc-blocker 🚧 PRs and Issues tagged this way are blocking the upcoming rc release! label Apr 25, 2024
assert_se() should not be used here, these checks are paranoia only and
have no side-effect after all.

hence fix this to use assert(), or in fact ASSERT_PTR()
…dren

This adds an AF_UNIX socket pair to the manager that we can collect
handoff timestamp messages on.

The idea is that forked off children send a datagram with a timestamp
and we use its sender PID to match it against the right forked off
process.

This part only implements the receiving side: a socket is created, and
listened on. Received datagrams are parsed, verified and then dispatched
to the interested units.
This changes the executor to systematically send handoff timestamps to
the service manager if a socket for that is supplied. This drops the
code that did this via Type=exec messages, and reverts that part to the
old behaviour before 93cb78a.

Benefits of this approach:

1. We can collect the handoff for any command we fork off, regardless
   if it's ExecStart= something else, regardless whether it's Type=exec,
   Type=simple or some any other service type, regardless of the unit
   type.

2. We collect both CLOCK_REALTIME and CLOCK_MONOTONIC, as we do for the
   other process timestamps.

3. It's entirely backwards compatible, as this doesn't change the
   protocol between service manager and executor, but just extends it.
@poettering
Copy link
Member Author

Force pushed a new version now, addressing @YHNdnzj's point.

didn't touch the dump timestamp display, because I think there's disagreement on what to show. while i am personally fine with anything as long as this is merged, i am not sure what that "anything" should be, that makes everyone happy.

@bluca
Copy link
Member

bluca commented Apr 25, 2024

Github helpfully hides it even if it's unresolved, please see #32441 (comment)

…ing logic

Also: rename Handover → Handoff. I think it makes it clearer that this
is not really about handing over any resources, but that the executor is
out off the game from that point on.
Let's show the runtimes of our commands and preparations for them. It's
actually quite interesting, we sometimes are irritatingly slow with our
handoffs.
@poettering
Copy link
Member Author

Github helpfully hides it even if it's unresolved, please see #32441 (comment)

updated with a comment about this. ptal.

Copy link
Member

@bluca bluca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, looks good to me

@YHNdnzj YHNdnzj added good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed and removed please-review PR is ready for (re-)review by a maintainer labels Apr 25, 2024
@poettering poettering merged commit 5693208 into systemd:main Apr 25, 2024
42 of 49 checks passed
@github-actions github-actions bot removed the good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed label Apr 25, 2024
YHNdnzj added a commit to YHNdnzj/systemd that referenced this pull request Apr 27, 2024
dual_timestamp dt;
dual_timestamp_now(&dt);

if (send(p->handoff_timestamp_fd, (const usec_t[2]) { dt.realtime, dt.monotonic }, sizeof(usec_t) * 2, 0) < 0) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This send might not be allowed by seccomp: #33299.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation pid1 rc-blocker 🚧 PRs and Issues tagged this way are blocking the upcoming rc release! tests util-lib
Development

Successfully merging this pull request may close these issues.

ExecMainHandoverTimestamp needs fixing
5 participants