FS#43177 - [systemd] systemd-coredump doing extreme amounts of I/O
Attached to Project:
Arch Linux
Opened by John Lindgren (jlindgren) - Saturday, 20 December 2014, 21:04 GMT
Last edited by Dave Reisner (falconindy) - Sunday, 21 December 2014, 04:33 GMT
Opened by John Lindgren (jlindgren) - Saturday, 20 December 2014, 21:04 GMT
Last edited by Dave Reisner (falconindy) - Sunday, 21 December 2014, 04:33 GMT
|
Details
Description:
Lately, I've been catching systemd-coredump doing extreme amounts of I/O (100 MB/s for several seconds, as shown by iotop) on my system, even though I have "Storage=none" in /etc/systemd/coredump.conf. No files are created in /var/lib/systemd/coredump, so I'm not sure what file is actually being written, maybe a temporary file somewhere? The I/O is certainly there, since the HDD activity light on the laptop lights up steady for several seconds. This is unacceptable, as it will eventually reduce the lifespan of the SSD that I'm using. Creating an empty /etc/sysctl.d/50-coredump.conf (thus bypassing systemd-coredump) is the only way I've found to fix the problem. Additional info: * package version(s) systemd 218-1 * config and/or log files etc. /etc/systemd/coredump.conf: [Coredump] Storage=none #Compress=yes #ProcessSizeMax=2G #ExternalSizeMax=2G #JournalSizeMax=767M #MaxUse= #KeepFree= Steps to reproduce: Easy to reproduce if you use MuseScore, since it crashes rather frequently. :( |
This task depends upon
Closed by Dave Reisner (falconindy)
Sunday, 21 December 2014, 04:33 GMT
Reason for closing: Not a bug
Additional comments about closing: Nothing to be fixed in Arch.
Sunday, 21 December 2014, 04:33 GMT
Reason for closing: Not a bug
Additional comments about closing: Nothing to be fixed in Arch.
Comment by
Daniel Micay (thestinger) -
Saturday, 20 December 2014, 21:23 GMT
Comment by
John Lindgren (jlindgren) -
Saturday, 20 December 2014, 21:24 GMT
Comment by
Daniel Micay (thestinger) -
Saturday, 20 December 2014, 21:25 GMT
Comment by
John Lindgren (jlindgren) -
Saturday, 20 December 2014, 21:26 GMT
If it's a very large process, I think that's expected. It will do
a bunch of work and then realize that it's over the limit and
won't store it. It may be "unacceptable" but it's how it's
designed so I don't think a bug report here is going to accomplish
much. You have the choice to set Storage=none or disable it
completely.
Read the bug report completely, please. I did already have
"Storage=none" and it still does heavy I/O.
I guess it reads the entire thing unconditionally then - it may
not have a choice to get the information it needs from the kernel.
I suggest filing performance bugs upstream, although I have a
feeling that the kernel API for this is *really* lacking for the
use case. I don't know what you expect the packager to do about it
though :P.
If it's "arguably awful" then maybe it should be disabled by
default for Arch Linux? That could be done in the packaging.