Repository navigation
core: fix logic of merging units - #25387
Conversation
2bd7293 to
5f84f68
Compare
5f84f68 to
098786d
Compare
|
(Hm, still GC logic needs to be updated.) |
098786d to
f2b321b
Compare
|
The commit for unit GC is dropped. PTAL. |
f2b321b to
f90143e
Compare
f90143e to
2e30309
Compare
|
@keszybz Thank you for the review. All points, except for the bashism in the test, are addressed. PTAL! |
Fixes a bug in 15ed3c3. Fixes systemd#24990. Also, hopefully fixes systemd#24577.
No functional change, just refactoring.
Before: systemd[1]: issue-24990.service: Dependency Before=n/a dropped, merged into issue-24990.service After: systemd[1]: issue-24990.service: Dependency Before=test1.service dropped, merged into issue-24990.service
2e30309 to
4f41ccd
Compare
As you can see in the below, the dropped dependency Before=issue-24990.service is not logged, but the dependency Before=test1.service which is not owned by the units generated by the TEST-26 is logged. Before: systemd[1]: issue-24990.service: Dependency After=test1.service dropped, merged into issue-24990.service systemd[1]: issue-24990.service: Dependency Before=test1.service dropped, merged into issue-24990.service After: systemd[1]: issue-24990.service: Dependency After=test1.service is dropped, as test1.service is merged into issue-24990.service. systemd[1]: issue-24990.service: Dependency Before=issue-24990.service in test1.service is dropped, as test1.service is merged into issue-24990.service.
4f41ccd to
ed99116
Compare
|
@keszybz Thank you for your review. All comments are addressed. Upgrading the green label.
I like the abbreviation! |
| /* This is a dependency pointing back to the unit we want to merge with? | ||
| * Suppress it (but warn) */ | ||
| unit_maybe_warn_about_dependency(u, other->id, UNIT_DEPENDENCY_FROM_PTR(dt)); | ||
| hashmap_remove(other_deps, back); |
There was a problem hiding this comment.
hmm, now you are changing the hashmap you are iterating through. It's something I so far avoided
|
looks good, but iterating through a hashmap that we modify is problematic, iirc our hashmap implementation is not safe against arbitrary changes during iteration |
It is safe. Please see the comment in |
|
This was already included in v252.4. |
Fixes several bugs introduced by 15ed3c3 (v249).
Fixes #24990. Also, hopefully fixes #24577.