Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#77186 - [systemd] Reduce default systemd service timeout to 15s

Attached to Project: Arch Linux
Opened by Mark (markg85) - Thursday, 19 January 2023, 11:26 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:14 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Christian Hesse (eworm)
Levente Polyak (anthraxx)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


Sometimes when you reboot an Arch running device you're "welcomed" with some service failing to shutdown (or taking really long) for whatever reason.
On a desktop where you see this happening the fix is brutal but easy. Force reset the device.
I admit that this doesn't happen often but when it does it's annoying.

When your Arch machine runs in a headless environment this failure to shutdown can take insanely long and is much harder to see!
I therefore propose to, in this specific case, follow Fedora's lead and kill a service after 15 seconds.
You can find their change to systemd to achieve this here:

And their arguments are here:
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:14 GMT
Reason for closing:  Moved
Additional comments about closing: ackaging/packages/systemd/issues/8
Comment by Toolybird (Toolybird) - Friday, 20 January 2023, 02:40 GMT
15s is too aggressive IMHO. Fedora have amended their proposal to be 45s [1] which is probably more reasonable. Similar to Fedora, Arch should probably consider this at the distro level (RFC anyone?) instead of at the pkg level.

Comment by Christian Hesse (eworm) - Friday, 20 January 2023, 06:28 GMT
I agree with Toolybird... This is a change we should not include on our own, but propose it upstream.
Comment by Mark (markg85) - Friday, 20 January 2023, 14:06 GMT
Fedora does this because upstream got stalled.

Specifically this part:
An attempt has also been made to have the unit timeout changed in upstream systemd. That attempt did not go anywhere, despite various efforts to move it along. We are no longer comfortable waiting for upstream changes to land.
And this PR as reference in upstream:
Comment by loqs (loqs) - Friday, 20 January 2023, 16:42 GMT
Does upstream's proposed change address the issue for you? This passes all tests for me on stable-252 and main. If it works for you then you could ask upstream to rebase the change and run the tests again.
If upstream's fix does not address the issue for you, then please provide them with additional feedback on what other changes are required.
Comment by Mark (markg85) - Friday, 20 January 2023, 17:00 GMT

I don't have a specific testcase where this timeout is annoying. Sometimes a service just doesn't want to shutdown. I've seen the login manager (sddm), networkmanager and a couple others i don't remember by name.
It makes sense in a general approach - preferably on systemd upstream level, but if they are stalled in discussions then on a distribution level - to force kill applications after X seconds.
A patch should most certainly not be done on a user-level, as you seem to suggest now. That patch, if not careful with updates, will be gone without noticing it once there is a systemd update.

I don't care if X is defined as 5 seconds or 90 seconds or anything in between. But I do care if there is no X and a shutdown can take indefinitely because of an applications not shutting down properly. This, although rarely, does happen.
Comment by loqs (loqs) - Friday, 20 January 2023, 17:09 GMT
The upstream change would not help for sddm or NetworkManager as it only changes the timeout for user services not system services.
I was assuming you had a reproducible issue this addresses that you could test the patch against.
Upstream stalled as the PR introduced test failures. If a rebased version of the commit no longer does I expect it would be accepted.
You are aware you can locally set in /etc/systemd/system.conf for system services DefaultTimeoutStartSec DefaultTimeoutStopSec DefaultTimeoutAbortSec DefaultDeviceTimeoutSec
and in /etc/systemd/user.conf for user services DefaultTimeoutStartSec DefaultTimeoutStopSec DefaultTimeoutAbortSec
which will be preserved through package updates subject to normal config merging.
Comment by Mark (markg85) - Friday, 20 January 2023, 18:03 GMT
Ohh awesome! I wasn't aware of that, thanx for letting me know!

Now this makes more sense. In that file i see defaults of 90 seconds but commented out.
I think want i actually want to suggest is to have this enabled by default!
Comment by Mark (markg85) - Tuesday, 01 August 2023, 15:42 GMT
Just got a mail about an update in this issue (title change) :)
It does remind me of this one though.

I - at least once - had the super annoying situation where i remotely ssd'ed into my machine and had to reboot it for something (i think it was a kernel update).
It never came back.
Just when i got home a couple days later to check what the hell was wrong i noticed it was waiting for a process to exit (no clue which one it was, too long ago).
While that was a weird once in a whatever big number event, i did many more times have the same situation where it took minutes up till hours. Nearly always it eventually works...

Having the default enabled (be it 15 or 45 seconds or even 5 minutes) would be much appreciated.

I strongly disagree that arch should not do this in hopes to wait for upstreeam to get their act together. No clue what kind of political games they play, but this is imho an essential feature of a stable system that needs to be enabled to safeguard against crap applications not wanting to quit.