Help with slow boot and shutdown of 16.04

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:
Computer
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

Regards,
Pete

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
or
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:

2 Likes

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.

systemd-analyze
2 Likes

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

angelo@thinkpad 20:09 ~ $ systemd-analyze Startup finished in 1.670s (kernel) + 3.096s (userspace) = 4.767s

angelo@thinkpad 20:09 ~ $ systemd-analyze blame 1.927s networking.service 1.636s plymouth-read-write.service 1.108s systemd-backlight@backlight: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:

hmmm…

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:

#!/bin/bash
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.

That’s not what it’s doing.
Also this is not specific to Ubuntu MATE. Ubuntu is also affected. As well as Debian, as well as any other Debian-based distro.
The reason for this is a design decision in Systemd.

1 Like

OK, I just saw that the big delay was gone when I first disconnected the network. Since you seem to know, could you elaborate a little on what it is it’s doing - I’m struggling to understand what else there is to do other than flushing the disk write buffer (= instant with SSD).

If I could somehow find out what process or whatever it’s waiting for, I could augment my script with a more brutal kill of that process…

So here’s the thing.
Ubuntu, following Debian, changed to Systemd as an init system in recent releases.
The shutdown sequence under Systemd now function like this:

  • When the shutdown is initiated, every running service is sent a SIGTERM signal.

There are many different signals you can send to processes under Linux, and the main two you have to understand for the issue at hand are SIGTERM and SIGKILL.

SIGTERM and SIGKILL usually produce the same results: the process that receive those signals terminates.

The difference between the two is that SIGTERM can be intercepted by the process. Any correctly-implemented process is supposed to use this as a chance to do some cleanup work, and then exit once the cleanup is complete.

  • There is a 90s timeout after the wave of SIGTERM is sent. Once it expires, every process still alive is sent a SIGKILL.

The problem we’re experiencing with slow shutdown comes from the fact that some processes aren’t handling the SIGTERM like we would want them to. (or, according to the latest comments on @anon42388993’s link to other bug above, some processes are not receiving the SIGTERM to begin with)

It’s not always the same process that causes the hangup either. See this other thread.

I think a lot of those processes are waiting from some kind of response from the network (like CUPS, Apport and Networkmanager for instance) which is why manually killing the interfaces beforehand makes them die faster.

That behavior was first described here: Bug #1457400

If you read down the comments, it is possible to change that timeout value, and a number of users here have done exactly that without encountering adverse side-effects.

Now we’ve discussed it with one of the systemd maintainers for Ubuntu and we can’t expect the value to be changed because it wouldn’t be right by the SRU guidelines. The maintainer made a good argument too. Database engines sometime take a while to shut down.

So basically I agree with you that it’s a pain, but sadly other than editing that config file there’s not a lot we can do.

5 Likes

Thanks for the explanation. Hopefully the misbehaving apps will eventually be identified and fixed in the distro - it really gives a very bad impression of linux for newcomers and potential converts. In fact, people will laugh - even Windows is pretty fast these days. I’m mildly surprised that the developers can accept such annoying flaws, but hey, it’s free and it can be brought to work with a little hacking :relaxed:

2 Likes

That’s because newcomers mostly think of Linux as ‘The guy who wrote the entire thing’. It’s fundamentally different in that it’s just a kernel and the ‘apps’ are done by thousands of others. It’s simply not possible to make apps perfectly working together when they are developed separately.

This is the first thing newcomers should learn.

2 Likes

One could argue that the sole purpose of a distro is to select among those thousands of apps a sub-set which work well together…

i Had installed debian on my laptop and now i have tripal booted laptop with win7,ubuntu16.04,debian 9(which have bugs).But now the ubutnu is taking more time to boot up.I think that it is booting two times(I am noob)
.here is the output of the command systemd-analyze blame

15.048s dev-sda2.device
     10.180s keyboard-setup.service
      9.765s systemd-tmpfiles-setup-dev.service
      8.491s systemd-sysctl.service
      6.719s NetworkManager-wait-online.service
      4.220s grub-common.service
      3.500s upower.service
      2.981s ModemManager.service
      2.427s systemd-udev-trigger.service
      1.752s systemd-logind.service
      1.718s speech-dispatcher.service
      1.712s alsa-restore.service
      1.697s thermald.service
      1.596s systemd-modules-load.service
      1.470s NetworkManager.service
      1.293s accounts-daemon.service
      1.221s systemd-journald.service
      1.163s avahi-daemon.service
      1.155s polkitd.service
      1.044s resolvconf.service
      1.008s lightdm.service
       771ms ufw.service
       697ms systemd-fsck@dev-disk-by\x2duuid-b9c06585\x2d9538\x2d46f4\x2d9a
 lines 1-23...skipping...
     15.048s dev-sda2.device
     10.180s keyboard-setup.service
      9.765s systemd-tmpfiles-setup-dev.service
      8.491s systemd-sysctl.service
      6.719s NetworkManager-wait-online.service
      4.220s grub-common.service
      3.500s upower.service
      2.981s ModemManager.service
      2.427s systemd-udev-trigger.service
      1.752s systemd-logind.service
      1.718s speech-dispatcher.service
      1.712s alsa-restore.service
      1.697s thermald.service
      1.596s systemd-modules-load.service
      1.470s NetworkManager.service
      1.293s accounts-daemon.service
      1.221s systemd-journald.service
      1.163s avahi-daemon.service
      1.155s polkitd.service
      1.044s resolvconf.service
      1.008s lightdm.service
      771ms ufw.service
      697ms systemd-fsck@dev-disk-by\x2duuid-b9c06585\x2d9538\x2d46f4\x2d9af5\x2d96a5e822437f.service
       393ms vboxdrv.service
       387ms kmod-static-nodes.service
       364ms irqbalance.service
       294ms udisks2.service
       293ms gpu-manager.service
       255ms console-setup.service
       243ms systemd-tmpfiles-setup.service
       230ms rsyslog.service
       196ms dev-mqueue.mount
       195ms dev-hugepages.mount
       187ms networking.service
       179ms systemd-rfkill.service
       158ms systemd-tmpfiles-clean.service
    lines 1-36

I dont know what to do next.Please help me!!!

Are you running Steam? Steam is notorious for slowing the shutdown process to a crawl on every distro I’ve ever used.

If you’re running Steam, close Steam before shutting down the PC and you’ll find shutdown times improve considerably.

My Ubuntu MATE rig boots faster than my Windows rig and shuts down faster than my Windows rig, both running SSD’s.

1 Like