Mdthbs

Olive oil in Japanese cooking

Can I deep fry food in butter instead of vegetable oil?

Isn't "Dave's protocol" good if only the database, and not the code, is leaked?

Blood-based alcohol for vampires?

Does this circuit have marginal voltage level problem?

Are the plates of a battery really charged?

Yield on municipal bonds versus treasury

Did Stalin kill all Soviet officers involved in the Winter War?

Is there any connection between "Whispers of the heart" and "The cat returns"?

Old story where computer expert digitally animates The Lord of the Rings

Is it possible to spoof an IP address to an exact number?

Was Wolfgang Unzicker the last Amateur GM?

What does "another" mean in this case?

How did sloshing prevent the Apollo Service Module from moving safely away from the Command Module and how was this fixed?

gzip compress a local folder and extract it to remote server

How can solar sailed ships be protected from space debris?

Show that there are infinitely more problems than we will ever be able to compute

what is the meaning of "stock" dilution on the Massive Dev Chart Website?

Use real text instead of lipsum in moderncv quote alignment

Recolour existing plots

SQL Server error 242 with ANSI datetime

Is my background sufficient to start Quantum Computing

What instances can be solved today by modern solvers (pure LP)?

PhD: When to quit and move on?

How do I skip the 90s timeout in systemd

“A stop job is running” for a long time when shutting down Kali LinuxHow to change systemd service timeout value?mount samba shares at boot with systemdMinecraft server startup/shutdown with systemdApplication log files to the systemd journalHow do I see when a systemd service was started/stopped/restarted?Relation between systemd service names and journald entriesHow to get user in systemd unit who caused an eventServices won't start after booting until after logging in through the virtual consoleHow to safely shutdown every running VM during Restart/Shutdown in Qubes OS 4.0 without incurring a stall/delay due to a timeout? (systemd issue)

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}

11

1

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.

systemd systemd-boot

share|improve this question

asked Sep 15 '16 at 17:46

user7610user7610

54811 gold badge77 silver badges1919 bronze badges

add a comment | 

11

1

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.

systemd systemd-boot

share|improve this question

asked Sep 15 '16 at 17:46

user7610user7610

54811 gold badge77 silver badges1919 bronze badges

add a comment | 

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.

systemd systemd-boot

share|improve this question

asked Sep 15 '16 at 17:46

user7610user7610

54811 gold badge77 silver badges1919 bronze badges

share|improve this question

asked Sep 15 '16 at 17:46

user7610user7610

54811 gold badge77 silver badges1919 bronze badges

share|improve this question

asked Sep 15 '16 at 17:46

user7610user7610

54811 gold badge77 silver badges1919 bronze badges

asked Sep 15 '16 at 17:46

user7610user7610

54811 gold badge77 silver badges1919 bronze badges

asked Sep 15 '16 at 17:46

user7610user7610

54811 gold badge77 silver badges1919 bronze badges

3 Answers
3

active

oldest

votes

10

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

share|improve this answer

edited 56 mins ago

dhag

11.7k33 gold badges3434 silver badges4747 bronze badges

answered Sep 15 '16 at 18:21

grochmalgrochmal

6,00633 gold badges1717 silver badges4848 bronze badges

• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  
  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
  Sep 16 '16 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
  Sep 16 '16 at 16:49
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  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
  Sep 16 '16 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
  Sep 16 '16 at 18:04
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  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
  Sep 16 '16 at 18:15
  

  
  
  
  

 | 
show 1 more comment

4

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

DefaultTimeoutStartSec=90s

DefaultTimeoutStopSec=90s

And change the value to what you consider appropriate.

share|improve this answer

answered Sep 15 '16 at 18:20

MsegadeMsegade

31511 gold badge33 silver badges1111 bronze badges

• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  
  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
  Sep 16 '16 at 7:41
  

  
  
  
  

add a comment | 

4

It is not possible. Systemd is noninteractive.

share|improve this answer

answered Sep 16 '16 at 17:05

user7610user7610

54811 gold badge77 silver badges1919 bronze badges

add a comment | 

Your Answer

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f310146%2fhow-do-i-skip-the-90s-timeout-in-systemd%23new-answer', 'question_page');
}
);

Post as a guest

Name

Email

Required, but never shown

10

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

share|improve this answer

edited 56 mins ago

dhag

11.7k33 gold badges3434 silver badges4747 bronze badges

