10回のうち9回は、コンピューターのシャットダウンまたは再起動に約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
およびdebug.sh
#!/bin/sh
mount -o remount,rw /
dmesg > /shutdown-log.txt
mount -o remount,ro /
驚いたことに、これによりハングの数が大幅に減少しましたが、再起動時にshutdown-log.txtを埋めることができました: https:// Gist .github.com/MatTheCat/99498b006651110462f3488dcb454b4
再起動が正常な場合のshutdown-log.txtは次のとおりです: https://Gist.github.com/MatTheCat/77f168927008bb0b886bb944d19337f1
コンピュータは Dell XPS 13 938 です。
$ 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=5042 のため
[ 2144.333960] systemd-shutdown[1]: Sending SIGTERM to remaining
...
[ 2234.342297] systemd-shutdown[1]: Sending SIGKILL to PID 306 (lvmetad).
調査中。
設定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)
約10回再起動しても、問題は発生しません。指を交差させたままにします。
OpenSUSE Leap 15.1でも同様の問題が発生します。同じ手順を実行しましたが、シャットダウンログに何も表示されませんでした(*)。ただし、「ターゲットのシャットダウンに到達」の直前に、どのsystemdジョブがまだアクティブであるかを確認する別の方法を見つけました。 _systemctl enable debug-Shell.service
_を実行し、次の起動時にCtrl + Alt + F9を押してsystemdデバッグシェルに移動し、そこで_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