Systemd 变得无响应

Question

三周内，我的两台 Ubuntu 20.04LTS 服务器systemd突然变得无响应。症状：

• 所有systemctl用于控制服务或访问日志的命令都会失败并显示错误消息：

Failed to retrieve unit state: Connection timed out
Failed to get properties: Connection timed out

• systemd不理会logrotate重新打开日志的信号，继续写入重命名的日志文件/var/log/syslog.1，而新创建的日志文件/var/log/syslog仍为空。
• 许多僵尸进程从 cronjobs 和系统管理任务中积累，即。PID 1 systemd 忽略了其收集孤立进程的职责。
• 正在运行的服务继续正常运行，但不再可能启动或停止服务，因为即使旧脚本也重定向/etc/init.d到非功能性systemctl.
• Connection timed out除了尝试与 交互的消息之外，日志中没有任何异常systemd。

普遍提出的纠正措施：

• systemctl daemon-reexec
• kill -TERM 1
• 去除/run/systemd/system/session-*.scope.d

不要解决问题。唯一的补救措施是重新启动整个系统，这对于地球另一端的服务器来说当然既具有破坏性又存在问题。

在大约 100 台服务器中，Ubuntu 16.04LTS 大约每月都会出现一次同样的问题。自从升级到 20.04LTS 以来，这种情况已经少了很多，但并没有完全消失。在自 20.04LTS 以来受到攻击的两台服务器中，其中一台在运行 16.04LTS 时就已经受到攻击。

问题：

• 造成此类systemd故障的可能原因是什么？
• 我该如何进一步诊断？
• 有没有比systemd重新启动破坏性更小的方法来从无响应中恢复？

Answer 1

这是一个非常古老的问题，但我希望它可以节省其他人的时间。

我遇到了同样的问题，一些僵尸和 systemctl 响应任何超时请求。正如预期的那样，问题是删除守护进程。至少在我们的案例中，解决方案是：

telinit u
systemctl daemon-reexec
systemctl daemon-reload