![关机并重新启动挂起](https://linux22.com/image/149492/%E5%85%B3%E6%9C%BA%E5%B9%B6%E9%87%8D%E6%96%B0%E5%90%AF%E5%8A%A8%E6%8C%82%E8%B5%B7.png)
我的计算机十分之九需要 ≅ 2 分钟才能关闭或重新启动。我尝试了很多事情,例如添加systemd
和/或shutdown
initcpio 挂钩,但没有运气。
reboot -f
永远不会挂起,所以我跟着这些步骤进行调试。添加选项后/proc/cmdline变成
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
和调试.sh
#!/bin/sh
mount -o remount,rw /
dmesg > /shutdown-log.txt
mount -o remount,ro /
令我惊讶的是,这大大减少了挂起的次数,但我设法填补了关机日志.txt重新启动时:https://gist.github.com/MatTheCat/99498b006651110462f3488dcb454b40
这是关机日志.txt当重新启动就可以了:https://gist.github.com/MatTheCat/77f168927008bb0b886bb944d19337f1
计算机是一个戴尔 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
看起来很匹配https://bugs.archlinux.org/index.php?do=details&task_id=50420因为
[ 2144.333960] systemd-shutdown[1]: Sending SIGTERM to remaining
...
[ 2234.342297] systemd-shutdown[1]: Sending SIGKILL to PID 306 (lvmetad).
正在调查。
答案1
设置use_lvmetad
为0
而不是1
in/etc/lvm/lvm.conf解决这个问题。我不知道发生了什么,所以我只是希望这不会造成任何问题,因为我没有使用 LVM。
我仍然愿意接受任何解释。
自从我写这篇文章以来已经有一段时间了,所以我尝试重置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)
大约重新启动十次后看不到任何问题。保持我的手指交叉。
答案2
我在 OpenSUSE Leap 15.1 上看到类似的问题,我遵循了相同的说明,但关闭日志从未有任何有趣的内容 (*)。然而,我找到了另一种方法来查看哪些 systemd 作业在“达到目标关闭”之前仍然处于活动状态。我这样做了systemctl enable debug-shell.service
,在下次启动时,我按 Ctrl+Alt+F9 进入 systemd 调试 shell,并在那里输入,
while true; do systemctl list-jobs | cat ; done
以便它连续列出 systemd 作业(并且没有寻呼机)。然后在下一次重新启动/关闭时挂起一段时间,我再次切换到 VT9,在那里我可以看到
lvm2-monitor.service
lvm2-lvmetad.socket
lvm2-lvmetad.service
systemd-reboot.service
reboot.target
显然,这意味着 lvmetad 也是我的问题所在。我现在将尝试您的解决方案来禁用它,谢谢。我只是想提一下这种调试技术,以防其他人遇到这个问题,因为当 systemd 不继续运行时,我们都想知道“它仍在执行哪些作业?”
(*) 既然你提到了,日志确实有Sending SIGKILL to PID 502 (lvmetad).
不幸的是,我没有解释为什么 lvmetad 会出现这种行为。这台计算机有一个加密分区,并且根本不使用 LVM。
版本:lvm2-2.02.180-lp151.3.2.x86_64、systemd-234-lp151.25.7.x86_64
答案3
自从我安装了 openSuse Leap 15.1 以来,我的笔记本电脑上也遇到了同样的问题。以下是我如何让它关机:
Ctrl+ Alt+F1
Alt+ PrtSc+O