How do I skip the 90s timeout in systemd

18,228

Solution 1

It is not possible. Systemd is noninteractive.

Solution 2

You have two options:

  1. You can set TimeoutStopSpec= on a specific UNIT to a specific value (in seconds*) to wait. You can also set it to infinity in which case SIGKILL will never be sent (not recommended as you may end up with runaway services that are hard to debug).

  2. Set DefaultTimeoutStopSec= inside /etc/systemd/system.conf (or user.conf, or in one of the *.d directories) to a default value that all UNITs that do not have TimeoutStopSpec= specified will use. The deafult for this setting is the 90s you normally see.

Man page references:

  • man systemd.service for TimeoutStopSpec=
  • man systemd-system.conf for DefaultTimeoutStopSec=

* 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.

Share:
18,228

Related videos on Youtube

lis2
Author by

lis2

merge me

Updated on September 18, 2022

Comments

  • lis2
    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
    lis2 over 7 years
    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.
  • lis2
    lis2 over 7 years
    Same 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
    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
    lis2 over 7 years
    I 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
    lis2 over 7 years
    In 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
    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
    Scrooge McDuck almost 4 years
    what a shame. there are cases in which the ability to interact with hanging jobs at runtime makes a 3 work hours difference at best.