One of the nice things that I immediately noticed when Mageia first switched to systemd (Mageia 2) was that it would shut down or reboot (the shutdown part of that process) *very* quickly. Unfortunately, systemd later added a "feature" causing it to hang and delay for a long time because of services or other processes that don't immediately respond to a signal to shut themselves down. Fedora is working on shortening these timeouts, and we should implement it as soon as they do: https://www.phoronix.com/news/Fedora-38-Faster-Reboots
Sorry, but that Fedora proposal is broken by design... forcing processes to stop after 15 s _will_ cause breakage / data loss... the proper thing to do is to debugging of what causes a system ending up waiting or 2 minutes, and fix them... not paper over them...
If you have something that you know needs a lot of time to save data, it says you can configure the timeout and make it higher. Beyond that, that sounds like unjustified speculation. I don't recall data loss being a problem even in Mageia 2, and there's no way there needs to be some 2 minute long hang to cleanly shut a system down. Usually if I'm at a physical console of a system that's hanging like this I just do the 7x Ctrl-Alt-Delete to try to push through and it doesn't break anything.
Hear, hear. My shutdowns almost always hang waiting for osspd to terminate, and I have almost always resorted to ALT-PrScr-RSEIUB to complete shutdown. No data loss ever detected.
CC: (none) => ftg
(In reply to Frank Griffin from comment #3) > Hear, hear. My shutdowns almost always hang waiting for osspd to terminate, great, so figure out why it hangs and fix it
Or like the Phoronix article says, accept that how ever many of the possibly dozens of programs that don't shut down correctly aren't all going to be fixed and just change this brain-dead and unnecessary behavior by systemd.
(In reply to David Walser from comment #2) > If you have something that you know needs a lot of time to save data, it > says you can configure the timeout and make it higher. that suggestion goes both ways... if you want shorter timeouts, set it on your system.. > Beyond that, that > sounds like unjustified speculation. I don't recall data loss being a > problem even in Mageia 2, and there's no way there needs to be some 2 minute > long hang to cleanly shut a system down. Usually if I'm at a physical > console of a system that's hanging like this I just do the 7x > Ctrl-Alt-Delete to try to push through and it doesn't break anything. Well, if your system hags for 2 minutes on shutdown, you have something broken in your setum and should fix that properly, not work around it by killing processes... and just because it does not happend too break something (or you have not noticed it yet) does not mean it's a safe default... Anyway, I wont accept a change like that before it's properly tested, verified and merged upstream...
Resolution: (none) => WONTFIXStatus: NEW => RESOLVED
CC: (none) => mageia
Approved for Fedora 38, with an adjustment to 45 seconds, which should alleviate any concerns: https://www.phoronix.com/news/Fedora-38-Shutdown-Timer-45 As you may have noticed, we had complaints about this on qa-discuss recently too.
Status: RESOLVED => REOPENEDResolution: WONTFIX => (none)
Thank you DavidW for the link, which is clear enough on the subject. It should answer tmb's comment 6. Assigning to Basesystem.
CC: (none) => tmbAssignee: bugsquad => basesystem
IMHO changing the timeout from 90 to 45 seconds doesn't tell the causes. Isn't possible to debug where exactly is waiting for during the shutdown? What I also noticed (indeed the credit for this discover belongs to David Hodgins) is that if we under Plasma5 do a clean logout (that takes some seconds) and then an immediate shutdown, the shutdown is completed within a couple of seconds, without any long timeout (so it's certainly related to user processes or something in systemd related to user processes). Why for instance this delay is not detected in the plasma logout process (isn't that procedure using systemd now?)
CC: (none) => ghibomgx