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 1726461 - sosreport doesnt collect symlink dirs in container
Summary: sosreport doesnt collect symlink dirs in container
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sos
Version: 7.6
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Pavel Moravec
QA Contact: Miroslav Hradílek
URL:
Whiteboard:
Depends On:
Blocks: 1728214
TreeView+ depends on / blocked
 
Reported: 2019-07-02 23:06 UTC by Parikshit Khedekar
Modified: 2023-03-24 15:02 UTC (History)
6 users (show)

Fixed In Version: sos-3.8-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1728214 (view as bug list)
Environment:
Last Closed: 2020-03-31 20:04:09 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github sosreport sos pull 1705 0 None closed [archive] Handle checking container sysroot in _make_leading_paths 2020-04-15 21:47:06 UTC
Red Hat Product Errata RHEA-2020:1127 0 None None None 2020-03-31 20:04:59 UTC

Comment 2 Pavel Moravec 2019-07-03 06:22:34 UTC 
Sorry but this is not a bug report. This is a report about properly working tool, that detected its plugins running out of time, according to its specification.

What in particular got wrong during the execution? Some particular command was invoked by sos wrongly such that it hung (and caused the timeouts)? Or too many redundant commands were called by sos?

Or was the problem caused by hanging commands (that were properly kicked off by sos)? By some container problem? By system swapping and slowing down everything?

Why are you convinced the problem is in sosreport, please? And if so, how can I reproduce it?
Comment 4 Pavel Moravec 2019-07-03 07:43:01 UTC 
(well now I realized the plugin default timeout is just 300s, so I am curious why the plugin kicked off commands after that limit, but still the problem remains the same: too much activity required from a plugin within given timeout)
Comment 6 Pavel Moravec 2019-07-04 06:45:22 UTC 
Re-phrased the subject.

This BZ will therefore backport https://github.com/sosreport/sos/pull/1705 .

Please provide a reproducer, it works well for me on some default test I run. Or grant OtherQE.
Comment 7 Jake Hunsaker 2019-08-01 16:45:21 UTC 
Sorry, didn't notice the request for reproducer.

As far as I can tell, any recent branch of Atomic Host will show this behavior when sos is run inside the support-tools container. If you sideload the sos rpm into the branch (something no one should be doing), you don't get the errors. It's specifically about running in a container.

With #1705, I don't see the exceptions inside a container.
Comment 8 Pavel Moravec 2019-08-11 08:45:43 UTC 
(In reply to Jake Hunsaker from comment #7)
> Sorry, didn't notice the request for reproducer.
> 
> As far as I can tell, any recent branch of Atomic Host will show this
> behavior when sos is run inside the support-tools container. If you sideload
> the sos rpm into the branch (something no one should be doing), you don't
> get the errors. It's specifically about running in a container.
> 
> With #1705, I don't see the exceptions inside a container.

I guess you can then do OtherQE (otherwise our QE does not know what/how to test, I think), please? (evaluating possible candidate to 7.8)
Comment 11 Pavel Moravec 2019-08-27 10:12:38 UTC 
Jake,
could you pls. verify also this?

A yum repository for the build of sos-3.8-1.el7 (task 23200819) is available at:

http://brew-task-repos.usersys.redhat.com/repos/official/sos/3.8/1.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.8/1.el7/sos-3.8-1.el7.repo

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

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

Build output will be available for the next 21 days.
Comment 12 Jake Hunsaker 2019-09-10 13:28:12 UTC 
sos-03.8 works as expected for me on AH inside the support-tools container now.
Comment 15 errata-xmlrpc 2020-03-31 20:04:09 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, 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:1127
Note You need to log in before you can comment on or make changes to this bug.