Regarding: DefaultTimeoutStartSec=?/DefaultTimeoutStopSec=?

Tips, Tricks and Tutorials Tips & Tricks
#1

A hefty amount of research indicates that, despite popular sentiment, it is not wise to set the ‘DefaultTimeoutStartSec=10s’ (note the ‘Start’ entry here)

First off, it does not help with any apparent systemd bugs, lagging daemons, programs that won’t quit, or any other shutdown/reboot issues. Instead, what it will likely lead to, I am finding out, are problems with journald during boot, like described below:

systemd[1]: Failed to start Journal Service.
systemd[1]: Dependency failed for Flush Journal to Persistent Storage.
systemd[1]: systemd-journal-flush.service: Job systemd-journal-flush.service/start failed with result 'dependenc
systemd[1]: systemd-journald.service: Unit entered failed state.

In all of the relevant cases, the reason for the above error was that the user had their /etc/systemd/system.conf set to either:

DefaultTimeoutStartSec=10s
DefaultTimeoutStopSec=10s

                  or

DefaultTimeoutStartSec=6s
DefaultTimeoutStopSec=6s

By commenting out ‘# DefaultTimeoutStartSec=10s’ or setting it to a higher value (30s) the issue was solved for all of those (I could find) with applicable issues.

Moreover, a dozen or more threads indicate that those who modified their value for ‘DefaultTimeoutStopSec=10s’ should re-adjust that value to at least '=30s.' This would be to ensure, especially on older machines, that a clean unmounting on shutdown/reboot is fully possible.

Not to step on anyone’s advice which may contradict parts of this. :cold_sweat:

I looked at a couple of dozen threads; but this this post (below) sums up most of the pertinent stuff: :relaxed:

https://bbs.archlinux.org/viewtopic.php?id=210164

2 Likes
Acer Laptop not shutting down properly
#2

Do you have a thread that indicates another way to have reasonable shutdown times under Ubuntu 16.04 LTS?

Because sorry but I don’t care that my disks are unmounted properly if it takes one and a half freaking minute to do so. :/

1 Like
#3

That would only be 1/3 of the time you are referring to; after all this is in the Tips & Tricks section - you know, hopefully safe stuff… hopefully. :smile:

Keep in mind that without a bit of digging, this issue cannot be fully addressed. We are looking at systemd bugs, lagging daemons, programs that won’t quit, or any other number of shutdown/reboot issues; so this configuration tweak should strictly be looked at as merely a workaround.

But the moral to this story is 30s for start and 30s for stop; if you must tweak this configuration. Moderation allows us to go further in life, I have found, as I move on through my second half century of life. :wink:

#4

Well, I see your point.
Still, even 30s is way too long for me. I mean seriously it’s the fault of GNU/Linux. I got so used to booting and shutting down under 10 seconds that now anything more than that is painful.
I guess someone freshly rescued from the evil grip of Microsoft wouldn’t be able to tell the difference though so hopefully that won’t bother the new users too much.
Hopefully those bugs will be fixed by the time 16.04.1 is released.

Cheers

2 Likes
#5

Hi mated

I wanted to point out default start/stop time is 90 seconds. I would think setting it to 30 seconds would be way safe, but who wants to wait that long.

I don’t think one post can sum it up. I have found in linux there is usually more than one way to get something done. In my case setting start/stop to 10s has worked for a month.

For others it may not (as mention).

At anyrate, its just a work-a-round and will soon become history when a fix comes out.

Also…
I am up to speed on what your talking about, but most of the community is not. Your post jumps right into systemd without giving any background. I think that will turn away viewers. Just a thought :slight_smile:

1 Like
#6

Hello

Thanks for this, I am a bit of a novice when it comes to this kind of thing, how do I go about putting this in?

i.e. - >

DefaultTimeoutStartSec=6s
DefaultTimeoutStopSec=6s

I guess it’s in the Terminal.

Thanks,

Phil.