☰

Systemd 无响应

tag-icon • tag-icon systemd
Systemd 无响应

三周内，我的两台 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

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

同样的问题在 Ubuntu 16.04LTS 上每月发生一次，大约有 100 台服务器。升级到 20.04LTS 后，发生频率大大降低，但并未完全消失。在 20.04LTS 之后受到影响的两台服务器中，有一台在运行 16.04LTS 时就已经受到影响。

问题：

  • 造成此类systemd故障的可能原因有哪些？
  • 我该如何进一步诊断这个问题？
  • systemd除了重新启动之外，有没有一种破坏性更小的方法来从无响应中恢复？

答案1

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

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

telinit u
systemctl daemon-reexec
systemctl daemon-reload

相关内容