Bug 5 - logrotate fails (unnecessarily) when prerotate script runs without effect
logrotate fails (unnecessarily) when prerotate script runs without effect
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: logrotate (Show other bugs)
5.2
All Linux
low Severity low
: ---
: ---
Assigned To: David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1998-11-08 13:44 EST by seth
Modified: 2013-05-06 13:15 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1998-11-20 07:00:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
chaowan: needinfo-


Attachments (Terms of Use)

  None (edit)
Description seth 1998-11-08 13:44:14 EST
I am reasonably certain that I have found an undocumented
piece of behavior in the prerotate part of logrotate-2.6
In particular, commands have to succeed if logrotate will
succeed.  This makes it clumsy to use logrotate to,
for example, grep out potentially interesting pieces of
log files.

Let me illustrate.

Here is an example from the relevant part of the
config file.

prerotate

grep something filename >> output

endscript

If grep does not find anything, then the following
error message is reported.  (I have just clipped out
a piece from the error message that was mailed to me,
of course the file name depends on what script is
being run, but I have confirmed this with different
logs and scripts).


errors occured while rotating /home/seth/adm/info.log

error running prerotate script --
                                leaving old log in place


However, if I add a test to check whether there
is anything to grep before trying to grep:

prerotate
check=`/usr/bin/grep passwd /home/seth/adm/info.log `
if [ -n "$check" ] ; then
grep passwd /home/seth/adm/info.log >> output
fi
endscript

Then it works all right.

I can reliably repeat this error.

Thanks for any feedback about the validity of this
analysis.
Comment 1 zblaxell 1998-11-17 14:16:59 EST
Two solutions:

	grep something filename >> output || exit 0

(i.e. grep succeeds, or 'exit 0' succeeds)

or:

	grep something filename | cat >> output

(the pipeline will ignore the exit status of grep, but will still
report errors such as "no space left on device" or "permission denied"
or "I/O error").

Perhaps the documentation should be updated.  The principle of least
surprise says that the established behavior shouldn't change.
Comment 2 seth 1998-11-20 00:43:59 EST
Ok...I looked in the source code.  I can see starting line 395

  if (runScript(log->files[logNum], log->pre)) {
                    fprintf(errorFile, "error running prerotate script
--
                                leaving old log in place\n");
                    hasErrors = 1;

And RunScript() is returning the result from the system command.
So presumably a grep that finds nothing is appearing to be an
error.   It has been a while since I have played with system()
Isn't it possible to have more nuance in interpreting the
kinds of errors?

If not, then perhaps the man page should be modified to reflect
this fact.
Comment 3 Preston Brown 1998-11-20 07:00:59 EST
by de facto standard, unix commands exit with a nonzero status when
there has been an error.
Comment 4 seth 1998-11-20 09:23:59 EST
> by de facto standard, unix commands exit with a nonzero status
  > when there has been an error.

True.  But you do not seem to appreciate the point that the
manpage logrotate(1) does not inform what logrotates behavior will be
under those circumstances.

Here is the relevant piece:

 prerotate/endscript
              The lines between prerotate and endscript (both  of
              which  must appear on lines by themselves) are exe-
              cuted before the log file is rotated. These  direc-
              tives  may only appear inside of a log file defini-
              tion.  See postrotate as well

Nowhere does it say "Failures will result in the non-execution of
the rotation" or warn that this also means that greps that return
nothing will count as a failure.

You can discard the issue if you want, but it is poor documentation,
especially when one considers the "typical" use of a prerotate
script would be pull out and save potentially interesting
things from a log file, and where one is likely to get a
grep that returns nothing.

Cheers,
  Seth

Note You need to log in before you can comment on or make changes to this bug.