Bug 169578 - logconv.pl has an off by one bug in %monthname
logconv.pl has an off by one bug in %monthname
Product: 389
Classification: Community
Component: Command Line Utilities (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nathan Kinder
Viktor Ashirov
: 170039 (view as bug list)
Depends On:
Blocks: 152373 fds103trackingbug 240316
  Show dependency treegraph
Reported: 2005-09-29 15:55 EDT by Mike Jackson
Modified: 2015-12-07 11:58 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-12-07 11:58:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Mike Jackson 2005-09-29 15:55:19 EDT
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):


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:

Comment 2 Nathan Kinder 2006-04-18 14:21:25 EDT
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 14:51:47 EDT
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
Comment 4 Nathan Kinder 2006-04-18 14:53:27 EDT
*** Bug 170039 has been marked as a duplicate of this bug. ***
Comment 5 Michael Gregg 2007-11-20 20:49:29 EST
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.