shutdown failed to unmount /var

English Install/Boot/Login
#1

I just recently upgraded to 15.1 from 15 and have noticed shutting down seems to take about 1 minute, whereas it used to take about 15 seconds on 15.0. During the shutdown sequence I get a

Unmounting /var failed

error. Any ideas what would be causing this? I saw the other thread on shutdown/reboot delay of 90s, but I’m not sure if this is related.

Thanks.

#2

If you are using “btrfs”, with “/var” a subvolume, then this is a common message. I think everyone using “btrfs” is seeing that. And I seem to recall seeing a bug report.

I don’t think that’s causing a slow shutdown. I am seeing that message with Leap 15.2Alpha (using “btrfs”), but shutdown seems reasonably fast.

#3

https://github.com/systemd/systemd/issues/867#issuecomment-482043974

It’s probably not what is causing your delay. I get it and my system shuts down in a few seconds.

#4

https://bugzilla.suse.com/show_bug.cgi?id=1066021

#5

Thanks for the replies. I can’t find any other info int he logs that may indicate a problem.
Here is what I have after the reached target shutdown entry, which is the last one visible during the actual shutdown sequence:

Sep 03 21:48:38 precision systemd[1]: Reached target Shutdown.
Sep 03 21:48:38 precision systemd[1]: Reached target Final Step.
Sep 03 21:48:38 precision systemd[1]: Starting Power-Off...
Sep 03 21:48:38 precision systemd[1]: Shutting down.
Sep 03 21:48:38 precision systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Sep 03 21:48:38 precision haveged[452]: haveged: Stopping due to signal 15
Sep 03 21:48:38 precision haveged[452]: haveged starting up
Sep 03 21:48:38 precision systemd-journald[423]: Journal stopped

I don’t know that haveged is, or why it’s starting back up right after stopping, could that be an issue or is that normal? After the last journal entry it just sits there for almost a minute before powering off.

I saw another post where someone said the lvm2 package was causing their system to be slow to shutdown. I thought about removing it, but zypper also wants to remove a bunch of libvirtd packages, which probably isn’t going to work for me. I’ll deal with it if I have to, it’s just a minor annoyance.

#6

I doubt that “haveged” is a problem here.

It’s purpose is to gather data about random events or random timings, to use in “/dev/random”.

#7

https://freedesktop.org/wiki/Software/systemd/Debugging/

#8

I posted thinking I found the problem, which appeared to be related to an fstab entry. But, upon further testing it appears to be more random, so disregard.

#9

After a bit of troubleshooting and reading other posts, I’ve discovered that the lvm2-lvmetad service is what is causing the problem. Uninstalling lvm2 is not an option because it’s a dependency of libvirtd, which I use. Disabling lvm2-lvmetad is evidently not possible because it restarts on every boot regardless of whether or not it’s disabled. Any suggestions on how I can disable this service without uninstalling lvm2?

Thanks.

#10

I doubt your claims. What is your output of:

erlangen:~ # systemctl list-unit-files lvm*
UNIT FILE             STATE   
lvm2-lvmetad.service  static  
lvm2-lvmpolld.service static  
lvm2-monitor.service  disabled
lvm2-pvscan@.service  static  
lvm2-lvmetad.socket   disabled
lvm2-lvmpolld.socket  disabled

6 unit files listed.
erlangen:~ #
#11

Ah, what you should have said is something along the lines of “there are other lvm2 services/sockets that need to be disabled as well.” Disabling the monitoring service was sufficient to stop it from re-activating on every boot.