Real天下
科技 2022-07-21 ChenReal

Debian/Ubuntu系统Systemd-Logind CPU占用率飙升100%

今天，我的Debian服务器上的postgresql服务当机多次，最后竟然无法启动！究其原因，竟然是……

Debian系统真不错！

最近，喜欢上了Debian。与我用了十多年的Ubuntu同宗同源，几乎没有什么学习成本。 喜欢它组要有两点：

  1. 非常非常的精简，连sudo 和 vim都要自己动手安装才能用上，因此让人感觉到这个系统很干净很纯粹，不会有多余没用的东西在里面。所以也特别对我这种有洁癖之人的胃口。
  2. APT安装的软件应用版本比较新，反观Ubuntu则显得过于保守。譬如：安装PostgreSql，Debian11下安装的是v13，而Ubuntu22.04却给的是v11，整整差了两个大版本！（最新的PostgreSql是v14）因此，想软件应用能够与时代接轨，还是选择Debian吧。

问题来了。

好了，上面说了那么多Debian的好话，不得不说一下今天所遇到的一个糟心的问题。当然，最终结论，这并不完全是Debian的锅，Ubuntu安装在笔记本电脑上可能也会有类似的问题。 事情要先从今天下午postgresql服务down机开始，对号称稳定压倒一切的Debian系统，我的PostgreSql居然挂了！上去重启居然启动不了？！还留下几几行日志：

2022-07-21 00:38:55.230 PDT [2280864] FATAL:  could not write lock file \"postmaster.pid\": No space left on device
pg_ctl: could not start server

线索立马找出来了，居然磁盘空间不足。开始还不太愿意相信，因为这重装Debian系统才堪堪半个月上面跑的应用和数据也没多少。好吧，看看磁盘使用情况

df -h

一看吓一跳，居然128G硬盘，被用得一点空间都不剩了！

db1.png

是谁，，，占用我的盘？！为了把TA给揪出来，我使用“夹逼法”，从顶层目录开始排查，看每个目录占用多少存储空间： du -lh --max-depth=1。最终，找到两个50G的 /var/log/auth.log文件！

db2.png

第一次见到竟然有如此之“厚颜”的log文件！直接rm掉它们～可是，这样治标不治本必须找到它们的来源。查看一下系统应用进程，看看是否有异常。果然……

db3.png

有个名叫systemd-logind的服务，进程将CPU几乎飙到了100%。

systemd-logind是什么呢？

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

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

寻找解决方法

众里寻她千百度。。。度娘竟然告诉我直接kill掉进程就完事了？想想也知道，实际并没有那么简单。但是暂时没有更好的办法先曲线救国吧。

systemctl stop systemd-logind

好像，暂时解决了。进程杀掉了，CPU也回归正常。可是，过了半个小时在看服务器的状况，systemd-logind又死灰复燃，CPU持续飙高，瞬间回到解放前。 没辙了，还是查看一下日志找找其他线索吧。度娘不靠谱，接下来还要换个其他娘来用～

systemctl status systemd-logind

看到了systemd-logind服务在疯狂输出报错信息：

 systemd-logind[23724]: Suspending...
 systemd-logind[23724]: Unit suspend.target is masked, refusing operation.
 systemd-logind[23724]: Failed to execute suspend operation: Permission denied

这下，果然又有了新的线索。打开bing.com，查询一下。找到了英文站页面。赫然看到，人家所描述的症状跟我的一模一样！ 解决方法也很简单：

  • 打开编辑 /etc/systemd/logind.conf
  • 设置 HandleLidSwitch=ignore
  • 重启systemd-logind服务 systemctl restart systemd-logind
  • 重新查看服务日志 systemctl status systemd-logind 没有再出现上述的爆错信息了！

大功告成问题解决！

总结

  • 玩系统，特别是Linux系统，懂得读日志很重要！往往很多关键的线索都写在日志里。
  • 百度虽然方便，但是多数疑难杂症一都能够难倒它，所以需要准备一个backup搜索引擎，E文的。（其它非中文的也可以试试，反正俺不懂！）
  • 物理机安装Linux特别是笔记本电脑，还是有不少出人意料的坑。因为笔记本电脑有些特殊设定，例如休眠、切换电池&店员适配器、有线&无线网卡切换等等，都会对一些后台服务有所扰动，从而产生一些软件应用的故障。正所谓：“路漫漫其修远兮，吾将上下而踩坑”
返回