abrt project uses sosreport to collect system information after a crash is detected. We run it this way: sosreport --tmp-dir "$DUMP_DIR" --batch \ --only=anaconda --only=bootloader --only=devicemapper \ --only=filesys --only=hardware --only=kernel --only=libraries \ --only=memory --only=networking --only=nfsserver --only=pam \ --only=process --only=rpm -k rpm.rpmva=off --only=ssh \ --only=startup --only=yum --only=general --only=x11 \ >sosreport.log 2>&1 Sometimes sosreport generates insane amounts of data. For example, users report 17Gb of logs from libvirt. This makes sosreport run way too slow, overfills /tmp, etc... Need a way to tell sosreport to avoid doing that.
I wouldn't recommend hard-coding a list of modules to enable. It's not going to work well with future versions of sos as we will be renaming and consolidating many modules and should not be needed in the general case. For most log files collected there is already automatic size-limiting. We can extend this for other problem cases that we know about.
This should fix the libvirt log problem in the 2.2 branch: diff -up sos-2.2/sos/plugins/libvirt.py.orig sos-2.2/sos/plugins/libvirt.py --- sos-2.2/sos/plugins/libvirt.py.orig 2013-03-25 11:12:26.477129295 +0000 +++ sos-2.2/sos/plugins/libvirt.py 2013-03-25 11:12:54.658294568 +0000 @@ -18,4 +18,4 @@ class libvirt(sos.plugintools.PluginBase """ def setup(self): self.addCopySpec("/etc/libvirt/") - self.addCopySpec("/var/log/libvirt*") + self.addCopySpecLimit("/var/log/libvirt*", 15) Upstream will probably be slightly different but will achieve the same outcome.
I've filed bug 927351 to track the development of a D-Bus interface to sos - this is probably a better way for ABRT and other components to interact with sos in the future. Please add any missing requirements for ABRT's use to the list in that bug.
(In reply to comment #3) > Please add any missing requirements for ABRT's use to the list in that bug. I have no problems with running sosreport as a process as we do now.
(In reply to comment #1) > I wouldn't recommend hard-coding a list of modules to enable. It's not going > to work well with future versions of sos as we will be renaming and > consolidating many modules and should not be needed in the general case. What would you recommend to do? We need something like "run sosreport so that it collects potentially useful stuff without running for minutes and without creating a large (multi-megabyte) tarball". The point is that we aren't running it on the user's request ("Yes, I definitely want to collect sosreport data"), we are merely attempting to save one round-trip in customer<->support interaction. This sosreport run is a shot-in-the-dark thing. We want to avoid making it expensive in terms of run time or problem data upload size/duration.
> We need something like "run sosreport so that it collects potentially useful > stuff without running for minutes and without creating a large (multi-megabyte) > tarball". As I said, we consider it a bug if this happens and are more than happy to fix those situations when we are aware of them. The problem with hard-coding a list of modules is that you're trying to collect "potentially useful stuff" but you're limiting the set of stuff that's being collected. Sos is designed to collect a reasonable set of data with default options. Command line options are there to allow users to have more control over the data collected when they know what they want to collect. It's also fragile since as we change the set of modules or move data collection between them ABRT will require changes to avoid failing with "a non-existing plugin (foo) was specified in the command line". In our testing the typical runtime of a default sos invocation is 10-20s depending on system capability. I find it hard to believe that that is a problem in most cases and if there are cases where we deviate from this expectation we want to know about it so that we can fix it. Working around these problems downstream just papers over the cracks. The other reason we would like to move users like ABRT away from shelling out and toward a real interface is to avoid problems like bug 728127. This happens because ABRT removes sos's working files while the process is still running. We would prefer that cleanups like this are dealt with by sos itself so that we can ensure they are handled correctly and consistently.
btw, do you have some example problems (other than libvirt) or figures for how often you are seeing these very long running/large sosreport cases?
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
(In reply to Bryn M. Reeves from comment #7) > btw, do you have some example problems (other than libvirt) or figures for > how often you are seeing these very long running/large sosreport cases? I'm not in abrt team anymore. You need to ask somebody else. I'm clearing my "needinfo" flag...
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.