刚开始远程工作,就接到短信告警,系统CPU占用过高,立即登录系统查看,登录的过程异常缓慢,不过总算登录了
ABRT报告发现了一个问题
ABRT是一个自动汇报错误的工具,主要是为用户提供简洁的,全面的错误信息
对于系统用户来说,它主要从系统日志中查询可以的字符串,比如oops、Machine-check、Xorg故障等,除了在系统日志中查询匹配外,它还检查kdump等记录故障的文件,从中提取系统错误信息,它提供了abrt-cli命令进行报告查看
通过提示命令查看
发现是systemd-logind的问题,结合top查看
systemd-logind占用CPU100%,导致系统负载飙升
systemd-logind是什么呢?
systemd-logind 是一个管理用户登录的系统服务。其职责如下:
那么为什么登录慢,登录后又提示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用户下的定时任务