![logrotate:如何检测故障](https://linux22.com/image/586160/logrotate%EF%BC%9A%E5%A6%82%E4%BD%95%E6%A3%80%E6%B5%8B%E6%95%85%E9%9A%9C.png)
# logrotate -d /etc/logrotate.conf
...
reading config info for /var/log/rsyncd.log
error: rsync:12 duplicate log entry for /var/log/rsyncd.log
error: found error in /var/log/rsyncd.log , skipping
removing last 1 log configs
...
# echo $?
0
由于 logrotate 通常使用 cron 运行,因此 cron 退出时显示 OK,因为 logrotate 退出时显示 OK。这应该以不同的方式执行吗?这是一个错误,还是出于某些我尚未理解的原因而故意为之?
更新:这个问题与错误来源无关。我故意在其中放置了一个错误,以说明返回代码始终为 0(=OK),我很想知道为什么会这样。
答案1
好吧,我猜 logcheck 的设计者认为这种情况是值得抱怨的配置错误,但不是操作错误。在这种情况下,logcheck 仍然能够运行,并且仍然在 /var/log/rsyncd.log 上操作。忽略第二个配置文件不会阻止 logcheck 继续运行,因此报告的状态为 0。
尤其是对于服务器软件,在部署配置文件之前,我们假定您已经检查过它们。这样做的好处是可以更明显地提醒您注意问题,而坏处则是担心任何依赖于 logcheck 的任务。
尽管如此,您不能指望传递时的状态-d
与正常运行时的状态相同。引用man logcheck
:在调试模式下,日志或 logrotate 状态文件不会发生任何更改。。因此,读取内容并详细报告的操作已成功并应返回 0。这可能与关闭调试模式时获得的结果无关。
无论如何,到最后,这可能更像是一场软件设计争论,而不是其他任何事情。作为系统管理员,生产中配置文件的验证应该作为其自己的任务来完成。
将所有这些与在配置文件中放入无法解析的乱码进行比较,这肯定会在任何像样的软件中为您提供非零代码。