More info on why Fedora 38 did this here and to do it you may edit the DefaultTimeoutStopSec= setting in /etc/systemd/system.conf. You may also create a drop-in to change the TimeoutStopSec= setting for user@service
I personally don’t like this change by default. Sometimes things legitimately take more time to shut down and cutting to 45 seconds means killing those things prematurely.
That being said, anyone is free to make this change on their own system if it is their preference.
5 Likes
At least according to the linked page about this change in Fedora 38, the devs didn’t find any issues in testing when the timeout was set to 45s.
I regularly see things taking longer than 45 seconds.
It is totally dependent on use case.
Just because one is doing it, doesn’t mean everyone else should.
But if you think it’s a good default, Fedora may be the best distro for you.
1 Like
Fedora isn’t Arch and i also think it depends on some hardware may have issues.
well, in theory those services that legitimately take longer than 45 seconds can set their own timeout which can be higher than 45 seconds and that way supersede the default Timeout.
I am pretty sure this change will be upstreamed and become the systemd default at some point, but we at EndeavourOS should not jump into the test ship that Fedora launched. Arch will decide if they adapt that change early and if they do, they will hopefully make the necessary changes to the relevant service files, too.
3 Likes
so fedora tore out/disabled the systemd watchdog service? or they co-exist? or is this conceptually going over my head (very plausible)?
I run Fedora everday and this is the best I could find in their documentation about watchdog:
I ran 37/38 for a while, I used to read the Docs a lot!
Best I remember watchdog is a service (timeouts for shutdown) that does the same thing as the shorter decrease would do…of course I don’t know how it worked in conjunction with the longer decrease so I;ll quit while I’m not ahead.
thanks for the info
You’re welcome. Admittedly I know little about Fedora compared to Arch. The whole point of Fedora was that I do nothing and update. I would like to keep that theme running as long as possible.
Fedora was magnificent in its stability. I went from 37 to 38 seamlessly but so many did not on the forums. DNF was easy, updates easy. I didn’t feel challenged so I went to Archer pastures. I have a solid #2 distro like you, so I know the value. I don’t see why you could not keep that theme running as long as possible. It’s all in the right DE for one at fedora and spins. Sorry for mini-hijack.
IMO, if any service is taking more than 10 seconds to stop, that service is broken and needs to be fixed. I give them 10 seconds to stop, and not a second more.
1 Like
That is a pretty bold statement.
docker services or vmware services, where complete server environments are running in the background, can certainly take longer than 10 seconds to shutdown.
personal example: I have a nextcloud vmware running in the background on my home PC. Depending on the task that nextcloud is currently running (maintenance, os update, etc.) it can easily take 1-2 minutes to shut down. And during that time it should not be forcefully terminated.
So, I say no, services taking longer than 10 seconds to stop are not necessarily broken. They can be busy and need more time to finish.
2 Likes
Ok, I understand. Should I delete this forum post?
1 Like
No. This is a useful thread for all other users with a similar question.
I guess from a server perspective, yes, that’s true. But I’ve never liked Arch as a server distro, so never occurred to me.
So, my amended statement would as “Being I use it only as a desktop OS, if any…”
Many people run containers on their desktops to isolate applications or provide services…
There are many services people run on the desktop that need more than 10 seconds to shut down.
You might not use any of those, but that doesn’t mean other people don’t.
Did they list what they actual tested? One thing I notice is many projects say they tested … then you ask for the use cases they tested you realize they had little to no test coverage. It gets even worse if the project has a private bug tracker … so you can’t see what problems they hit after the configuration change.
Maybe a better baby step is to log and capture what processes utilize the time out when shutdown … and then how long did they take to shutdown (did they use the whole 2 mins and 45 seconds).
Utimately the timeout is really to let a service shut down cleanly (like Dalto said) and avoid data corruption. If you are seeing regular use of the timeout setting … maybe time to find out why the service is needing to utilize the time out?
What suprises me is why such a specific time change … 2min and 45 seconds … to 45 seconds? Why not an even 1 minute.
Maybe slower CPU need the extra time to cleanly shutdown a service?