-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
job: Don't mark as redundant if deps are relevant #14086
Conversation
This is just one approach. Some other ways to skin this could be still letting the job get marked as redundant but flattening the graph before GC, not GCing units that matter to the anchor, etc... |
Something in this patch is killing the CentOS CI machines:
|
0968e76
to
662c8f5
Compare
In the steps given in systemd#13850, the resulting graph looks like: C (Anchor) -> B -> A Since B is inactive, it will be flagged as redundant and removed from the transaction, causing A to get garbage collected. The proposed fix is to not mark nodes as redundant if doing so causes a relevant node to be garbage collected. Fixes systemd#13850
662c8f5
to
8f3178f
Compare
@mrc0mmand Apologies. Once I built it onto my system tree was able to repro the panic. Didn't happen with the |
looks correct. thanks! |
I suspect this may not actually be correct: https://bugzilla.redhat.com/show_bug.cgi?id=1803293 we're running into an issue in Fedora 32 and Rawhide where |
Yep, reverting this change definitely seems to fix that bug. |
@AdamWill Gotcha. If this patch is changing the behavior of existing unit files then it should be reverted. Even if there is something that can be changed in the unit, the edge case it fixes is not worth a regression. |
This is a yet another case where it would be really great if we could, somehow, resurrect the Fedora Rawhide CI for the systemd upstream repo. |
I can confirm the breakage I ran a git bisect and ended up with 097537f as the first faulty commit. Imho this change should be reverted until a solution is found that doesn't break plymouth. |
It doesn't only affect Plymouth, it affects over a dozen other services. See this comment. |
@AdamWill good to know. I'll be reverting this commit downstream as this seems to hit users hard. |
Actually the only ones known so far are systemd-network-generator.service, systemd-vconsole-setup.service, and plymouth-start.service. And systemd-network-generator.service is idempotent, so not running it twice is just a minor optimization. (#1803293 lists some other services, but they already had RemainAfterExit=true, so they would not be invoked again anyway.) -- |
What's with all the other service names listed in that comment, then? Anyhow, at least |
Not sure. Most of those units have Type=oneshot, RemainAfterExit=yes. In v244 it is possible that in some scenarios they would not run even though they should, but it would be unexpected if they run twice. I guess that they had already been started, and those lines in the log are just noise, systemd deciding not to run them again, when it doesn't really matter why. If you paste a full log, we could try to figure it out, but I don't it is worth the time. |
So, I have been having weird issues on ArchLinux with systemd 245 recently, and today I was able to bisect and got this as the first bad commit. Initially I noticed issues when trying to use VMs with virt-manager. For some reason, I would start a VM and nothing happened, it just stayed frozen. I tried to restart libvirtd and then I saw systemd asking me for my LUKS password. Digging further, it seems any operation using systemctl would request my LUKS password (after boot, wait a few minutes for the password provided in the boot to expire from the keyring, then try to start/restart/stop a service and it would ask me for the LUKS password). I do not have plymouth in this system. Any ideas what is going on here? |
And I guess I have have found my issue: somehow I had the same device listed twice in crypttab and one of the systemd-cryptsetup units associated to this device would be marked as failed after boot. After this commit it seems systemd keeps retrying failed units (question in #15242), which is what causes the issue I had. A little subtle in my case, as since the password is cached for a little while, the issue wont be reproducible immediately. |
In the steps given in #13850, the resulting graph looks like:
Since B is inactive, it will be flagged as redundant and removed from
the transaction, causing A to get garbage collected. The proposed fix is
to not mark nodes as redundant if doing so causes a relevant node to be
garbage collected.
Fixes #13850