Paul Martin wrote:
They did fix it for the shared scripts, but not for the single file
case.
I've written a patch to fix this, and it will be in 3.7.1-3.
Ah, thanks.
For example, I frequently see emails that look like:
/etc/cron.daily/logrotate:
Null message body; hope that's ok
which are caused when logrotate attempts to mail an empty log file.
(Apparently 'mail' doesn't return an error code in this case, which
seems reasonable.)
If you think that zero length logs shouldn't be mailed, I'd suggest
opening a new bug about that.
I used the 'notifempty' directive to avoid the problem.
More generally speaking, I don't think logrotate is in error for mailing
empty log files. The fault is really with 'mail' for producing spurious
warnings to STDERR.
But logrotate makes correcting that problem more difficult by not
identifying the context in which the warning message was produced.
The behaviour of programs in a script is not something that logrotate
can control.
It's not that it should control it, but that it should accept the
responsibility of providing context, given that it executes a bunch of
different external processes from within its "black box."
Clearly, any external process returning an error exit code should lead
to logrotate providing contextual information identifying what portion
of the config file was being processed when the error occurred. (And
your patch will hopefully address this.)
What's less clear is whether logrotate should provide this information
even with a zero exit code, if the child process produced output to
STDERR. The reality is that cron will generate a mail message if it sees
any output to STDERR (STDOUT as well, I believe), regardless of the exit
code, and logrotate is intended to be executed by cron (or the equivalent).
A common scenario where something like this helps is when a user
modifies multiple postrotate directives, say calling an init.d script,
and forgets to direct non-error output to /dev/null. This will trigger
mail from cron, and have no context from logrotate. If they're lucky,
the produced output will identify the cause.
Difficult to fix that one, as that depends on the behaviour of the mail
program.
Difficult (or ugly), yes, but it doesn't depend on what is being executed.
The classic approach would be to redirect output from the child
processes to a temp file, and then after the process exits, if the file
is non-zero, wrap it in context information before copying the contents
to STDERR and/or STDOUT. The cron code base probably has an
implementation of this.
If we presume logrotate now consistently provides context information if
a child process has a non-zero exit code, then the following POSIX shell
wrapper will trigger logrotate to provide that context.
TMPOUT=$TMP/lr$$ ; child > $TMPOUT 2>&1 ; EC=$? ; \
[ ! -s $TMPOUT ] ; OUT=$? ; cat $TMPOUT; rm $TMPOUT ; \
if [ $EC -gt 0 ]; then exit $EC; else exit $OUT; fi
where 'child' is the child command logrotate wants to run, and TMPOUT is
set appropriately to some process unique temporary file.
(I initially tried a version using tee, but the pipe gets in the way of
catching the true exit code of the child process. The need to clean up
the temporary file also complicates things.)
-Tom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
