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 
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 
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
First you may want to start with this command in a terminal systemd-analyze blame It will give you a list of what is taking the longest to boot, we can go from there.
1 Like
Hello
Please visit System>Administration>Startup applications and select the items only u need for startup
You can also check demsg logs
Regards,
Christian
1 Like
Hello, reading in a rush your first posts i tried the pluma /etc/systemd/system.conf and putted the default vaules at 15s this is good to shut down to me, very fast now, i still have a Very Slow boot up! From the Boot tone to the passw splash 1min 42 seconds!
I’m running a MacPro 1,1 dual2 (quad) 2.66 original 8gbram
here what comes out from my systemd-analyze blame
21.937s udev-configure-printer@-devices-pci0000:00-0000:00:1d.7-usb1-1\x2d3.service
14.447s dev-mapper-ubuntu\x2d\x2dmate\x2d\x2dvg\x2droot.device
12.081s lvm2-monitor.service
9.661s systemd-sysctl.service
9.505s NetworkManager-wait-online.service
9.022s networking.service
8.972s systemd-udevd.service
8.917s accounts-daemon.service
8.362s speech-dispatcher.service
8.362s irqbalance.service
8.361s apport.service
8.361s ondemand.service
8.361s grub-common.service
6.460s NetworkManager.service
6.037s lightdm.service
5.080s ModemManager.service
2.919s gpu-manager.service
2.906s polkitd.service
2.805s rsyslog.service
2.370s keyboard-setup.service
2.224s systemd-tmpfiles-setup-dev.service
2.030s thermald.service
Can someone suggest me something good to do to fix up?