2

9 times out of 10 my computer would take ≅ 2 minutes to shutdown or reboot. I tried many things like adding systemd and/or shutdown to initcpio hooks, but no luck.

reboot -f never hangs so I followed these steps to debug. After adding the options /proc/cmdline becomes

initrd=\intel-ucode.img initrd=\initramfs-linux.img root=PARTUUID=d596f77d-aafa-479f-ad3c-df9e7c91fc7b rw quiet systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on enforcing=0

and debug.sh

#!/bin/sh
mount -o remount,rw /
dmesg > /shutdown-log.txt
mount -o remount,ro /

To my surprise this greatly reduced the number of hangs but I managed to fill shutdown-log.txt on reboot: https://gist.github.com/MatTheCat/99498b006651110462f3488dcb454b40

Here is shutdown-log.txt when reboot is fine: https://gist.github.com/MatTheCat/77f168927008bb0b886bb944d19337f1

Computer is a Dell XPS 13 9380.

$ lspci
00:00.0 Host bridge: Intel Corporation Device 3e34 (rev 0b)
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (Whiskey Lake)
00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 0b)
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model
00:12.0 Signal processing controller: Intel Corporation Cannon Point-LP Thermal Controller (rev 30)
00:14.0 USB controller: Intel Corporation Cannon Point-LP USB 3.1 xHCI Controller (rev 30)
00:14.2 RAM memory: Intel Corporation Cannon Point-LP Shared SRAM (rev 30)
00:15.0 Serial bus controller [0c80]: Intel Corporation Device 9de8 (rev 30)
00:15.1 Serial bus controller [0c80]: Intel Corporation Device 9de9 (rev 30)
00:16.0 Communication controller: Intel Corporation Cannon Point-LP MEI Controller (rev 30)
00:1c.0 PCI bridge: Intel Corporation Device 9dbe (rev f0)
00:1d.0 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port (rev f0)
00:1d.4 PCI bridge: Intel Corporation Device 9db4 (rev f0)
00:1f.0 ISA bridge: Intel Corporation Cannon Point-LP LPC Controller (rev 30)
00:1f.3 Audio device: Intel Corporation Cannon Point-LP High Definition Audio Controller (rev 30)
00:1f.4 SMBus: Intel Corporation Cannon Point-LP SMBus Controller (rev 30)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP SPI Controller (rev 30)
01:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
02:00.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
03:00.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
03:01.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
03:02.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
03:04.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
04:00.0 System peripheral: Intel Corporation JHL6540 Thunderbolt 3 NHI (C step) [Alpine Ridge 4C 2016] (rev 02)
38:00.0 USB controller: Intel Corporation JHL6540 Thunderbolt 3 USB Controller (C step) [Alpine Ridge 4C 2016] (rev 02)
6d:00.0 Non-Volatile memory controller: SK hynix Device 1527

$ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 0489:e0a2 Foxconn / Hon Hai 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Seems to match https://bugs.archlinux.org/index.php?do=details&task_id=50420 because of

[ 2144.333960] systemd-shutdown[1]: Sending SIGTERM to remaining
...
[ 2234.342297] systemd-shutdown[1]: Sending SIGKILL to PID 306 (lvmetad).

Investigating.

5
  • Please add to the question the out of cat /proc/cmdline Mar 7, 2019 at 8:47
  • @RuiFRibeiro done
    – MatTheCat
    Mar 7, 2019 at 8:52
  • Nothing out of ordinary there. lspci and lsusb might be useful. Also model and brand of notebook Mar 7, 2019 at 8:54
  • @RuiFRibeiro added
    – MatTheCat
    Mar 7, 2019 at 9:01
  • I reproduced the hang; seems to be random. I edited my question accordingly.
    – MatTheCat
    Mar 7, 2019 at 9:12

3 Answers 3

2

Setting use_lvmetad to 0 instead of 1 in /etc/lvm/lvm.conf works around the issue. I have no idea what's going on so I just hope this won't cause any issue since I'm not using LVM.

I'm still open to any explanation.


It's been some time since I wrote this so I tried to reset use_lvmetad.

$ lvm version
  LVM version:     2.02.185(2) (2019-05-13)
  Library version: 1.02.158 (2019-05-13)
  Driver version:  4.40.0

$ systemctl --version
systemd 242 (242.84-1-arch)

Can't see any issue after about ten reboots. Keeping my fingers crossed.

0

I'm seeing similar trouble on OpenSUSE Leap 15.1, and I followed the same instructions but the shutdown log never had anything interesting (*). I however found another way to see which systemd jobs are still active just before "Reached target shutdown". I did systemctl enable debug-shell.service and on the next boot I pressed Ctrl+Alt+F9 to go to the systemd debugging shell and there I typed while true; do systemctl list-jobs | cat ; done so that it lists systemd jobs continuously (and without a pager). Then on the next reboot/shutdown that hangs for a while, I switched to VT9 again and there I could see

lvm2-monitor.service
lvm2-lvmetad.socket
lvm2-lvmetad.service
systemd-reboot.service
reboot.target

Clearly this means lvmetad is the problem in my case as well. I will now try your solution for disabling it, thanks for that. I just wanted to mention this debugging technique in case others hit this problem, because the one thing we're all wondering when systemd doesn't move on, is "which jobs is it still executing?"

(*) now that you mention it, the log does have Sending SIGKILL to PID 502 (lvmetad).

Unfortunately I don't have an explanation on why lvmetad is misbehaving this way. This computer has a single encrypted partition and doesn't use LVM at all.

Versions: lvm2-2.02.180-lp151.3.2.x86_64, systemd-234-lp151.25.7.x86_64

-1

I'm having the same problem on my laptop since I installed openSuse Leap 15.1. Here's how I get it to power off:

Ctrl + Alt + F1

Alt + PrtSc + O

1
  • 1
    This doesn't really solve the issue, it's only a workaround that may not even work for the user with the question. Could you, for example, say something about why this would be the correct solution for this particular user?
    – Kusalananda
    Oct 25, 2019 at 5:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.