Bug 5
| Summary: | logrotate fails (unnecessarily) when prerotate script runs without effect | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | seth |
| Component: | logrotate | Assignee: | David Lawrence <dkl> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 5.2 | Flags: | chaowan:
needinfo-
|
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 1998-11-20 12:00:42 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. 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.
by de facto standard, unix commands exit with a nonzero status when there has been an error. > 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
|
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.