logrotate(8) and copytruncate as default
mitr at volny.cz
Thu Jun 27 18:10:34 UTC 2013
On Thu, Jun 27, 2013 at 7:58 PM, P J P <pj.pandit at yahoo.co.in> wrote:
> IMHO, renaming a
> file which is being written to by another application does no feel right.
>> _Any_ data loss during normal operation is _unacceptable_.
> Sure! As per the experiment so far, there is no data loss at all.
There can be a data loss:
* logrotate reads all contents of file until EOF
* application appends one more data line
* logrotate calls truncate()
No amount of testing can give us confidence that "this can't happen".
In designing concurrently-operating processes, we need invariants and
proofs more than we need experimental data; experimental data is only
useful to the extent that it can demonstrate errors in thinking when
creating the proofs.
>> The rename+create new file+SIGHUP+reopen "protocol" is both safe and
> Safe? There is a race condition in it for which a CVE has been assigned.
That's not an inherent aspect of the design. It could have been fixed
and has been fixed.
(And yes, journald solves that by integrating the log rotation with
the log writer, which is a better design, and there's no inherent
reason why rsyslog couldn't be doing something similar. Then there
are only the dozens? of applications that don't go through syslog at
all and write their own log files to also handle...)
More information about the devel