logresolvemerge is very helpful in detecting different time formats without help. Unfortunately it also can be confused by log contents. The following has hit us a couple of times the last month or so, causing logresolvemerge to pick the wrong time information
The following log line
138.201.23.68 - - [28/Mar/2023:02:08:55 +0200] "GET / HTTP/1.1" 200 197475 "https://www.uni-erfurt.de/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_5_0; rv:1.9.3.20) Gecko/3764-11-07 02:32:07 Firefox/3.8"
makes logresolvemerge select the time as "3764-11-07 02:32:07" causing the rest of this file to be retained until all other files have been emptied, and then to be dropped by awstats because of wrong order.
I have fixed the problem for us by flipping the two first time match lines, because we only handle Apache common log, but the proper solution will require copying part of the LogFormat logic from awstats.pl to logresolvemerge.pl
logresolvemerge is very helpful in detecting different time formats without help. Unfortunately it also can be confused by log contents. The following has hit us a couple of times the last month or so, causing logresolvemerge to pick the wrong time information
The following log line
138.201.23.68 - - [28/Mar/2023:02:08:55 +0200] "GET / HTTP/1.1" 200 197475 "https://www.uni-erfurt.de/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_5_0; rv:1.9.3.20) Gecko/3764-11-07 02:32:07 Firefox/3.8"
makes logresolvemerge select the time as "3764-11-07 02:32:07" causing the rest of this file to be retained until all other files have been emptied, and then to be dropped by awstats because of wrong order.
I have fixed the problem for us by flipping the two first time match lines, because we only handle Apache common log, but the proper solution will require copying part of the LogFormat logic from awstats.pl to logresolvemerge.pl