标签： cron

使用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]