我遇到了以下问题。当我的日志被轮换时,会产生类似这样的问题
-rw-r--r-- 1 root 管理员 169K 9月 24 12:15 消息 -rw-r--r-- 1 root 管理员 0 9月24日 04:03 消息.1 -rw-r--r-- 1 root 管理员 0 9月 19 日 04:02 消息.11 -rw-r--r-- 1 root 管理员 20 八月 22 04:03 messages.1.gz -rw-r--r-- 1 root 管理员 0 9月23日 04:02 消息.3 -rw-r--r-- 1 root 管理员 20 八月 21 04:02 messages.3.gz -rw-r--r-- 1 root 管理员 0 9月22日 04:02 消息.5 -rw-r--r-- 1 root 管理员 20 年 8 月 20 日 04:02 消息.5.gz -rw-r--r-- 1 root 管理员 0 9月21日 04:02 消息.7 -rw-r--r-- 1 root 管理员 20 八月 19 04:03 messages.7.gz -rw-r--r-- 1 root 管理员 0 9月20日 04:02 消息.9 -rw-r--r-- 1 root 管理员 20 八月 18 18:02 messages.9.gz
如您所见,偶数没有压缩,但奇数压缩了。最重要的是没有保留日志!
我的 logrotate 如下......
啦啦啦 { 不压缩 共享脚本 旋转 12 每周 后旋转 /bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 2> /dev/null || true 结束语 }
什么地方出了问题?
答案1
问题终于解决了。问题是有些目录是其他目录的链接,因此它们被旋转了两次。!!!!!!! 结果导致生成的文件为空!
答案2
这看起来像是基于 redhat 的发行版。在这种情况下,您可能想检查该特定 pid 文件是否确实存在,以及哪个守护进程真正用于登录消息。
在 Fedora 上(作为示例),实际的 pid 文件是 /var/run/syslogd.pid。这因发行版(以及服务器的单独配置)而异。