Red Hat Bugzilla – Bug 1368479
sosreport timeout does not allow for a full capture of foreman-debug output for Satellite 6 systems
Last modified: 2017-08-21 09:34:31 EDT
Description of problem: Running a sosreport will collect a 'foreman-debug' from a Satellite 6 based system, however this instance of foreman-debug will not be a complete capture, as sosreport has a timeout against modules that run in sosreport during the run. Version-Release number of selected component (if applicable): sos-3.2-35.el7_2.3.noarch How reproducible: 100% Steps to Reproduce: 1. Run 'sosreport' on Satellite 6 system. 2. Run 'foreman-debug' on Satellite 6 system. 3. Compare foreman-debug contents to sosreport at sosreport/sos_commands/foreman/foreman-debug* Actual results: foreman-debug that is included in sosreport is missing large swath of information compared to a plain 'foreman-debug' capture. Expected results: foreman-debug from sosreport should be allowed to complete and have identical information to normal foreman-debug. Additional info: This issue causes us to always have to request a sosreport & foreman-debug from every customer, and we are partially wasting time and duplicating information that customers even sometimes fight us on, as they know their sosreport captured one. This puts us in the position of explaining the reason for needing the separate capture. This applies to RHEL 6 && 7 sos.
How much time it takes to generate full f-d and full sosreport (that calls also f-d)? Does sosreport print it timeouted on some command? Can you attach some f-d and sosreport tarballs as example? FYI sosreport calls "foreman-debug -g" to skip collecting some generic information that sosreport collects by itself - that prevents collecting some info twice.
Decided to fix the generic "foreman-debug run takes longer than 5minutes timeout of sosreport" just by increasing the timeout to 15 minutes. Upstream PR: https://github.com/sosreport/sos/pull/888
POSTED to upstream. See also: https://github.com/Katello/katello-packaging/pull/329 where we aim to significantly improve the lengthest call of foreman-debug: task export.
For QE: in case deeper verification than "yes, the parameter is changed in code" is preferred from your side, I can help with either installing Satellite, mocking test, or preparing environment for a real test.
(In reply to Pavel Moravec from comment #5) > For QE: > > in case deeper verification than "yes, the parameter is changed in code" is > preferred from your side, I can help with either installing Satellite, > mocking test, or preparing environment for a real test. Hello, would you be able to verify the fix on a candidate RPM for RHEL7.4 (once available)? Our QE would appreciate it.
I can confirm the change in plugin source. If there is no positive feedback from the customer I will verify this SanityOnly. # diff -u old/BUILD/sos-3.3/sos/plugins/foreman.py /usr/lib/python2.7/site-packages/sos/plugins/foreman.py --- old/BUILD/sos-3.3/sos/plugins/foreman.py 2016-06-29 20:24:47.000000000 +0200 +++ /usr/lib/python2.7/site-packages/sos/plugins/foreman.py 2017-05-22 22:40:13.000000000 +0200 @@ -30,6 +30,6 @@ path = self.get_cmd_output_path(name="foreman-debug") self.add_cmd_output("%s -g -q -a -d %s" % (cmd, path), - chroot=self.tmp_in_sysroot()) + chroot=self.tmp_in_sysroot(), timeout=900) # vim: set et ts=4 sw=4 : # rpm -qf /usr/lib/python2.7/site-packages/sos/plugins/foreman.py sos-3.4-4.el7.noarch
Verifying Sanity Only (based just on code). See comment 12.
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/RHBA-2017:2203