Shutdown delayed?

Why’s the shutdown so slow, it takes really long time, almost like nothings happening. What can I do to make shutdown instant?

It happens to me in virtual machines every once in a while, usually after updates, and I’d like to hear from anyone that’s tracked down exactly why.

And it’s compounded by systemd being configured for 90 seconds for everything to wrap up. 90 SECONDS! Gee, how much would anything have to do, really?

I change to 15 seconds. Still slow but not as ridiculous. Here is part of my current /etc/systemd/system.conf

#DefaultStandardError=inherit
#   This changed per item #4 of
#   https://ubuntu-mate.community/t/ubuntu-mate-16-04-lts-common-problems-known-bugs-workarounds/8340
DefaultTimeoutStartSec=15s
DefaultTimeoutStopSec=15s
TimeoutSec=15s
#   End Changes
#DefaultRestartSec=100ms

This makes it more tolerable. Hopefully, someone can be more specific as it should shut down in only a few seconds these days.

1 Like

If you mount some remote locations using NFS, be sure you unmount them before shuting down to avoid this delay.

There are mount options to instruct systemd to “do the right thing” when mounting and unmounting.

My shutdown typically takes only about 3 seconds.

Sometimes, it runs around 20 seconds.

Interesting.

My system.conf has everything commented out. ??

Yep. The top of the file explains it:

# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.

Thanks.

I assume you have already tried the default before you made mods.

How long does your shutdown take ?

I have virtual machines of 16.04. 17.04 and 17.10 and each later version shuts down quicker than the previous - maybe 6 seconds to 2 seconds or so. But that’s a normal shutdown. I’ve really noticed it IS getting faster.

Every once in a while, one takes an extra long time and I’ve timed it at 90 seconds. Thus, something prevents quick shutdown in these cases. But once I see this I can’t make that above change quick enough. Sure enough, I now occasionally get 15 instead of 90 seconds.

I don’t think I’ve ever seen this slow shutdown on my main box on 16.04 which typically takes 2-3 seconds. Startup grub-to-login is 6 seconds (SSD).

Interesting.

Do you use virtual machines for testing of various distros?

Lol, this one time I shut my computer down and then went on a 5 day vacation.

Came back and it was still shutting down. Just displayed that ubuntu mate symbol on the green background.

I laughed so hard.

Oh yes. Right now I’m looking at Debian Stretch.

Shutdown seems okay for now, but sometimes it just gets stuck and that too when the system is on back up power and is required to shut down fast. The system.conf file of mine has # before every line. My bluetooth is showing a red cross sign and I haven’t turned it on, maybe it was causing the shutdown delay issue? coz it seems fine now and I don’t need bluetooth so I’ll keep it that way.

Also, I am not running any thing else, only firefox, calc and rhythmbox/vlc and I only have single hdd with ubuntu-mate on it and I keep a pen drive plugged in for document back ups.

This is a service problem. Some service is halting the shutdown process. And until we know which one, there is nothing to do but speculate.

So, how to start solving it? We can start by trying to identify the service. After you experienced one of those prolonged boot situations, be patient. When it finally shuts down, boot normally and then type on a terminal:

$ journalctl -rb -1

The above command will display the logs of the last boot in reverse order (with newer entries at the top). Paste the first 20-30 lines or so on this thread.

@Bill_MI, I don’t advise changing that setting. For two reasons: you are just circumventing the problem without solving it and, what’s worst, you are doing it on the wrong setting :wink:

The DefaultTimeout{Start|Stop}Sec= and DefaultRestartSec= options govern unit start/stop timeouts globally during the whole of your runtime. And you wish to leave them at their sane defaults since some units could conceivably require more than your proposed 15s to start or stop and you would just be timing them out instead. Any change to these values should be only made on a per unit basis, on their respective unit files. Both service and non-service units have timeout options that override these global defaults and that can be defined on their respective sections of the unit file. So I could, for instance, configure the avahi-daemon.service to timeout at 10s when starting and 15s when stopping. What I wouldn’t want to do was setting this for EVERY unit. Which is what you are doing.

The more appropriate way is to enable an hardware watchdog. There are two global watchdogs available. The one that interests you is ShutdownWatchdogSec= which you can set on your systemd.conf file for 15s. It will have the desired effect and will only affect unit stop operations during the system shutdown or reboot, not during runtime.

However, be aware that ideally you want to first identify the source of the problem. The unit that is hanging. Depending on what unit this is and what can be done about it, if nothing can be done you can set an hardware watchdog on that unit, or set its personal timeout as explained above, and that will be a better solution than setting it globally. However, more often than not identifying the unit should be enough to understand what is hanging it.

3 Likes

Hi @marfig and thanks for the helpful info. Now that I have looked at this, of course, the slow shutdown is hard to create via Murphy’s Law. I happen to be looking at a VM of 17.10 which was creating them pretty regular.

I find ShutdownWatchdogSec= defaults to 10 minutes! With the runtime timeouts defaulting to 90 seconds I don’t think I’ve ever seen it go 10 minutes but I’m at 15s now and returned the others as they were.

I did not have a slow shutdown but tried the command anyway. Looks like this journal needs to be enabled?

$ journalctl -rb -1 -n20
Specifying boot ID has no effect, no persistent journal was found
$ sudo journalctl -rb -1 -n20
Specifying boot ID has no effect, no persistent journal was found
$ 

Thanks again.

Oh right! Forgot about that small (big) detail. The default Ubuntu MATE installation does not create /var/log/journal. So, the Storage=auto option in /etc/systemd/journald.conf falls back to volatile logs. All you have to do to enabled persistent logs is to create the directory where these logs are stored:

$ sudo mkdir /var/log/journal


Note 1: You can periodically run $ journalctl --vacuum-time=1month to clean up journal files older than one month, for example. Or --vacuum-size=100M to clear the directory to a maximum of 100 MB. You can also find size limitation options on the journald configuration file. See man journald.conf for details.

Note 2: As I was rummaging around my Ubuntu MATE trying to understand why you didn’t have persistent logs, I also bumped into something I had forgotten when I suggested the command on my earlier post. The -n and -r options are currently not working well together due to a bug. So I want you to use the following command instead:

$ journalctl -rb -1

I’m also editing that post to remove the -n option.

1 Like

Hi marfig,

Thanks for the command suggestion, I fried my board the other day and couldn’t log into my system, I got a new one now but shutdown seems normal for now but I will report back the next time it halts with the result of that command.

Thanks