Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
# 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 $?

Since logrotate is usually run using cron, cron exits with OK because logrotate exits with OK. Should this be done differently? Is this a bug or is it by design for some reason I haven't comprehended yet?

UPDATE: This question is not about the source of the error. I put an error in there intentionally in order to illustrate that the return code is always 0 (=OK) and I'm interested in why that's the case.

share|improve this question
please post your /etc/logrotate.conf and /etc/logrotate.d/rsync* if it exists – krissi Jun 4 '12 at 12:04
I put an error in the config intentionally to show that the return code is always 0. The question is if it is normal that it is always 0 (=OK) – Marki Jun 4 '12 at 12:05
ah, sorry. Misunderstanding ;) – krissi Jun 4 '12 at 13:31

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.

share|improve this answer
Well logrotate 3.7.3 still produced error code 1. logrotate 3.7.7 no longer does... I'll have to check. BTW it's also code 0 in real (not debug) mode. – Marki Jun 4 '12 at 13:26

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.