Hide Forgot
Created attachment 940690 [details] access log Description of problem: Attached is a small example access log which can be used to reproduce this, I'm seeing the same on F20 & RHEL6. $ logconv.pl ./access - reports meaningful statistics $ logconv.pl -S foo ./access - reports all zeroes but does not complain about the invalid time string - should probably error out if the time string is invalid as otherwise the results will be unexpected and it's hard to spot such mistakes $ logconv.pl -S '[24/Sep/2014:10:10:00 +0300]' ./access - reports all zeroes and the printed "Start of Logs" does not match the provided time string Using -E does not seem to have any effect. Version-Release number of selected component (if applicable): F20 / RHEL6
This issue prevent the ds389log PMDA in PCP working properly, see http://oss.sgi.com/pipermail/pcp/2014-September/005683.html.
The given start and end time _must exist in the access log_. For example: $ awk '{print $1}' access | sort -u [24/Sep/2014:10:08:09 [24/Sep/2014:10:08:10 [24/Sep/2014:10:09:06 [24/Sep/2014:10:09:07 [24/Sep/2014:10:09:08 [24/Sep/2014:10:11:07 389-Directory/1.3.2.23 f20-test.example.com:389 Using any of these times works: $ logconv.pl -S '[24/Sep/2014:10:09:07' -E '[24/Sep/2014:10:09:08' access ----------- Access Log Output ------------ Start of Logs: 24/Sep/2014:10:09:07 End of Logs: 24/Sep/2014:10:09:08 Processed Log Time: 0 Hours, 0 Minutes, 1 Seconds Restarts: 0 Total Connections: 122 $ logconv.pl -E '[24/Sep/2014:10:08:10' access.bad ----------- Access Log Output ------------ Start of Logs: 24/Sep/2014:10:08:09 End of Logs: 24/Sep/2014:10:08:10 Processed Log Time: 0 Hours, 0 Minutes, 1 Seconds Restarts: 1 Total Connections: 235 $ logconv.pl -S '[24/Sep/2014:10:09:08' access ----------- Access Log Output ------------ Start of Logs: 24/Sep/2014:10:09:08 End of Logs: 24/Sep/2014:10:11:07 Processed Log Time: 0 Hours, 1 Minutes, 59 Seconds Restarts: 0 Total Connections: 117 So I guess this should be changed into an RFE - logconv.pl -E and -S arguments: timestamp should work even when date/time not present in log Does the PMDA functionality require being able to use dates/times not present in the log?
(In reply to Rich Megginson from comment #2) > The given start and end time _must exist in the access log_. Ok, I didn't see this mentioned in the man page. > Using any of these times works: > > $ logconv.pl -S '[24/Sep/2014:10:09:07' -E '[24/Sep/2014:10:09:08' access Yes, this works, but logconv.pl(1) states: -S, --startTime <time to begin analyzing logfile from> Time to begin analyzing logfile from E.g. [28/Mar/2002:13:14:22 -0800] -E, --endTime <time to stop analyzing logfile> Time to stop analyzing logfile from E.g. [28/Mar/2002:13:24:62 -0800] So it is strange that $ logconv.pl -S '[24/Sep/2014:10:09:07]' -E '[24/Sep/2014:10:09:08]' access does not work (note the trailing ]). I think this underlines the need for logconv.pl to abort on timestamps it does not recognise. > So I guess this should be changed into an RFE - logconv.pl -E and -S > arguments: timestamp should work even when date/time not present in log Ok. > Does the PMDA functionality require being able to use dates/times not > present in the log? Yes, but I think this would be useful functionality also in general (i.e. request for statistics between 10:00:00 and 11:00:00 with actually checking was there those exact timestamps present in the log. Thanks.
(In reply to Marko Myllynen from comment #3) > > Yes, this works, but logconv.pl(1) states: > > -S, --startTime <time to begin analyzing logfile from> > Time to begin analyzing logfile from E.g. > [28/Mar/2002:13:14:22 > -0800] > > -E, --endTime <time to stop analyzing logfile> > Time to stop analyzing logfile from E.g. > [28/Mar/2002:13:24:62 > -0800] > > So it is strange that > > $ logconv.pl -S '[24/Sep/2014:10:09:07]' -E '[24/Sep/2014:10:09:08]' access > > does not work (note the trailing ]). I think this underlines the need for > logconv.pl to abort on timestamps it does not recognise. Sigh, I missed the timezone part above, that was the reason the above didn't work. $ logconv.pl -S '[24/Sep/2014:10:09:07 +0300]' -E '[24/Sep/2014:10:09:08 +0300]' access works as expected.
(In reply to Marko Myllynen from comment #3) > (In reply to Rich Megginson from comment #2) > > The given start and end time _must exist in the access log_. > > Ok, I didn't see this mentioned in the man page. Because it's not there - we need to add it - the -S and -E arguments are definitely not intuitive. Or we just need to fix -S and -E handling (see below). > > > Using any of these times works: > > > > $ logconv.pl -S '[24/Sep/2014:10:09:07' -E '[24/Sep/2014:10:09:08' access > > Yes, this works, but logconv.pl(1) states: > > -S, --startTime <time to begin analyzing logfile from> > Time to begin analyzing logfile from E.g. > [28/Mar/2002:13:14:22 > -0800] > > -E, --endTime <time to stop analyzing logfile> > Time to stop analyzing logfile from E.g. > [28/Mar/2002:13:24:62 > -0800] > > So it is strange that > > $ logconv.pl -S '[24/Sep/2014:10:09:07]' -E '[24/Sep/2014:10:09:08]' access > > does not work (note the trailing ]). I think this underlines the need for > logconv.pl to abort on timestamps it does not recognise. It should be improved in this case - if there is a trailing ], it should just assume that the local current time zone is being used. > > > So I guess this should be changed into an RFE - logconv.pl -E and -S > > arguments: timestamp should work even when date/time not present in log > > Ok. > > > Does the PMDA functionality require being able to use dates/times not > > present in the log? > > Yes, but I think this would be useful functionality also in general (i.e. > request for statistics between 10:00:00 and 11:00:00 with actually checking > was there those exact timestamps present in the log. Agreed. The problem is that the comparison is just a simple string equality comparison - there is currently no concept of < or > in this comparison - to do so would probably require an actual date -> time_t conversion. > > Thanks.
Upstream ticket: https://fedorahosted.org/389/ticket/47910
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fixed upstream.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.