Well, I'm guessing that the designers of logcheck decided that this scenario is a configuration error worth complaining about, but it's not an operation error. In this scenario, logcheck is still able to run and still operates on /var/log/rsyncd.log. Ignoring a second configuration file doesn't prevent logcheck from continuing, so the status reported is 0.
Especially with server software, it is presumed that you checked your configuration files before deploying them. While the upside here would be a more obvious alerting to the issue, the downside would be concern for any tasks that depend on logcheck.
All that said, you can't rely on the state when passing -d
to be the same as in normal operation. Quoting man logcheck
: In debug mode, no changes will be made to the logs or to the logrotate state file.. Thus, the operation of reading things and verbosely reporting them has been successful and should return 0. That may not relate to what you get with debug mode off.
In any case, at the end of it this may be more of a software design debate than anything else. As a sysadmin, verification of configuration files in production should be done as its own task.
Compare all of this to putting unparsable gibberish in the configuration file which will certainly give you a non-zero code in any piece of decent software.
/etc/logrotate.conf
and/etc/logrotate.d/rsync*
if it exists