Skip to content

core: only activate transaction that contain useful jobs#40314

Merged
YHNdnzj merged 1 commit intosystemd:mainfrom
msekletar:device-nops-waiting
Jan 15, 2026
Merged

core: only activate transaction that contain useful jobs#40314
YHNdnzj merged 1 commit intosystemd:mainfrom
msekletar:device-nops-waiting

Conversation

@msekletar
Copy link
Copy Markdown
Contributor

If no real jobs were added to the transaction, do not activate it. The JOB_NOP anchor does not perform any useful work and activating such transaction only wastes resources.

Fixes #9751

@github-actions github-actions bot added the please-review PR is ready for (re-)review by a maintainer label Jan 9, 2026
Copy link
Copy Markdown
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.

Code itself makes sense to me, but I don't entirely understand the connection to the linked issue. The way I read things this only suppresses jobs from being installed if there's nothing load-bearing, but doesn't address the underlying issue?


/* Only activate the transaction if it contains jobs other than NOP anchor.
* Short-circuiting here avoids unnecessary processing, such as emitting D-Bus signals. */
if (hashmap_size(tr->jobs) == 1)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

we prefer <= checks

Copy link
Copy Markdown
Contributor Author

@msekletar msekletar Jan 9, 2026

Choose a reason for hiding this comment

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

Hmmm...Isn't that confusing? I mean we want early return in exactly one case so why check interval. On top of that, we put anchor job to the transaction explicitly.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Yeah I know == 0 is in reality not reachable, but we tend to encode the intention in these comparisons, and 0 is conceptually something we should skip too

@YHNdnzj YHNdnzj added the pid1 label Jan 9, 2026
@msekletar
Copy link
Copy Markdown
Contributor Author

Code itself makes sense to me, but I don't entirely understand the connection to the linked issue. The way I read things this only suppresses jobs from being installed if there's nothing load-bearing, but doesn't address the underlying issue?

AFAICT, the issue as described is not reproducible any more with current systemd version. I was able to reproduce 50%, i.e. NOP jobs are present after reload but eventually they are cleared because run_queue is correctly triggered after coldpluging stuff after deserialization. So the second part, i.e. these NOP jobs are stuck forever is no longer the case.

@YHNdnzj YHNdnzj added good-to-merge/with-minor-suggestions and removed please-review PR is ready for (re-)review by a maintainer labels Jan 9, 2026
If no real jobs were added to the transaction, do not activate it.
The JOB_NOP anchor does not perform any useful work and activating
such transaction only wastes resources.

Fixes systemd#9751
@msekletar msekletar force-pushed the device-nops-waiting branch from 629f082 to e88fcd5 Compare January 9, 2026 19:29
@msekletar
Copy link
Copy Markdown
Contributor Author

@YHNdnzj updated. PTAL.

Copy link
Copy Markdown
Member

@yuwata yuwata left a comment

Choose a reason for hiding this comment

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

LGTM.
Could you add a test case for the issue?
I think it is better to add a sub test in TEST-17-UDEV.

@YHNdnzj
Copy link
Copy Markdown
Member

YHNdnzj commented Jan 15, 2026

OK, merging this as-is now. As explained above this is just an optimization, hence doesn't strictly speaking need a test. Test cases are still nice to have, but I see no reason to block the PR for that.

@YHNdnzj YHNdnzj merged commit bcbf80c into systemd:main Jan 15, 2026
50 of 57 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

race condition between "systemctl daemon-reload" and "udevadm trigger"

4 participants