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.
Description of problem:
When generating sosreports on glusterfs servers or clients, the /var/log/glusterfs log collection is unconstrained and unconstrainable, leading to potentially extremely large sosreports.
Version-Release number of selected component (if applicable):
sos-2.2-38.el6.noarch
How reproducible:
Consistently on running a sosreport on a glusterfs server or client.
Steps to Reproduce:
1. Install glusterfs packages and enable services
2. Generate extensive logs
3. Run sosreport
Actual results:
All /var/log/glusterfs log files are collected without limit.
Expected results:
A default and tunable limit for log collection should be used.
Additional info:
Taking a look at the sosreport python scripts, we can see that the syslog size limitation is only applied to certain logs.
# sosreport -l | grep size
auditd.syslogsize 15 max size (MiB) to collect per syslog file
general.syslogsize 15 max size (MiB) to collect per syslog file
printing.cups 50 max size (MiB) to collect per cups log file
vdsm.logsize off max size (MiB) to collect per log file
# grep syslogsize *py
auditd.py: optionList = [("syslogsize", "max size (MiB) to collect per syslog file", "", 15)]
auditd.py: self.addCopySpecLimit("/var/log/audit*", sizelimit = self.getOption("syslogsize"))
general.py: optionList = [("syslogsize", "max size (MiB) to collect per syslog file", "", 15),
general.py: self.addCopySpecLimit("/var/log/messages*", sizelimit = self.getOption("syslogsize"))
general.py: self.addCopySpecLimit("/var/log/secure*", sizelimit = self.getOption("syslogsize"))
general.py: self.addCopySpecLimit(i, sizelimit = self.isOptionEnabled("syslogsize"))
The gluster plugin for sosreport seems to collect all logs without limit, and without option for limit. :-/
# grep log gluster.py
# collect this last as some of the other actions create log entries
self.addCopySpec("/var/log/glusterfs")
This request is to add the same or similar limit functionality as provided by the syslogsize option in general.py and auditd.py to gluster.py as well. An appropriate default maximum should be set, but what that default should be I'm sure is a matter of debate.
AFAIK, a sosreport will collect all files in /var/log/glusterfs without restriction. This can result in extremely large sosreports (20GB in a current case) that are difficult to deliver and retrieve, and can cause significant latency in supporting a customer.
That's correct. This is a trivial change to add a 'logsize' parameter and switch to the addCopySpecLimit() API. Changes of this type are considered bugs rather than feature requests in sos since they have major usability impacts.
Because of the way that gluster structures its logs I've applied limiting separately to each of the (non-rotated) default log paths:
# all_logs takes precedence over logsize
if not self.getOption("all_logs"):
limit = self.getOption("logsize")
else:
limit = 0
if limit:
# collect logs last as some of the other actions create log entries
self.addCopySpecLimit("/var/log/glusterfs/cli.log", limit)
self.addCopySpecLimit("/var/log/glusterfs/*.vol.log", limit)
self.addCopySpecLimit("/var/log/glusterfs/gluster-lock.log", limit)
self.addCopySpecLimit("/var/log/glusterfs/glustershd.log", limit)
self.addCopySpecLimit("/var/log/glusterfs/nfs.log", limit)
self.addCopySpecLimit("/var/log/glusterfs/quota-crawl.log", limit)
self.addCopySpecLimit("/var/log/glusterfs/quotad.log", limit)
self.addCopySpecLimit("/var/log/glusterfs/quotad-mount-*.log", limit)
self.addCopySpecLimit("/var/log/glusterfs/status.log", limit)
self.addCopySpecLimit("/var/log/glusterfs/bricks/*.log", limit)
This considerably reduces the size of these paths for a typical installation:
# sosreport -v --batch --debug -o gluster
[...]
# du -ch bmr-rhel6-vm1-2014061917231403195010/var/log/glusterfs/
12K bmr-rhel6-vm1-2014061917231403195010/var/log/glusterfs/bricks
40K bmr-rhel6-vm1-2014061917231403195010/var/log/glusterfs/
40K total
The old behaviour may be obtained by passing '-k gluster.all_logs' or '-k gluster.logsize=0':
# sosreport -v --batch --debug -o gluster -k gluster.all_logs
[...]
# du -ch bmr-rhel6-vm1-2014061917261403195160/var/log/glusterfs/
60K bmr-rhel6-vm1-2014061917261403195160/var/log/glusterfs/bricks
292K bmr-rhel6-vm1-2014061917261403195160/var/log/glusterfs/
292K total
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-1528.html
Description of problem: When generating sosreports on glusterfs servers or clients, the /var/log/glusterfs log collection is unconstrained and unconstrainable, leading to potentially extremely large sosreports. Version-Release number of selected component (if applicable): sos-2.2-38.el6.noarch How reproducible: Consistently on running a sosreport on a glusterfs server or client. Steps to Reproduce: 1. Install glusterfs packages and enable services 2. Generate extensive logs 3. Run sosreport Actual results: All /var/log/glusterfs log files are collected without limit. Expected results: A default and tunable limit for log collection should be used. Additional info: Taking a look at the sosreport python scripts, we can see that the syslog size limitation is only applied to certain logs. # sosreport -l | grep size auditd.syslogsize 15 max size (MiB) to collect per syslog file general.syslogsize 15 max size (MiB) to collect per syslog file printing.cups 50 max size (MiB) to collect per cups log file vdsm.logsize off max size (MiB) to collect per log file # grep syslogsize *py auditd.py: optionList = [("syslogsize", "max size (MiB) to collect per syslog file", "", 15)] auditd.py: self.addCopySpecLimit("/var/log/audit*", sizelimit = self.getOption("syslogsize")) general.py: optionList = [("syslogsize", "max size (MiB) to collect per syslog file", "", 15), general.py: self.addCopySpecLimit("/var/log/messages*", sizelimit = self.getOption("syslogsize")) general.py: self.addCopySpecLimit("/var/log/secure*", sizelimit = self.getOption("syslogsize")) general.py: self.addCopySpecLimit(i, sizelimit = self.isOptionEnabled("syslogsize")) The gluster plugin for sosreport seems to collect all logs without limit, and without option for limit. :-/ # grep log gluster.py # collect this last as some of the other actions create log entries self.addCopySpec("/var/log/glusterfs") This request is to add the same or similar limit functionality as provided by the syslogsize option in general.py and auditd.py to gluster.py as well. An appropriate default maximum should be set, but what that default should be I'm sure is a matter of debate.