39

I'm looking for a way to remove any trace of old coredumps in coredumpctl list. At the moment it lists coredumps beginning at 2014-12-14 - I've updated software so often between then and now that I doubt those old coredumps are going to help me debug any problems now. Unfortunately removing the files from /var/lib/systemd/coredump only made the asterisk in the "PRESENT" column of coredumpctls output disappear.

I couldn't find any way to remove all information about coredumps in the manpages or in the help output of coredumpctl.

Wieland
  • 6,489
  • There is no such capability yet (and just deleting the dumps is technically not the right way either). So, for as much as the other "solutions" don't even seem to address the issue directly, this is the best atm. – mirh Sep 05 '20 at 13:57

5 Answers5

9

First you may prune the journal discarding entries older than a day:

journalctl --vacuum-time=1d

Since "coredumpctl list" lists the dumpfiles recorded by the journal, you may manually delete the dump files from /var/lib/systemd/coredump that are not listed.

coredumpctl list

Browse the dump files, compare the files with the results from the command and delete the files not listed.

megalith
  • 131
  • 16
    It's not a solution. It's not even a workaround. It's an action that deletes a lot of the logged stuff in the attempt to delete the dumps. Also not good! – EnzoR Dec 02 '18 at 11:25
  • Who ever wanted to build up a library of core dumps in the first place? You fix the bug and forget, right? – Adrian May Jul 20 '19 at 08:18
  • @EnzoR You've commented twice that deleting the journal logs is a bad idea. Why do you insist on this? They're taking 3 GiB on my 18GiB system, and I usually would only look at the logs every once in a while, usually if something is working poorly, and then rinse once I've fixed whatever was broken. – mazunki Mar 27 '21 at 18:36
  • 1
    @mazunki Deleting logs is always a bad idea, unless it's a non-production system. I presume you fixed your stuff thanks also to the logs. What if the logs were not there anymore? While I can understand that removing core dumps can make some sense, removing everything altogether is a radical approach. Of course, there is little technical contents in my suggestion as it sounds more like a philosophical thing. I would considetr a better approach to logging and disk sizing. – EnzoR Mar 31 '21 at 06:50
7

journalctl ONLY archives journal files, it does not include coredump files, unless specifically set Storage=journal. So the accepted answer is NOT correct (missing conditions).

e.g. journalctl --vacuum-time=7d keeps no older than 7 days' worth of journal.

The closest I can find is the coredump.conf file, use MaxUse to enforce disk space taken by externally (default Storage=external) stored core dumps, defaults to /var/lib/systemd/coredump.

check kernel.core_pattern

cat /proc/sys/kernel/core_pattern
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h

RTFM

Terry Wang
  • 631
6

This recipe works for me (Fedora 37). In short, it's important first to detach the current systemd journal files replacing them with newly created ones:

sudo journalctl --rotate

and then make a cleanup:

sudo journalctl --vacuum-time=1d

After that:

> coredumpctl list
No coredumps found.
BeastOfCaerbannog
  • 184
algo99
  • 61
  • You might want to check that /var/lib/systemd/coredump is empty, as larger coredumps are stored there and referenced from the journal. Vacuuming the journal only removes the reference. One way to approach this problem if you want to leave the journal intact is to create /etc/systemd/coredump.conf.d/99-local.conf with Storage=external and then delete coredumps from /var/lib/systemd/coredump. This leaves dangling references in the journal, but removes the bulk of the disk space used. – vk5tu Feb 22 '24 at 03:26
5

It looks like the correct answer is easier than expected.

In order to cleanup all dumped core stored by systemd-coredump you can run (as root):

systemd-tmpfiles --clean

You will still get the list of dumped cores with:

coredumpctl

but the dumped cores will be actually gone and the output will tell you that they are missing. Please, refer to the relevant man pages to get more details.

In case you want to completely disable this systemd feature altogether, you can do it via systemctl (as root):

systemctl disable systemd-coredump.socket
systemctl stop systemd-coredump.socket
systemctl status systemd-coredump.socket
systemctl disable systemd-coredump.socket

Be warned that this move won't survive the reboot: systemd will re-enable it at reboot!

To actually make this happen you have to "shadow" that systemd module. Which in turn translates into:

sudo ln -fs /dev/null /etc/sysctl.d/50-coredump.conf

Keep in mind that, at least on my Arch Linux box, my /proc/sys/kernel/core_pattern reads |/bin/false which completely avoids any core dumping by piping the core dump through the /bin/false binary (which does nothing at all).

Please check the relevant man page and your distribution documentation for more details.

EnzoR
  • 933
  • That looks like it is nearly the answer I've searched for (there seems to be no answer for the OP). Shouldn't --prefix or similar be given to system-tmpfiles to only remove the coredumps? – Simon Sobisch May 20 '22 at 13:44
0

It seems the metadata is kept in the systemd journal, so it is gone after

rm /var/log/journal/*/*
killall -9 systemd-journald

The downside is that all other syslog is gone as well.

Maybe the cleaner method would be the one given in How to clear journalctl

journalctl --vacuum-time=2d
Bernhard M.
  • 198
  • 1
  • 6
  • 21
    It's not a solution. It's not even a workaround. It's an action that deletes all the logged stuff as well as the dumps. Not good! – EnzoR Dec 02 '18 at 11:24