Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/419https://bugzilla.redhat.com/show_bug.cgi?id=823882 (''Red Hat Directory Server'')
{{{
RFE Request
0. Proposed title of this feature request
Feature Request: better memory management in logconv.pl
2. What is the nature and description of the request?
Feature Request: better memory management in logconv.pl
3. Why does the customer need this? (List the business requirements here)
Since with Directory Server Red Hat offer an enterprise solution, a company
should be able to expect enterprise behaviour, in this case that is that the
product won't break from regular use. This is what's happening with the use of
logconv.pl: we use it to handle an undefined amount of logs, and we expect it
to do anyhing BUT break the system and cause unavailability. Whether it be an
error message (too many logs), a better handling of the logs (i.e. in chunks)
or a better memory management, all is acceptable. For a script like this to
crash a server is unacceptable in an enterprise environmemt.
4. How would the customer like to achieve this? (List the functional
requirements here)
Customer is expecting better memory Management in logconv.pl in below ways.
- refusing to start processing logs altogether when logconv.pl calculates the
logs are too big to be processed in memory
- processing logs in sizeable chunks and later adding these processed chunks
together to do a final report
- fine-tune the memory usage of logconv.pl
- finding temporary diskspace to flush parts of memory (of course with the
option of still one of the previous three when disk space is too low)
5. For each functional requirement listed in question 4, specify how Red Hat
and the customer can test to confirm the requirement is successfully
implemented.
Create a replica setup which generate 5 GB of daily logs & try to run
logconv.pl.
6. Is there already an existing RFE upstream or in Red Hat bugzilla?
No
7. How quickly does this need resolved? (desired target release)
No time-line
8. Does this request meet the RHEL Bug and Feature Inclusion Criteria (please
review)
Yes
9. List the affected packages
389-ds-base
10. Would the customer be able to assist in testing this functionality if
implemented?
Yes
}}}
USCBP would like this and all logconv.pl enhancements not currently in 6.4 to be available in 6.5
*** Bug 1111164 has been marked as a duplicate of this bug. ***
Comment 10srkrishn@redhat.com
2014-08-18 11:10:37 UTC
using logconv.pl -efcibaltnxrgjuyp accesslog
I got the following errors:
Use of uninitialized value $1 in string ne at /usr/bin/logconv.pl line 2135, <LOG> line 113254.
Use of uninitialized value $1 in array element at /usr/bin/logconv.pl line 2134, <LOG> line 113256.
Use of uninitialized value $1 in string ne at /usr/bin/logconv.pl line 2135, <LOG> line 113256.
Use of uninitialized value $1 in hash element at /usr/bin/logconv.pl line 2146, <LOG> line 113256.
Use of uninitialized value $1 in array element at /usr/bin/logconv.pl line 2134, <LOG> line 113258.
tested on version:1.2.11.15 38.el6
Comment 12srkrishn@redhat.com
2014-08-19 12:10:27 UTC
this bug has been verified:
using logconv.pl -efcibaltnxrgjuyp accesslog
----- Top 20 Most returned nentries -----
224952 nentries=1
9254 nentries=0
980 nentries=2
672 nentries=3
----- Top 20 Longest etimes -----
etime=40 14
etime=39 42
etime=38 14
etime=37 28
----- Top 20 Search Filters -----
Number of Unique Search Filters: 11944
22400 (objectclass=raboperson)
20622 (&(objectclass=raboperson)(uid=topaz_am)(activeentry=1))
6776 (objectclass=*)
5054 (&(objectclass=person)(cn=te*))
2240 (&(objectclass=platformfunction)(!(activeentry=0)))
real 19m20.916s
user 17m46.122s
sys 1m30.416s
this was tested on 1.2.11.15.40
Comment 13Sankar Ramalingam
2014-08-19 12:29:45 UTC
Based on previous comment from Sriram, I am marking the bug as Verified.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHBA-2014-1385.html