linux systemd-logind 进程cpu占用100% 解决方法

刚开始远程工作，就接到短信告警，系统CPU占用过高，立即登录系统查看，登录的过程异常缓慢，不过总算登录了

ABRT报告发现了一个问题

ABRT是一个自动汇报错误的工具，主要是为用户提供简洁的，全面的错误信息

对于系统用户来说，它主要从系统日志中查询可以的字符串，比如oops、Machine-check、Xorg故障等，除了在系统日志中查询匹配外，它还检查kdump等记录故障的文件，从中提取系统错误信息，它提供了abrt-cli命令进行报告查看

通过提示命令查看

发现是systemd-logind的问题，结合top查看

systemd-logind占用CPU100%，导致系统负载飙升

systemd-logind是什么呢？

systemd-logind 是一个管理用户登录的系统服务。其职责如下：

• 持续跟踪用户的会话、进程、空闲状态。这将在 user.slice 之下，为每个用户分配一个 slice 单元、为每个用户的当前会话分配一个 scope 单元。同时，针对每个已登录的用户，将会启动一个专属的服务管理器(作为 user@.service 模版的一个实例)。
• 生成并管理"session ID"。如果启用了审计并且已经为一个会话设置了审计"session ID"， 那么该ID也将同时被用作"session ID"， 否则将会使用一个独立的会话计数器(也就是独立生成一个"session ID")。
• 为用户的特权操作(例如关闭或休眠系统) 提供基于 polkit 的认证与授权
• 为应用程序实现 阻止关闭/休眠系统的逻辑
• 处理 硬件关机/休眠按钮的动作
• 多席位(Multi-Seat)管理
• 会话切换管理
• 管理 用户对设备的访问
• 在启动虚拟终端时 自动启动文本登录程序(agetty)， 并管理用户的运行时目录

那么为什么登录慢，登录后又提示systemd-logind被killd，通过查找message看到如下

很明显是系统的buffer不够，在读取/run/systemd/users/0时无法读取，无法为登录用户创建session，然后3分钟无响应被wachdog检测到kill掉，重新启动重新尝试

可以在图中看到，仍然有root用户分配了session，我想这是因为这个时候正好资源有释放，刚好可以申请到资源创建session

为了解决疑惑，通过strace看一下systemd-logind在用户登录时的调用

首先查看下systemd-logind的pid

接着通过strace -p进行跟踪调用

发现登录过程中，就是调用/run/systemd/users下面的文件

我们看下/run/systemd/users/0文件中存储的内容

记录了用户id为0也就是root用户的session信息，这里发现活动的session很多，但是我登录用户只登录了一个会话

因为每一个session都会创建一个slice，通过slice查看，先查看系统slice

然后查看user.0.silce

发现除了用户登录，还有大量的crond定时任务的session，可以看到每个session下面的详细命令或脚本

systemd-logind有个bug，就是当有crond时，往往session回收不及时，这也是资源占用导致无法新开session的原因

从上的图中可以看到user.0.slice中是通过cgroup来进行管理的，用户的进程的资源管理可以在/run/systemd/system/目录下，根据用户的slice或者是session去进行配置

比如user.0.slice.d下面的配置

至此问题大致了解，systemd-logind在用户登录时申请资源，由于系统资源不够，导致无法创建session，无法登录。

网上有建议让关掉systemd-logind，我个人建议不关掉，因为它有一个比较重要的功能就是更方便系统通过cgroup来管理用户资源

更好的做法是，定时释放资源，将定时任务尽量写到不同的用户中，而不是都写入到root用户下

通常管理员都是将定时任务写入到root下，这种方式不管是执行产生的临时文件还是日志文件，都是root权限的，比如执行web的命令生产root权限的文件，会导致原本的web用户无法调用而报错，所以尽量通过crontab -e -u web用户的方式，减少root用户下的定时任务