☰

从不间断状态恢复 systemd

tag-icon • tag-icon centos systemd
从不间断状态恢复 systemd

最近，通过 ssh 连接 CentOs8 虚拟机变得极其缓慢。我检查了 top 命令，其中显示了以下内容：

    load average: 30.09, 30.13, 30.09
    Tasks: 403 total,   1 running, 364 sleeping,   0 stopped,  38 zombie
    %Cpu(s):  2.4 us,  1.1 sy,  0.0 ni, 94.9 id,  0.0 wa,  1.4 hi,  0.2 si,  0.0 st
    MiB Mem :  15853.6 total,   5322.0 free,   8791.9 used,   1739.7 buff/cache
    MiB Swap:      0.0 total,      0.0 free,      0.0 used.   6052.8 avail Mem

     PID  USER     PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
       1 root      20   0  245460   8192   4132 D   0.0   0.1 662:05.04 systemd
      43 root      39  19       0      0      0 D   0.0   0.0  15:06.70 khugepaged
      56 root      20   0       0      0      0 D   0.0   0.0  68:38.87 kswapd0
   34809 root      20   0       0      0      0 D   0.0   0.0   0:00.09 sh
   41031 101       20   0   34248  25884      4 D   0.0   0.2   0:00.62 nginx
   41309 root      20   0   93260   6740   5904 D   0.0   0.0   0:00.03 systemd-user-ru
   44308 root      20   0   57184   3760   3340 D   0.0   0.0   0:00.01 ps    
    ...etc

其他一些命令一旦我使用它就会立即进入“D”状态，例如 ps、pgrep。因此，如果我输入“ps aux”，终端将变得无响应，然后从其他终端重新登录，我可以看到新的“ps”命令已添加到“D”进程中。

All of the ps,grep D state process's and  and systemd's stack trace:    
[<0>] __access_remote_vm+0x5a/0x2d0
[<0>] proc_pid_cmdline_read+0x1a6/0x350
[<0>] vfs_read+0x91/0x140
[<0>] ksys_read+0x4f/0xb0
[<0>] do_syscall_64+0x5b/0x1b0
[<0>] entry_SYSCALL_64_after_hwframe+0x65/0xca
[<0>] 0xffffffffffffffff

khugepaged:
[<0>] collapse_huge_page+0x11f/0xdf0
[<0>] khugepaged+0xb4f/0x1140
[<0>] kthread+0x112/0x130
[<0>] ret_from_fork+0x35/0x40
[<0>] 0xffffffffffffffff

kswapd0:
[<0>] rpc_wait_bit_killable+0x1e/0x90 [sunrpc]
[<0>] _nfs4_proc_delegreturn+0x22e/0x330 [nfsv4]
[<0>] nfs4_proc_delegreturn+0x7c/0x130 [nfsv4]
[<0>] nfs_do_return_delegation+0x33/0x50 [nfsv4]
[<0>] nfs4_evict_inode+0x25/0x70 [nfsv4]
[<0>] evict+0xd2/0x1a0
[<0>] dispose_list+0x48/0x60
[<0>] prune_icache_sb+0x52/0x70
[<0>] super_cache_scan+0x123/0x1a0
[<0>] do_shrink_slab+0x118/0x270
[<0>] shrink_slab+0x187/0x2e0
[<0>] shrink_node+0xe4/0x440
[<0>] balance_pgdat+0x1e2/0x340
[<0>] kswapd+0x21a/0x400
[<0>] kthread+0x112/0x130
[<0>] ret_from_fork+0x35/0x40
[<0>] 0xffffffffffffffff
[<0>] prealloc_shrinker+0x6d/0x110

systemd-user-ru:
[<0>] sget_userns+0x2c0/0x4b0
[<0>] mount_nodev+0x2a/0xa0
[<0>] mount_fs+0x3b/0x167
[<0>] vfs_kern_mount.part.35+0x54/0x120
[<0>] do_mount+0x1fc/0xc80
[<0>] ksys_mount+0xb6/0xd0
[<0>] __x64_sys_mount+0x21/0x30
[<0>] do_syscall_64+0x5b/0x1b0
[<0>] entry_SYSCALL_64_after_hwframe+0x65/0xca
[<0>] 0xffffffffffffffff

我还应该寻找什么？他们是从这里恢复过来的一种方法吗？

答案1

一般来说，唯一可能的恢复是重新启动 - 最好通过 SysRq，这样您就有机会刷新文件系统并卸载那些未卡住的文件系统。做不是 sudo reboot，因为当系统等待最后一个进程完成时它可能会挂起（它永远不会这样做）。

但有时还是可以逐渐退出这种状态的。就你而言，我将从 systemd 本身开始。如果无法恢复，重新启动是唯一的选择。所以尝试：

$ sudo systemctl daemon-reexec

这将分叉一个新的 systemd 副本，将当前状态交给它，并终止当前的 systemd 副本——希望能够解决它的所有问题。此命令可能会失败，要么像ps以前那样变得不可中断，要么只是无法连接到现有的 systemd 实例。

如果你恢复了 systemd，你可以在其他守护进程上尝试类似的技巧：尝试重新启动它们。一些即使在“不间断”状态下也可能被杀死， 尝试kill -9。

堆栈跟踪特别提到了文件系统和 NFS。 NFS 因此类问题而臭名昭著，因此请考虑不要将其用于根分区等重要事务。

相关内容