1
# 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

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.

3
  • please post your /etc/logrotate.conf and /etc/logrotate.d/rsync* if it exists
    – krissi
    Jun 4, 2012 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, 2012 at 12:05
  • ah, sorry. Misunderstanding ;)
    – krissi
    Jun 4, 2012 at 13:31

1 Answer 1

1

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.

1
  • 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, 2012 at 13:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .