8

I just noticed that most of my memory was hogged by coredump of a few processes that I had killed recently. I had a systemd-coredump process running for each crashed process (usually the processes were google-chrome, which I had force quit, which explains the large memory consumption).

What I would like to know is why instead of dumping the core of the crashed process to the disk, a new process that holds the entire core in the ram is being started.

Is my configuration buggy or is it supposed to be this way? If so how do I change the behavior?

For now I have disabled the storing of core dump by linking /dev/null to /etc/sysctl.d/coredump.conf, though I do not see core dumps, but still would like to keep it enabled. Any ideas/hints would be appreciated.

(The issue is also posted at: https://bbs.archlinux.org/viewtopic.php?pid=1246237)

Improve this question
2
  • More important might be why your Chrome is getting SIGSEGV (11). You may want to begin with running memtest86 and verifying your memory before solving this. man core will explain many of the options available for core dumps. Commented Jun 23, 2013 at 11:30
  • @bdowning Well in those days (when I asked the question) I would force kill chrome and other processes (which btw would be running quite fine). So I think this would create the core dump. Commented Jul 6, 2013 at 9:44

1 Answer 1

Reset to default
4

By default, core dumps are written to disk and should not be written to memory. See the core manual page for further information. You can find out, and change, the path and filename of the core file by looking at /proc/sys/kernel/core_pattern

You can simply disable core dumps by redirecting coredump.conf to null

$ sudo ln -s /dev/null /etc/sysctl.d/coredump.conf && /lib/systemd/systemd-sysctl

Another way to disable core dumps is by changing the settings in limits.conf

Improve this answer
2
  • I had disabled the core dumps when I found this was happening, using one of these ways (or both, do not remember now). What I am puzzled about is that, after a process would crash a new systemd-coredump process would start which would maintain the core dump in the memory (considering the amount of memory it took up). Now it can be argued that perhaps the process was swapped out to disk, but the issue is why the process exists. I mean why couldn't the core dump handling process just write the dump in a file and exit. Commented Jul 6, 2013 at 9:51
  • Note that the filename changed from coredump.conf to 50-coredump.conf now. See also the Arch Linux wiki for Systemd. Commented Aug 10, 2014 at 9:55

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.