answered Sep 15 '16 at 18:21

grochmalgrochmal

6,00633 gold badges1717 silver badges4848 bronze badges

• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  
  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
  Sep 16 '16 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
  Sep 16 '16 at 16:49
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  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
  Sep 16 '16 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
  Sep 16 '16 at 18:04
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  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
  Sep 16 '16 at 18:15
  

  
  
  
  

 | 
show 1 more comment

10

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

share|improve this answer

edited 56 mins ago

dhag

11.7k33 gold badges3434 silver badges4747 bronze badges

answered Sep 15 '16 at 18:21

grochmalgrochmal

6,00633 gold badges1717 silver badges4848 bronze badges

• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  
  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
  Sep 16 '16 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
  Sep 16 '16 at 16:49
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  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
  Sep 16 '16 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
  Sep 16 '16 at 18:04
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  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
  Sep 16 '16 at 18:15
  

  
  
  
  

 | 
show 1 more comment

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

share|improve this answer

edited 56 mins ago

dhag

11.7k33 gold badges3434 silver badges4747 bronze badges

answered Sep 15 '16 at 18:21

grochmalgrochmal

6,00633 gold badges1717 silver badges4848 bronze badges

share|improve this answer

edited 56 mins ago

dhag

11.7k33 gold badges3434 silver badges4747 bronze badges

answered Sep 15 '16 at 18:21

grochmalgrochmal

6,00633 gold badges1717 silver badges4848 bronze badges

edited 56 mins ago

dhag

11.7k33 gold badges3434 silver badges4747 bronze badges

edited 56 mins ago

dhag

11.7k33 gold badges3434 silver badges4747 bronze badges

answered Sep 15 '16 at 18:21

grochmalgrochmal

6,00633 gold badges1717 silver badges4848 bronze badges

answered Sep 15 '16 at 18:21

grochmalgrochmal

6,00633 gold badges1717 silver badges4848 bronze badges

4

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

DefaultTimeoutStartSec=90s

DefaultTimeoutStopSec=90s

And change the value to what you consider appropriate.

share|improve this answer

answered Sep 15 '16 at 18:20

MsegadeMsegade

31511 gold badge33 silver badges1111 bronze badges

• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  
  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
  Sep 16 '16 at 7:41
  

  
  
  
  

add a comment | 

4

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

DefaultTimeoutStartSec=90s

DefaultTimeoutStopSec=90s

And change the value to what you consider appropriate.

share|improve this answer

answered Sep 15 '16 at 18:20

MsegadeMsegade

31511 gold badge33 silver badges1111 bronze badges

• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  
  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
  Sep 16 '16 at 7:41
  

  
  
  
  

add a comment | 

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

DefaultTimeoutStartSec=90s

DefaultTimeoutStopSec=90s

And change the value to what you consider appropriate.

share|improve this answer

answered Sep 15 '16 at 18:20

MsegadeMsegade

31511 gold badge33 silver badges1111 bronze badges

DefaultTimeoutStartSec=90s

DefaultTimeoutStopSec=90s

share|improve this answer

answered Sep 15 '16 at 18:20

MsegadeMsegade

31511 gold badge33 silver badges1111 bronze badges

answered Sep 15 '16 at 18:20

MsegadeMsegade

31511 gold badge33 silver badges1111 bronze badges

answered Sep 15 '16 at 18:20

MsegadeMsegade

31511 gold badge33 silver badges1111 bronze badges

4

It is not possible. Systemd is noninteractive.

share|improve this answer

answered Sep 16 '16 at 17:05

user7610user7610

54811 gold badge77 silver badges1919 bronze badges

add a comment | 

4

It is not possible. Systemd is noninteractive.

share|improve this answer

answered Sep 16 '16 at 17:05

user7610user7610

54811 gold badge77 silver badges1919 bronze badges

add a comment | 

It is not possible. Systemd is noninteractive.

share|improve this answer

answered Sep 16 '16 at 17:05

user7610user7610

54811 gold badge77 silver badges1919 bronze badges

share|improve this answer

answered Sep 16 '16 at 17:05

user7610user7610

54811 gold badge77 silver badges1919 bronze badges

answered Sep 16 '16 at 17:05

user7610user7610

54811 gold badge77 silver badges1919 bronze badges

answered Sep 16 '16 at 17:05

user7610user7610

54811 gold badge77 silver badges1919 bronze badges