linux清理磁盘空间 - 日志 - journalctl

时间:2024-05-19 20:54:05

1.简单操作

坊间有一句谣言:Linux没有垃圾文件,只有Windows才有,说的好像外星人和外星人之间沟通不需要语言一样。

操作系统,顾名思义就是操作各种文件的系统。它不可能没有日志文件,因为记录操作历史日志,可以方便管理。它更不可能不产生临时文件,就像剪纸一样,临时产生一些废料是再自然不过的事情。

Linux到底有没有占用空间的垃圾文件,下图就可以说明。

linux清理磁盘空间 - 日志 - journalctl

未清理前发现硬盘根分区空间告急,用du -t 100M /varjournalctl --disk-usage命令一查,发现/var/log/journal日志文件占用了近3G空间,每个日志文件体积高达128M,这些日志文件记录了很长时间以来的systemd情况,毫无价值,用journalctl --vacuum-size=10M命令将其清理之后,腾出了2.7G的空间。用df命令一查,/根分区果然宽敞了很多。

接下来,我还要探索其他清理Linux垃圾的方法……

 

2.详情

CentOS系统中有两个日志服务,分别是传统的 rsyslog systemd-journal

systemd-journald是一个改进型日志管理服务,可以收集来自内核、系统早期启动阶段的日志、系统守护进程在启动和运行中的标准输出和错误信息,还有syslog的日志。

该日志服务仅仅把日志集中保存在单一结构的日志文件/run/log中,由于日志是经历过压缩和格式化的二进制数据,所以在查看和定位的时候很迅速。

本文转自米扑博客:Linux 系统 /var/log/journal/ 垃圾日志清理

默认情况下并不会持久化保存日志,只会保留一个月的日志。另外,一些rsyslog无法收集的日志也会被journal记录到。

rsyslog作为传统的系统日志服务,把所有收集到的日志都记录到/var/log/目录下的各个日志文件中。

常见的日志文件如下:

  /var/log/messages 绝大多数的系统日志都记录到该文件
  /var/log/secure 所有跟安全和认证授权等日志都会记录到此文件
  /var/log/maillog 邮件服务的日志
  /var/log/cron crond计划任务的日志
  /var/log/boot.log 系统启动的相关日志

 

曾经有人说:Linux没有垃圾文件,Windows才有垃圾文件,实际上不是这样的,两者都会有垃圾文件。

操作系统,就是操作各种文件的系统,它不可能没有日志文件,更不可能不产生临时文件,就像剪纸一样,临时产生一些废料是再自然不过的事情。

Linux到底有没有占用空间的垃圾文件,这个看如何判定了,例如好几年前、几个月前的日志文件、系统文件,基本没什么用处,算垃圾文件吗?

  ls -lhm --full-time /var/log/journal/f9d400c5e1e8c3a8209e990d887d4ac1_bk_20190122/ | sort -k6 | head -n30

  # ls -lhm --full-time /var/log/journal/f9d400c5e1e8c3a8209e990d887d4ac1_bk_20190122/ | sort -k6 | head -n30
total 3.5G
  -rw-r-x---+ 1 root systemd-journal 64M 2018-03-28 01:36:01.010275802 +0800 [email protected]28f35cca7.journal
  -rw-r-x---+ 1 root systemd-journal 8.0M 2018-03-28 01:36:01.100275802 +0800 [email protected]567f7fd08bd2f.journal
  -rw-r-x---+ 1 root systemd-journal 72M 2018-04-02 19:16:41.644934707 +0800 [email protected]852f561be.journal
  -rw-r-x---+ 1 root systemd-journal 8.0M 2018-04-02 19:16:41.714934707 +0800 [email protected]56872cab77761.journal
  -rw-r-x---+ 1 root systemd-journal 72M 2018-04-08 05:48:01.673026304 +0800 [email protected]bb97116ae.journal
  -rw-r-x---+ 1 root systemd-journal 72M 2018-04-13 18:25:01.967846109 +0800 [email protected]9207ae8a1.journal
  -rw-r-x---+ 1 root systemd-journal 72M 2018-04-18 04:12:35.385621922 +0800 [email protected]848f6f86c.journal
查看垃圾文件的方法

未清理前发现硬盘根分区空间告急,用 du -t 100M /var 或 journalctl --disk-usage 命令查看,发现/var/log/journal日志文件占用了近3G空间,每个日志文件体积高达8-128M,这些日志文件记录了很长时间以来的systemd情况,毫无价值,用journalctl --vacuum-size=10M命令将其清理之后,腾出了2.7G的空间。用df命令一查,/根分区果然宽敞了很多。

 

查看某个目录的文件大小并排序(单位为MB)

  du -hm --max-depth=1 /var/ | sort -n

  # du -hm --max-depth=1 /var/ | sort -n
  1 /var/adm
  1 /var/crash
  1 /var/db
  1 /var/empty
  1 /var/games
  1 /var/gopher
  1 /var/kerberos
  1 /var/local
  1 /var/nis
  1 /var/opt
  1 /var/preserve
  1 /var/spool
  1 /var/tmp
  1 /var/yp
  131 /var/www
  198 /var/lib
  486 /var/cache
  3695 /var/log
  8513 /var/
清空 /var/log/journal 文件的方法

1、用echo命令,将空字符串内容重定向到指定文件中

  echo "" > system.journal

  说明:此方法只会清空一次,一段时间后还要再次手动清空很麻烦,这里可以用以下命令让journalctl 自动维护空间

 

2、journalctl 命令自动维护文件大小

1)只保留近一周的日志

  journalctl --vacuum-time=1w

 

2)只保留500MB的日志

  journalctl --vacuum-size=500M

 

3)直接删除 /var/log/journal/ 目录下的日志文件

  rm -rf /var/log/journal/f9d400c5e1e8c3a8209e990d887d4ac1

 

问题与分析解决

执行 journalctl 命令时报错:Error was encountered while opening journal files: Input/output error

  # journalctl --vacuum-time=1w
  Error was encountered while opening journal files: Input/output error
问题分析:日志文件损坏

解决方法:删除之前的日志,并重启 journalctl 服务

  mv journal/f9d400c5e1e8c3a8209e990d887d4ac1 journal/f9d400c5e1e8c3a8209e990d887d4ac1_bk_20190122

  systemctl restart systemd-journald.service

查看 /var/log/journal/ 日志目录如下:

  # ll /var/log/journal/
  drwxr-sr-x 2 root systemd-journal 4096 Jan 22 11:26 f9d400c5e1e8c3a8209e990d887d4ac1
  drwxr-sr-x+ 2 root systemd-journal 12288 Jan 14 15:37 f9d400c5e1e8c3a8209e990d887d4ac1_bk_20190122
 

然后,再执行 journalctl 限制日志的命令:

  # journalctl --vacuum-time=1w
  Vacuuming done, freed 0B of archived journals on disk.
  # journalctl --vacuum-size=500M
  Vacuuming done, freed 0B of archived journals on disk.