Bug 169578 - logconv.pl has an off by one bug in %monthname
Summary: logconv.pl has an off by one bug in %monthname
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Command Line Utilities
Version: 7.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Viktor Ashirov
URL:
Whiteboard:
: 170039 (view as bug list)
Depends On:
Blocks: 152373 fds103trackingbug 240316
TreeView+ depends on / blocked
 
Reported: 2005-09-29 19:55 UTC by Mike Jackson
Modified: 2015-12-07 16:58 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-12-07 16:58:39 UTC
Embargoed:


Attachments (Terms of Use)
CVS Diffs (845 bytes, patch)
2006-04-18 18:21 UTC, Nathan Kinder
no flags Details | Diff

Description Mike Jackson 2005-09-29 19:55:19 UTC
Description of problem:

logconv.pl %month hash is off by one. Month numbers should start with 0,
otherwise the tool will fail when parsing a log where there are days numbered
with 31.

Version-Release number of selected component (if applicable):

All.

How reproducible:

Every time.

Steps to Reproduce:
1. Run logconv.pl on an access logfile with days which are numbered 31.

  
Actual results:

Time::Local will fail and say day 31 out of range, use 0..30.


Expected results:

That it would work.

Additional info:

None.

Comment 2 Nathan Kinder 2006-04-18 18:21:25 UTC
Created attachment 127938 [details]
CVS Diffs

The timegm() subroutine expects the month to be specified as a range of 0..11. 
We were using a range of 1..12 in logconv.pl which would cause timegm() to
report out of range errors when the log was from the month of december or if
the month that we incorrectly mapped to contained less days the day of the
month that the log specified (ex. - If the log has an entry for January 30th,
we'd incorrectly map this to February 30th, which is an invalid date).

This fix changes the range we use for the month to 0..11.

Comment 3 Nathan Kinder 2006-04-18 18:51:47 UTC
Checked into ldapserver.  Reviewed by RIch and Noriko.

Checking in logconv.pl;
/cvs/dirsec/ldapserver/ldap/admin/src/logconv.pl,v  <--  logconv.pl
new revision: 1.6; previous revision: 1.5
done

Comment 4 Nathan Kinder 2006-04-18 18:53:27 UTC
*** Bug 170039 has been marked as a duplicate of this bug. ***

Comment 5 Michael Gregg 2007-11-21 01:49:29 UTC
Some of the entries in the log file I checked aginst:
[31/Oct/2007:10:13:05 -0400] conn=527 op=4 RESULT err=0 tag=101 nentries=5 etime=0
[31/Oct/2007:10:13:05 -0400] conn=527 op=5 SRCH base="cn=replica,cn=\22ou=ou2
with space,o=o1\22,cn=mapping tree,cn=config" scope=2
filter="(objectClass=nsDS5ReplicationAgreement)" attrs="cn
nsds5BeginReplicaRefresh nsds5replicaUpdateInProgress nsds5replicaLastInitStatus
nsds5replicaLastInitStart nsds5replicaLastInitEnd nsds5replicareapactive
nsds5replicaLastUpdateStart nsds5replicaLastUpdateEnd
nsds5replicaChangesSentSinceStartup nsds5replicaLastUpdateStatus
nsDS5ReplicaHost nsDS5ReplicaPort nsDS5ReplicaBindMethod
nsDS5ReplicaUpdateSchedule nsDS5ReplicaTransportInfo"
[31/Oct/2007:10:13:05 -0400] conn=527 op=5 RESULT err=0 tag=101 nentries=5 etime=0

logconf.pl seemed to run aginst the access log just fine.

Verified against:
1191427572 redhat-ds-base-8.0.0-5.el4dsrv Wed Oct 03 2007 


Note You need to log in before you can comment on or make changes to this bug.