1746941 – Glob not working as expected for ManageIQ plugin

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.

Bug 1746941 - Glob not working as expected for ManageIQ plugin

Summary: Glob not working as expected for ManageIQ plugin

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	sos
Sub Component:
Version:	7.7
Hardware:	Unspecified
OS:	Unspecified
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Pavel Moravec
QA Contact:	Miroslav Hradílek
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2019-08-29 14:39 UTC by David Luong
Modified:	2020-10-08 15:19 UTC (History)
CC List:	6 users (show)
Fixed In Version:	sos-3.9-2.el7
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2020-09-29 20:55:10 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Priority	Status	Summary	Last Updated
Github	sosreport sos pull 1779	None	closed	[manageiq] modify plugin to account for regularly large files	2020-10-08 13:44:24 UTC
Github	sosreport sos pull 1802	None	closed	[plugin] add_copy_spec handle same file diff sizelimit	2020-10-08 13:44:24 UTC
Red Hat Product Errata	RHEA-2020:4034	None	None	None	2020-09-29 20:55:50 UTC

Description David Luong 2019-08-29 14:39:01 UTC

Description of problem:
Glob not working as expected for ManageIQ plugin for *.log in /var/www/miq/vmdb/log dir

Version-Release number of selected component (if applicable):
sos-3.7-5.el7.noarch

How reproducible:
Sometimes

Steps to Reproduce:
1.  Collect sos report
2.
3.

Actual results:

Log directory is pretty bare:
# ls -alh sosreport-localhost-2019-08-28-nyplspm/var/www/miq/vmdb/log

drwxr-xr-x. 3 root root  182 Aug 28 17:06 .
drwxr-xr-x. 4 root root   85 Aug 28 16:41 ..
lrwxrwxrwx. 1 root root   81 Aug 28 17:33 ansible_tower.log -> ../../../../../sos_strings/manageiq/var.www.miq.vmdb.log.ansible_tower.log.tailed
drwxr-xr-x. 2 root root   94 Jul 29 20:55 apache
-rw-r--r--. 1 root root  22M Aug 28 17:34 evm.log
-rw-r--r--. 1 root root 115K Aug 28 16:43 gem_list.txt
-rw-r--r--. 1 root root  66K Aug 28 17:25 last_settings.txt
-rw-r--r--. 1 root root  77K Aug 28 16:43 last_startup.txt
-rw-r--r--. 1 root root 426K Aug 28 16:43 package_list_rpm.txt
-rw-r--r--. 1 root root  73K Aug 28 17:34 vmstat_output.log


Expected results:

# ls -al sosreport-localhost-2019-08-29-uhniazi/var/www/miq/vmdb/log/

ansible_tower.log         audit.log                 container_monitoring.log  gem_list.txt              lenovo.log                production.log            top_output.log            websocket.log             
apache/                   automation.log            datawarehouse.log         kubernetes.log            nuage.log                 redfish.log               vcloud.log                
api.log                   aws.log                   evm.log                   last_settings.txt         package_list_rpm.txt      rhevm.log                 vim.log                   
appliance_console.log     azure.log                 fog.log                   last_startup.txt          policy.log                scvmm.log                 vmstat_output.log   

Additional info:

Running with the --all-logs option brings in all the missing logs plus the archives, so that's working as expected.  

Also, behavior is inconsistent.  Yesterday was the sosreport generated in actual results.  Today was the sosreport generated in expected results.  Same machine, no changes.

Comment 3 Pavel Moravec 2019-09-02 19:09:12 UTC

manageiq plugin collects by default these log files:

/var/www/miq/vmdb/log/*.log
/var/www/miq/vmdb/log/apache/*.log
/var/www/miq/vmdb/log/*.txt

By default, it collects 25MB of data of each type. Sosreport orders files from newest to oldest (per mtime), and collects them. Once the 25MB limit is reached, the latest file is tailed only - that's why:

ansible_tower.log -> ../../../../../sos_strings/manageiq/var.www.miq.vmdb.log.ansible_tower.log.tailed

as this was the first file over the limit.


Workaround: call sosreport with option --log-size 40 (or whatever limit works for you, in MB)

Resolution:
- either increase the limit by default (trivial change), 
- or impose it more granularly. Currently the limit is applied per the 3 logfile patterns individually. It is possible to apply it per individual files (that would have to be enumerated each and every one, or via some file pattern)

Could you please state what granularity and what size limits should be used to collect the logfiles?

To play with the stuff, see /usr/lib/python2.7/site-packages/sos/plugins/manageiq.py and miq_log_dir / miq_log_files / namely:

        self.add_copy_spec([
            os.path.join(self.miq_log_dir, x) for x in self.miq_log_files
        ])

(one can add sizelimit=40 as add_copy_spec method argument, or make the list more granular, or call add_copy_spec more times (with different sizelimit, optionally))


Please provide specification how to modify the current behaviour.

Comment 4 David Luong 2019-09-06 02:30:14 UTC

Hey Pavel,

Thanks for the advice, I got around this by listing the specific log files individually for the ones that I can't predict the size for, eg, evm.log, production.log, etc.  However, for the glob, it also looks like it limits it to 4 items.  Any way to bypass this?

Comment 5 David Luong 2019-09-06 04:08:48 UTC

Nevermind, there was something wrong with my pattern matching.

Comment 6 Pavel Moravec 2019-09-16 06:00:32 UTC

(In reply to David Luong from comment #5)
> Nevermind, there was something wrong with my pattern matching.

Let me know if I can help here any way.

Comment 7 Jan Jansky 2020-05-06 15:14:16 UTC

(In reply to David Luong from comment #5)
> Nevermind, there was something wrong with my pattern matching.

Can you please confirm if this was just wrong pattern matching and we can close this BZ or if you still need our assistance?

Comment 8 David Luong 2020-05-06 15:18:19 UTC

I think I solved this problem in one of the 2 PRs I submitted below (the changes are merged already)

https://github.com/sosreport/sos/pull/1779
https://github.com/sosreport/sos/pull/1802

If those changes are in RHEL 7 already then this BZ can be closed out.

Comment 9 Jan Jansky 2020-05-08 07:08:34 UTC

Both PRs are merged and linked with release 3.9.1 which means those PRs should be present in rhel 7.9 (sos 3.9.1).

Comment 13 Jan Jansky 2020-06-01 14:14:08 UTC

Hello,
thanks for the availability to test the fix. Please use below repository / package:


A yum repository for the build of sos-3.9-2.el7 (task 28860092) is available at:

http://brew-task-repos.usersys.redhat.com/repos/official/sos/3.9/2.el7/

You can install the rpms locally by putting this .repo file in your /etc/yum.repos.d/ directory:

http://brew-task-repos.usersys.redhat.com/repos/official/sos/3.9/2.el7/sos-3.9-2.el7.repo

RPMs and build logs can be found in the following locations:
http://brew-task-repos.usersys.redhat.com/repos/official/sos/3.9/2.el7/noarch/

The full list of available rpms is:
http://brew-task-repos.usersys.redhat.com/repos/official/sos/3.9/2.el7/noarch/sos-3.9-2.el7.src.rpm
http://brew-task-repos.usersys.redhat.com/repos/official/sos/3.9/2.el7/noarch/sos-3.9-2.el7.noarch.rpm

The repository will be available for the next 60 days. Scratch build output will be deleted
earlier, based on the Brew scratch build retention policy.

Comment 14 David Luong 2020-06-08 13:16:09 UTC

Tested and works as expected.

Comment 18 errata-xmlrpc 2020-09-29 20:55:10 UTC

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 (sos bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:4034

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