Help with slow boot and shutdown of 16.04

I’ve seen this 90 sec “stop job is running…” previously in 15.10, but only occasionally, and now in the last 2 shut-downs in 16.04 it is here again. I did my fresh install just a few days ago! Doesn’t look like any solution is coming anytime soon. I also use U. Mate 14.04, and it never happens on that (no systemd!).

I didn’t know about the timeout time being user setable. I will use that. Thanks for this tip!

Hi Spyder

I do not have the problem in 16.04, it only happens in 16.10.

And isn’t there an option in 15.10 grub boot menu to revert to upstart for one session?

In 15.10, It didn’t happen very often, and I didn’t know when, so I pretty much ignored it. That 15.10 has now been replaced. We’ll see if two of these in a row is unusual, or a portent of something worse. In any case, changing the delay will help.

I just had the occasion to reboot my Dell laptop So instead I choose to shut down and do a fresh start from power up. Here are the times:
1-from clicking shut down to full power off > 7.68 sec
2-from power up to first grub screen >>>>>>> 16 sec
3-from power up to login prompt >>>>>>>>>> 53 sec
4-from power up to running >>>>>>>>>>>>> 72 sec

Processor 4x Intel® Core™ i3 CPU M 330 @ 2.13GHz
Memory 7839MB (1320MB used)
ATA TOSHIBA MK5056GS [500GB 7200 RPM 16MB Cache SATA 3.0]


That is slow! I tested a single core 64 bit boot in VirtualBox. It took 40 seconds from starting the virtual machine to up and running. You night want to look at your dmesg log to see if some device is hanging up the boot.

1 Like

Hi @anon83023755,

just keep updating, it should eventually solve the bug problem!:


This command may help identify what services are taking the longest to initialize:

systemd-analyze blame

Here’s a few lines from my output:

      7.234s NetworkManager-wait-online.service
      2.541s apt-daily.service
       532ms vboxdrv.service
       373ms dev-sda2.device
       354ms ModemManager.service
       329ms networking.service
       299ms accounts-daemon.service
       264ms timidity.service
       262ms php7.0-fpm.service
       230ms snapd.socket
       228ms systemd-logind.service
       227ms NetworkManager.service
       211ms lightdm.service
       209ms ssh.service

This is on an SSD, but that NetworkManager in this case is the culprit.

There was also a discussion over here on the long shut down times:


I’m attempting to speed up my laptop boot times [posted above 72 seconds]. I used [quote=“lah7, post:10, topic:5622”]
systemd-analyze blame[/quote] and found the top 26 listed processes on my system totaled 2.05 minutes. So can I assume that the listed programs are concurrent?
My slowest 10

13.640s	networking.service
13.560s	grub-common.service
13.416s	apport.service
13.344s	speech-dispatcher.service
13.298s	preload.service
13.246s	irqbalance.service
13.245s	ondemand.service
10.096s	lightdm.service
8.681s	NetworkManager-wait-online.service
7.865s	dev-sda5.device

My system:

Processor	4x Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz
Memory	7839MB (1320MB used)
ATA TOSHIBA MK5056GS [500GB 7200 RPM 16MB Cache SATA 3.0]

Is speech-dispatcher required and for what? if not required how to bypass / eliminate?

How can grub-common.service be accelerated?

NetworkManager-wait-online.service - laptop is connected to in home wifi - any way to accelerated?

dev-sda5.device = / ext4 on an extended partition - suggestion to accelerate?

1 Like

I'm not quite sure to whom That Is Slow! refers. Additionally booting a guest OS in an already running host is probably not a good comparison.

I suggest comparing boot times we use a benchmark to 'handicap' stastics ... I found a benchmark utility in Software Boutique that's gui driven and provides an extremely comprehensive output.

