Regarding the patch proposed by Bolesław Tokarski
(logrotate-dest-file-exists(2).patch) , I would not want logrotate to
delete a zero-size log file that it happens to find on the system. An
empty log file could be telling you something very important!
However, if logrotate runs into an error which causes it to create a
superfluous empty file *itself*, then I would definitely support an
immediate rollback at that point by having logrotate eliminate the empty
file it just created.
My scenario for running into this bug is the following. Say the "/var"
partition gets nearly full. logrotate tries to compress x.1 but there
isn't sufficient space so it ends up with an empty x.1.gz, but x.1 is
still fully intact. Next time around, logrotate won't even try to
compress x.1 because it is already blocked by the empty x.1.gz that the
previous round of logrotate itself created.
So, towards the end of logrotate.c::compressLogFile() I would propose an
addition in accordance with the following comment:
if (!WIFEXITED(status) || WEXITSTATUS(status)) {
/* if outFile is empty then delete it */
message(MESS_ERROR, "failed to compress log %s\n", name);
return 1;
}
And, of course, I would want to log the error message. :)
-Zach
