[ZBX-7098] logrt possibly read old log file from very beginning after log rotation Created: 2013 Oct 04 Updated: 2017 May 30 Resolved: 2014 May 09 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Agent (G) |
Affects Version/s: | 2.0.8 |
Fix Version/s: | 2.0.13rc1, 2.2.4rc1, 2.3.0 |
Type: | Incident report | Priority: | Critical |
Reporter: | Kodai Terashima | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 0 |
Labels: | logrt | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
|
Description |
logrt possibly read old log file from very beginning after log rotation if new log and old log has same timestamp How to reproduce:
The procedure above is simulation of logrotate, but this problem happened with logrotated. |
Comments |
Comment by Oleksii Zagorskyi [ 2013 Nov 07 ] |
See also |
Comment by Andris Zeila [ 2013 Nov 08 ] |
There are two bugs that might/would happen if the last few log files have the same modification time:
Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-7098 |
Comment by Andris Mednis [ 2013 Dec 13 ] |
(1) The fix has been developed for Zabbix 2.2 but 2.0 also must be fixed. |
Comment by Andris Mednis [ 2014 Feb 06 ] |
Before fixing |
Comment by Andris Mednis [ 2014 Apr 11 ] |
The solution turned out to be more complex, than expected. Until now we used only file 'mtime' and 'lastlogsize' for following log file changes. We have added using inode numbers and MD5 sums of the first 512-bytes for deciding whether a log[] or logrt[] file checked during the previous check can be counted as the same file and can be checked from 'lastlogsize' position, or it is a different file and should be analyzed from the start. One consequence of the coming solution - do not modify 'mtime' of log files with 'touch', do not copy the log file with later restoration of the original name (it will change file's inode number). In both cases the file will be counted as different and will be analyzed from the start, which may result in duplicated alerts. On Microsoft Windows, if log files reside on NTFS or ReFS file systems, we have added 64-bit file indexes or 128-bit file IDs to track log file rotation. On file systems where file indexes change (e.g. FAT32) we have developed a fall-back algorithm to take a sensible approach in uncertain conditions. |
Comment by Andris Mednis [ 2014 May 09 ] |
For Zabbix 2.0 available in development branch svn://svn.zabbix.com/branches/dev/ZBX-7098-20-1 It is a significant change, need to be thoroughly tested on UNIX, GNU/Linux (with various file systems) and Microsoft Windows (including log files on NTFS, FAT32 (or eXFAT) and ReFS), including complicated log file rotations, truncations, multiple log files with the same modification time, even with identical log files... Try to break it in various ways. wiper successfully tested |
Comment by Andris Mednis [ 2014 May 20 ] |
For Zabbix 2.2 available in development branch svn://svn.zabbix.com/branches/dev/ZBX-7098-22-1 wiper successfully tested |
Comment by Andris Mednis [ 2014 May 20 ] |
For trunk available in development branch svn://svn.zabbix.com/branches/dev/ZBX-7098-23 wiper successfully tested |
Comment by Andris Zeila [ 2014 May 21 ] |
Successfully tested! |
Comment by Andris Mednis [ 2014 May 21 ] |
Fixed in versions pre-2.0.13 r45702, pre-2.2.4 r45706, pre-2.3.0 r45718. |
Comment by Andris Mednis [ 2014 May 21 ] |
Documented at wiper technical review done. martins-v Reviewed as well. Some small grammar points improved. CLOSED. |
Comment by Andris Mednis [ 2014 May 29 ] |