How do I skip the 90s timeout in systemd
Solution 1
It is not possible. Systemd is noninteractive.
Solution 2
You have two options:
You can set
TimeoutStopSpec=
on a specific UNIT to a specific value (in seconds*) to wait. You can also set it toinfinity
in which case SIGKILL will never be sent (not recommended as you may end up with runaway services that are hard to debug).Set
DefaultTimeoutStopSec=
inside/etc/systemd/system.conf
(oruser.conf
, or in one of the*.d
directories) to a default value that all UNITs that do not haveTimeoutStopSpec=
specified will use. The deafult for this setting is the 90s you normally see.
Man page references:
man systemd.service
forTimeoutStopSpec=
man systemd-system.conf
forDefaultTimeoutStopSec=
* systemd also accepts time specs, e.g. "2min 3s". That's extensively described in the man.
Solution 3
You can uncomment in /etc/systemd/system.conf
the lines:
DefaultTimeoutStartSec=90s
DefaultTimeoutStopSec=90s
And change the value to what you consider appropriate.
Related videos on Youtube
Comments
-
lis2 over 1 year
Is it possible to interactively skip the 90s timeout in systemd? For example, when it is waiting for a disk to become available or user to log out? I know it will fail eventually, so can I just make it fail now? I hate just staring at the screen helplessly.
-
lis2 over 7 yearsThis is not interactive. When the systemd is already counting down the 90s, it is too late to make these changes and I am forced to sit though it helplessly.
-
lis2 over 7 yearsSame as the other answer, this is not interactive. When the systemd is already counting down the 90s, it is too late to make these changes and I am forced to sit though it helplessly.
-
grochmal over 7 years@JiriDanek - that is because systemd isn't interactive, it is not meant to be. Your tty process (in which you see the 90s) runs as a child of init (sytemd), i.e. the process showing (getty) the 90s is a child of the process counting them (systemd). And moreover, systemd ignores most signals. systemd is not meant to be controlled by a random user in front of a tty (that would be a huge security risk).
-
lis2 over 7 yearsI am primarily a desktop user, so I tend to see the things differently. Remember Torvalds' daughter's printer? Many design inadequacies can be justified by security concerns.
-
lis2 over 7 yearsIn my specific case, the writer of the unit file is innocent. I just made a typo when copy-pasting a disk UUID. I simply found it irritating having to wait for full minute and half before systemd gave up mounting that and let me get into the system and fix the problem. The long timeout actually makes sense here. Except when I the admin know it doesn't.
-
grochmal over 7 years@JiriDanek - Then I'd argue that the default delay should be longer. It will ensure that sysadmins are more careful on not making typos (and/or testing their configuration changes) :D
-
Scrooge McDuck almost 4 yearswhat a shame. there are cases in which the ability to interact with hanging jobs at runtime makes a 3 work hours difference at best.