Certainly the entire report will be TMI for posting, but type cpu and 1 benchmark would provide others a comparison. Here's the type of output hardinfo produces:
Processor4x Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz
Memory7838MB (1289MB used)
Operating SystemUbuntu 16.04 LTS
User Namepfeiffep (Pete)
Date/TimeSat 30 Apr 2016 02:42:50 PM EDT
FPU Raytracing
This Machine1066 MHz5.699
Intel(R) Celeron(R) M processor 1.50GHz(null)40.8816714
PowerPC 740/750 (280.00MHz)(null)161.312647

The Operating System identifies OS = Ubuntu, in my case really UM 16.04LTS


Thanks for all the replies.

I’m gonna go along with @wolfman’s suggestion of regular updating.

But hat tip, among others, to pfeiffep for the inxi -ACDMNSG command and lah7 for systemd-analyze blame.

@anon42388993 For future ref. how do you open/save files like /etc/systemd/system.conf ?

1 Like

I’ll answer …
to view the contents of the file
cat /etc/systemd/system.conf
less /etc/systemd/system.conf

Editing system files and making a mistake can render your computer un-bootable

issue these commands as an example of how to edit /etc/systemd/system.conf
sudo prefacing the command elevates the privilege [you must enter you password but no text will appear]

  1. sudo cp /etc/systemd/system.conf /etc/systemd/system.conf.bu
    above makes a safety copy
  2. gksudo pluma /etc/systemd/system.conf
    launches MATE’s text editor with elevated privilege

Remember to save th file after you’ve made the desired changes.

Since you had to ask how … I strongly suggest posting here for guidance prior to making changes. Also if you want to learn please do practice on some files - the command cp will make a copy to your home directory.

Enjoy you journey!:slight_smile:


Another tip, you can type in this command to get timings of each part of the boot sequence, which can pinpoint which stage takes the longest.


i found out, that my installation of ubuntu mate 16.04 was also a bit slow. “sudo fdisk -l” showed me, that my linux partition was not correctly aligned on the ssd. could this be a reason, why its starting slowly?

Post a screenshot of your partition layout and maybe someone can help you decide!.

See also:

1 Like

A nice presentation is produced with
systemd-analyze critical-chain

my NetworkManager-wait-online.service was also taking about 8 seconds on my laptop

i ‘masked’ the service to stop it coming back, and now boot times are much quicker

[email protected] 20:09 ~ $ systemd-analyze Startup finished in 1.670s (kernel) + 3.096s (userspace) = 4.767s

[email protected] 20:09 ~ $ systemd-analyze blame 1.927s networking.service 1.636s plymouth-read-write.service 1.108s [email protected]:intel_backlight.service 867ms apt-daily.service 464ms dev-sda1.device 418ms nmbd.service 361ms samba-ad-dc.service 309ms gpu-manager.service 228ms smbd.service 196ms accounts-daemon.service 180ms systemd-logind.service <snip>

no ill-effects noticed so far crosses fingers :slight_smile:


systemctl mask name.service is rather drastic - rendering the actual unit file inaccessible to systemd.
this action can be reversed by systemctl unmask name.service

whereas systemctl disable name.service stops the service from being automatically started

Providing you absolutely know a service is never required in your setting disablle will work, OTOH preventing automatic start up at boot by setting disable renders the service available to systemd if required later.

in short:
mask = never available
disable = won’t start at boot available later if needed

yeah, i tried disable, but it seemed to come back again a day or two later, so i went drastic with it!

1 Like

I solved this annoying problem by first creating this small script:

ifconfig enp3s0 down
shutdown $* now

Change enp3s0 to whatever your network connection is called (use the ifconfig command with no options to see it).

This script must be given permission to run as root:

sudo visudo

Add the line:

ALL ALL = NOPASSWD: /path/to/script

Finally create a custom shutdown launcher in the panel, which executes this command:

sudo /path/to/script

I also created a reboot launcher, which executes this command:

sudo /path/to/script -r

Very disappointing that Ubuntu MATE goes out on the internet and does who-knows-what when I order it to shut down. This is the sort of Windowsy BS I had hoped to avoid :disappointed:

1 Like

Thanks paxxus…good tip and I hadn’t realised what was causing the delay.