logrotate(8) and copytruncate as default
P J P
pj.pandit at yahoo.co.in
Fri Jun 28 20:46:45 UTC 2013
----- Original Message -----
> From: Lennart Poettering <mzerqung at 0pointer.de>
> Subject: Re: logrotate(8) and copytruncate as default
> journald is the only writer, it doesn't need locking. The changes it
> does are done in a way so that concurrent readers will either see the
> changes or not, but never half-written changes.
I see. How is that done? Does journald also renames the current file and
creates a new one and continues writing to that new file??
I'm asking because, if not, then journald could also suffer from the same
buffering issue that kernel seems to do with locking. Ie. As the file size grows
copy-truncate takes time, kernel is unable to buffer all the writes that happen
during that time, so it starts dropping a few, which results in data loss.
> Also note that locking on Linux is seriously broken. You can get a lock
> on any file you can read, thus you can freeze everybody else who might
> want a lock. Or in other words: if a logging daemon takes a lock on its
> lock files, then you can use this to make that service freeze forever.
Yeah, I realised that. I posted a small script earlier in this thread.
With locking, you start seeing data loss as the file size grows >= 2MB.
More information about the devel