# 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。这可能与关闭调试模式时获得的结果无关。
无论如何，到最后，这可能更像是一场软件设计争论，而不是其他任何事情。作为系统管理员，生产中配置文件的验证应该作为其自己的任务来完成。
将所有这些与在配置文件中放入无法解析的乱码进行比较，这肯定会在任何像样的软件中为您提供非零代码。