On Sun, Feb 21, 2021 at 12:24 PM Tom Seewald <tseewald@xxxxxxxxx> wrote: > > If Gnome is still hanging for 2 minutes on reboot [1] then I think we may want to consider that a blocking bug for F34. I can at least confirm that this bug is still affecting Rawhide. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1909556 Under what criterion would it be a blocker? The gist of the problem is that (a) it's a reasonable goal to get reboot/shutdown times below 30s, ideally 10s but that's a detail; (b) it's not reasonable to just arbitrarily disregard the hierarchy of timeouts and just blow away the user manager and all child processes. The timeouts are there for a reason, so they all have to be taken into account to make sure everything is folding in the proper sequence. Otherwise we end up with new and possibly worse problems. e.g. https://github.com/systemd/systemd/pull/18386 I might be wrong but I think it's specious to just make this a blocker. Sounds good, but then upon closer inspection I think we'll find the blocker process isn't going to be an effective way to fix the problem, and then it'll just end up sucking people's time away from isolating the problems. And not least of which is learning *how* to isolate these problems, so maybe that's a conversation worth having is how to better understand the information available to find out what to blame and find a bug against. I filed that bug against pipewire only because it's mostly what's remaining at the 2 minute mark; and if I use the early debug shell so I can switch to tty9 during the timeout countdown, and kill off all those processes, usually I get an immediate reboot. Correlation or causation? *shrug* I don't know. Sometimes I see pipewire processes with new PID! As in something is restarting them in the middle of the timeout! That's pretty curious and unexpected, but I don't know what it means. Some of "getting more and better information" on what's happening has been discussed as a needed systemd enhancement. I'm not sure about the time frame yet. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
