GNU Core Utilities - Patches: patch #6612, tail -F should attempt to read...
You are not allowed to post comments on this tracker with your current authentication level.
patch #6612: tail -F should attempt to read from old file until EOF is encountered
Submitter: | Jos Backus <josb> | ||
Submitted: | Sat 16 Aug 2008 07:53:08 AM UTC | ||
Votes: | 1 | ||
Category: | None | Priority: | 5 - Normal |
Status: | None | Privacy: | Public |
Assigned to: | None | Open/Closed: | Open |
Attached Files
file #16298: tail-dump_remainder.patch added by josb (321B - application/octet-stream - Patch implementing this feature)
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
There is 1 vote so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2008-08-31 | josb | Carbon-Copy | - | Added josb | |
2008-08-16 | josb | Attached File | - | Added tail-dump_remainder.patch, #16298 | |
Carbon-Copy | - | Added -email is unavailable- |
Powered by Savane 3.13-758e.
Corresponding source code
Currently when `tail -F filename' sees that `filename' was moved (by noticing the dev/ino combo changing), it immediately switches to reading from the new filename without making a last attempt to read from the old file. When tailing log files this will cause tail to miss data in the usual scenario where the old file is closed, moved and the new file opened with the same name. The moment the new file appears, writing will have stopped to the old file, as close() has mostly likely been called and any remaining data will have been flushed to disk. So there is a good chance that reading until EOF from the old file will yield the file's remainder.
This patch was stress-tested against coreutils-6.4 and daemontools' multilog on CentOS 4, in a setup that forced multilog to rotate files rapidly and that checked for gaps in the logging stream from tail using a sequence number. In all but the most extreme scenarios (where the file was being rotated multiple times per second), this patch virtually eliminated data loss.
A similar patch was committed to FreeBSD; see http://www.freebsd.org/cgi/query-pr.cgi?pr=101979&cat=bin for details and a description of the test setup.