Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Thomas Bächler (brain0)
Dave Reisner (falconindy)
Tom Gundersen (tomegun)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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.
Comment by Daniel Micay (thestinger) - Saturday, 20 December 2014, 21:23 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.
Comment by John Lindgren (jlindgren) - Saturday, 20 December 2014, 21:24 GMT
Read the bug report completely, please. I did already have "Storage=none" and it still does heavy I/O.
Comment by Daniel Micay (thestinger) - Saturday, 20 December 2014, 21:25 GMT
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.
Comment by John Lindgren (jlindgren) - Saturday, 20 December 2014, 21:26 GMT
If it's "arguably awful" then maybe it should be disabled by default for Arch Linux? That could be done in the packaging.

Loading...