26

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.

Improve this question

3 Answers 3

Reset to default
17

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.

Improve this answer
6
  • 15
    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.
    – user7610
    Commented Sep 16, 2016 at 7:40
  • @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).
    – grochmal
    Commented Sep 16, 2016 at 16:49
  • 5
    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.
    – user7610
    Commented Sep 16, 2016 at 17:04
  • @JiriDanek - systemd is not a concern, it would be an actual attack vector. If you could aim a correct signal at the right moment you could (as a common user) disable a system service (e.g. SELinux). Just go into /etc/systemd/system.con and add DefaultTimeout=3. Or, better, fix the service that is failing. The fact that some service always fail is not bad design of systemd, is bad design of the person who wrote the unit file.
    – grochmal
    Commented Sep 16, 2016 at 18:04
  • 1
    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.
    – user7610
    Commented Sep 16, 2016 at 18:15
10

It is not possible. Systemd is noninteractive.

In 2023, Fedora 38 shortened the default timeout duration to 45s.

Improve this answer
1
  • 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.
    – Scrooge McDuck
    Commented Jun 20, 2020 at 2:08
7

You can uncomment in /etc/systemd/system.conf the lines:

DefaultTimeoutStartSec=90s
DefaultTimeoutStopSec=90s

And change the value to what you consider appropriate.

Improve this answer
1
  • 10
    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.
    – user7610
    Commented Sep 16, 2016 at 7:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .