Tumbleweed Long Shutdown Time

English Install/Boot/Login
#1

After the last update Tumbleweed now takes a long time to shutdown or reboot.

Here is the output of systemd-analyze blame:

# systemd-analyze blame
1.419s btrfsmaintenance-refresh.service
1.148s postfix.service
932ms apparmor.service
858ms SuSEfirewall2_init.service
718ms display-manager.service
616ms SuSEfirewall2.service
441ms lvm2-monitor.service
436ms var-spool.mount
415ms var-lib-mailman.mount
388ms var-lib-machines.mount
378ms opt.mount
373ms srv.mount
361ms var-lib-pgsql.mount
337ms usr-local.mount
326ms var-opt.mount
321ms plymouth-quit-wait.service
313ms dev-sdb3.device
311ms var-crash.mount
304ms var-lib-named.mount
258ms home-dave-NASMusic.mount
257ms var-tmp.mount
237ms initrd-switch-root.service

What would cause btrfsmaintenance-refresh.service and postfix.service to take so long? What should I be looking for?

Thanks!

#2

If it’s shutdown where the delay is then “systemd-analyze blame” is not going to tell you a great deal…

Take a look here: https://freedesktop.org/wiki/Software/systemd/Debugging/

Specifically the “Diagnosing Shutdown Problems” section.

#3

1.419s btrfsmaintenance-refresh.service
1.148s postfix.service

That is one (and a half) Second…

#4

Not even …

#5

Startup finished in 1.740s (kernel) + 757ms (initrd) + 1.835s (userspace) = 4.333s on my Intel i3-4130.

Look here: http://mistelberger.net/plot.svg postfix.service takes 728ms from 1,835ms user space. However it is not in the critical chain. So it does not matter. btrfsmaintenance-refresh.service was enabled on my machine. However there was no such partition. Thus I disabled the service.

#6

Yes… but… the OP stated the problem is with shutdown/reboot, not startup, which as can be seen from the “systemd-analyze blame” posted, is quite respectable. Looking at startup times with “systemd-analyze *” is all rather moot.

#7

Depending what services or programs that are running shut down can be fast or slow. The OS must wait until all critical operations for all services and programs are complete

#8

Have you added any new devices?
Have you tried the previous Kernel?
Try also to change loginmanager

#9

Shut down is lengthy:

hofkirchen:~ # journalctl -b -1 |grep -i slice|grep 13:49
Jan 02 13:49:08 hofkirchen systemd[1]: Removed slice system-systemd\x2dcoredump.slice.
Jan 02 13:49:08 hofkirchen systemd[1]: Removed slice system-systemd\x2dhibernate\x2dresume.slice.
Jan 02 13:49:09 hofkirchen systemd[1]: Removed slice system-getty.slice.
Jan 02 13:49:09 hofkirchen systemd[1]: Removed slice User Slice of charlemagne.
Jan 02 13:49:10 hofkirchen systemd[1]: Removed slice User Slice of erika.
Jan 02 13:49:11 hofkirchen systemd[1]: Removed slice User Slice of karl.
Jan 02 13:49:16 hofkirchen systemd[1]: Stopped target Slices.
Jan 02 13:49:16 hofkirchen systemd[1]: Removed slice User and Session Slice.
Jan 02 13:49:16 hofkirchen systemd[1]: Removed slice system-systemd\x2dbacklight.slice.
Jan 02 13:49:17 hofkirchen systemd[1]: Removed slice system-systemd\x2dfsck.slice.
hofkirchen:~ #

Removing a graphical login takes a second each.

hofkirchen:~ # journalctl -b -1 -u wicked
-- Logs begin at Tue 2016-10-25 15:09:12 CEST, end at Wed 2018-01-03 06:08:03 CET. --
Dec 31 15:38:47 hofkirchen systemd[1]: Starting wicked managed network interfaces...
Dec 31 15:39:02 hofkirchen wicked[855]: lo              up
Dec 31 15:39:02 hofkirchen wicked[855]: enp0s25         enslaved
Dec 31 15:39:02 hofkirchen wicked[855]: br0             up
Dec 31 15:39:02 hofkirchen systemd[1]: Started wicked managed network interfaces.
Jan 02 13:49:11 hofkirchen systemd[1]: Stopping wicked managed network interfaces...
Jan 02 13:49:16 hofkirchen wicked[23090]: enp0s25         device-ready
Jan 02 13:49:16 hofkirchen systemd[1]: Stopped wicked managed network interfaces.
hofkirchen:~ #

Starting wicked takes 15 seconds, stopping another 5 seconds.

#10

I have the opposite problem. I looked at systemd analyze and found it was just over 3 minutes in userspace. I just upgraded from LEAP 42.2. I have a dual boot and run LEAP 42.3 on another disk. That loads up extremely fast. What could be slowing this upgrade down?

#11

What does systemd-analyze blame tell you. That should tell you what is slow

#12

I had the same problem
For the causes I suspected:

  • NetworkManager waitonline service
  • sp5100-tco stuff (For Ryzen 7 + ASUS ROG CH6 systems)
  • Nvidia driver stuff
  • systemd related

I tried to disable NetworkManager waitonline service. Did not solve the problem
At the end I figured out that it was Plymouth+nvidia driver problem
I removed Plymouth and viola it worked!
If you have nvme ssd you really do not need splash animation
Boot takes just a few seconds!!!

You may think about that.