☰

Systemd 停止用户管理器并终止所有用户进程

tag-icon • tag-icon systemd
Systemd 停止用户管理器并终止所有用户进程

我有许多 podman 容器在同一个用户下运行。其中运行的进程有时会占用大量资源（CPU 和内存）。

直到最近，我们都没有遇到任何问题。但在对容器内运行的程序之一进行不可避免的软件更新后，容器每天都会同时死机。我将可用 RAM 增加了一倍，这暂时有所帮助，但问题又回来了。

我在 中发现了以下几行/var/log/syslog，它们总是在关机之前出现：

Jul 24 17:01:26 xxx1 systemd[1]: session-5.scope: Deactivated successfully.
Jul 24 17:01:26 xxx1 systemd[1]: session-5.scope: Consumed 9.924s CPU time.
Jul 24 17:01:36 xxx1 systemd[1]: Stopping User Manager for UID 1000...

由于容器同时执行计划任务，因此在此之前不久 CPU 使用率出现峰值。

我没有更改原始版本（Ubuntu 22.04LTS）的任何 systemd 设置。并且将/etc/systemd/system.conf其DefaultCPUAccounting设置为否。

我怀疑可能存在一些其他限制导致关机（例如：任务数量），但我在日志中找不到有关导致用户管理器停止的原因的任何信息。

我怎样才能找到停止的原因？

答案1

从你的日志来看，我想说你把因果关系颠倒了：用户会议首先停止；然后，经过 10 秒的计时器后，systemd-logind 将用户管理器停止为“不需要”（这是标准行为，除非为该用户启用了“停留”模式）。

首先loginctl enable-linger <user>禁用用户服务管理器的自动 GC；你应该启用这个功能反正每当您想要拥有“永久”用户服务时。（如果您记得之前启用过它，我会首先查看 /var/lib/systemd/linger 以检查标志文件是否仍然存在 - 可能某些东西已经将其删除。）

如果这有帮助，请继续尝试找出用户会话停止的原因 - 这取决于之前是什么使它们保持打开状态（本地控制台登录？SSH 会话？）。

DefaultCPUAccounting与问题无关；基于 cgroup 的 CPU 核算可能只会限制进程，但（与 ulimit 不同）不会直接杀死它们。“消耗 xxx CPU 时间”消息仅供参考。

相关内容