Hide Forgot
We tried to do this a number of years ago: at the time, CEE (then GSS), told us that many associates relied on the HTML report for quickly browsing a report and that disabling it by default was not acceptable. If that situation has now changed, we'd have no problem with changing the default but we do need to ensure that we have the buy-in of the wider support group before we can make any final decision.
Disabling HTML report is rather alleviating the problem than solving it - if one adds more block devices / paths, the plugin will timeout again. Is collection of all the paths necessary? For all the block devices? Shall not we rather stop collecting some of those (if we are certain they are out of interest for troubleshooting any problem)? And what particular paths are such numerous / causing the timeout problem? (anyway this reminds me similar https://bugzilla.redhat.com/show_bug.cgi?id=1683904 )
Anyway, someone in the poll had an interesting idea to use JSON reports (instead of plaintext and html ones) - I raised it as https://github.com/sosreport/sos/issues/1713
*** Bug 1727016 has been marked as a duplicate of this bug. ***
See the proposal in https://github.com/sosreport/sos/issues/1713 . Sosreport generates html report inefficiently when some plugin collects many files (many = tens or hundreds of thousands). Rather than disabling this feature, I would vote for improving the inefficiency. Within the above PR, I propose an implementation where HTML report (for a plugin with 100k files collected) is generated within fractions of a second - basically almost as fast as text report. I am preparing a test for 1M files collected one plugin, to see how my approach scales, but I dont expect any issues. Please share your concern about the approach OR about the way of implementation (there can be different subjective views about the reports content or formatting, and mine proposed might not be the best one).
FYI the upstream PR was merged and backported to RHEL7.8 candidate. If you want to test it, please use below repo (or download the package from brew): 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 13 days.
*** Bug 1784234 has been marked as a duplicate of this bug. ***
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
*** Bug 1754562 has been marked as a duplicate of this bug. ***