38

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.

Improve this question
1
  • 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 5, 2020 at 13:57

5 Answers 5

Reset to default
8

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.

Improve this answer
4
  • 15
    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 2, 2018 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, 2019 at 8: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, 2021 at 18:36
  • @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, 2021 at 6:50
6

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

Improve this answer
2
  • > So the accepted answer is NOT correct. - that's why there is no accepted answer :-)
    – Wieland
    Oct 8, 2020 at 12:09
  • @Wieland Ah, yes. I thought the most upvoted one was...
    – Terry Wang
    Oct 8, 2020 at 22:37
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 ping 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.

Improve this answer
1
  • 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, 2022 at 13:44
4

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.
Improve this answer
0
1

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
Improve this answer
1
  • 19
    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 2, 2018 at 11:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .