> Under what criterion would it be a blocker? This affects (all?) users of Workstation running 34 or rawhide and causes users to unsafely force power off their machine due to the 2 minute timeout. Many will be led to think that their Fedora install or hardware is broken. Shipping a release of Fedora Workstation that reboots without running into major errors or timeouts by default seems reasonable to me. Why is this a bad candidate for being 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. I don't know why you are assuming that I want to ignore timeouts or that things should be force killed. This is ostensibly a bug that hopefully can be fixed before F34 is released. Being condescending and assuming I am totally ignorant of how systemd manages services is not productive. To be very clear, no one is suggesting that the fix is to disregard or otherwise bypass timeouts. > 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. Why does making a bug a blocker suck time away from fixing said bug? I genuinely do not follow your logic here. > 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. The bug is currently filed against gnome-session, not pipewire. In the ticket Benjamin Berg linked the following gnome-session bug report[1] and stated "I suppose we did not yet update gnome-session, so that is expected."[2], as a result I am led to believe that this is related to a known issue with gnome-session and a likely fix is to release an update to gnome-session for F34 and rawhide. Why do you believe this bug has not been isolated to a known issue with gnome-session? Please update the issue if it is now known that gnome-session is unrelated to the problem. [1] https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/55 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1909556#c5 _______________________________________________ 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
