使用service –status-all 或 systemctl status 查询服务状态时卡顿

问题:

在一个运行多年的 debian 系统中,使用 service --status-all 检查服务列表
输出到项目 "[ + ]  cron" 时,会卡顿很久,才继续显示其他服务名。

起初不知道为什么卡顿,今天看到一文,他在 systemctl status 某服务名 时卡顿很久,后来发现这个问题和systemd-journald有关。我感觉这个问题也有可能一样,老系统运行多年,记录的服务信息过多。决定也尝试清理一下journald。

单独查看service --status-all 中卡顿的 cron

systemctl status cron

果真,翻页几千行,才发现看了不到一个月的记录,太多了

cron 是定时执行任务的服务。各种计划任务的执行都会产生大量的服务启动日志。

可以看出 systemctl 输出服务启动时的相关信息。都是从systemd-journald中读取的。

进入文件夹 /var/log/journal,里面有一个长文件名的文件夹:f25c9fe2e9554b54950734c0b92298e0,里面是用户的 system.journal 文件,还有user-1000.journal。

ls -lhm --full-time /var/log/journal/f25c9fe2e9554b54950734c0b92298e0/

查看这个文件夹下文件大小,21,001,486,336 bytes 有19.5 GiB。

下面清理 journal 文件

先停止 systemd-journald 服务

systemctl stop systemd-journald

Warning: Stopping systemd-journald.service, but it can still be activated by:
  systemd-journald-dev-log.socket
  systemd-journald.socket
  systemd-journald-audit.socket

提示警告,为了保险,把这几个都停止掉:
systemctl stop systemd-journald-dev-log.socket
systemctl stop systemd-journald.socket
systemctl stop systemd-journald-audit.socket

然后可以删除 journal 文件(我直接全部删除了,重要的生产服务器不建议这样)
 

最后是要限制systemd-journald日志的大小,避免以后出现这个问题。

编辑文件: /etc/systemd/journald.conf

修改以下两个配置参数:

SystemMaxUse=100M
RuntimeMaxUse=100M

限制全部日志文件加在一起最多可以占用多少空间,相对的问题是,以后的日志记录总量也变少了。

最后重启 systemd-journald

systemctl restart systemd-journald

再次使用 service –status-all 或 systemctl status 查询服务状态时,就不再出现卡顿了。

systemctl daemon-reload #重新加载服务配置文件

[end]