Hide Forgot
+++ This bug was initially created as a clone of Bug #1369122 +++ Description of problem: Version-Release number of selected component (if applicable): sos-3.2-36.el7ost.2.noarch (this is the version from the RHOS8 puddle). How reproducible: sosreport -o logs -v (output attached) 100% reproductible I can extract the log manually: [root@director tmp]# time bash -c 'journalctl --all --this-boot --no-pager > all' real 1m26.669s user 1m9.138s sys 0m13.246s [root@director tmp]# ls -lh all -rw-r--r--. 1 root root 1.4G Aug 22 09:00 all
reducing the size of the logs is enough to avoid the problem (journalctl --vacuum-size=200M)
Is this an sos problem (in which case, it's RHEL, not OSP). Or is this some default setting that we need to change?
This is an sos problem that impact RHOSP. Should I close it?
It's both, really: sos should handle commands that generate large amounts of output on stdout better (open RFE, quite a big job), and it would help if OSP had a default log rotation regimen that would mean sos users are not impacted by this in default configurations & with the default sos options. We added a new Plugin API method in 3.3, add_journal(), that gives plugin classes better control over what they are collecting - so far the openvswitch, openstack_sahara, docker, logs, and kubernetes plugins are using it. This allows plugins to override the default timeout, start/end time and other aspects of journal collection (although I don't think anyone's using those features, yet).