我遇到了以下问题。当我的日志被轮换时，会产生类似这样的问题
-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。这因发行版（以及服务器的单独配置）而异。