44

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
2
  • 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. Commented Sep 5, 2020 at 13:57
  • You have already removed the heavy files, what remains is only a few lines of log in journal. The correct answer may be just not to delete them. They will be cleaned up on their own as the journal accumulates new logs. Commented Sep 12, 2024 at 6:00

6 Answers 6

Reset to default
10

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.

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? Commented May 20, 2022 at 13:44
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.

Improve this answer
4
  • 20
    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! Commented Dec 2, 2018 at 11:25
  • 1
    Who ever wanted to build up a library of core dumps in the first place? You fix the bug and forget, right? Commented 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. Commented Mar 27, 2021 at 18:36
  • 2
    @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. Commented Mar 31, 2021 at 6:50
9

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.

Therefore choose an appropriate timespan e.g. 1d, 1h, 1m, or even 1s to remove journal and coredumps, for example, if the most recent coredump was more than 1 hour ago, journalctl --rotate --vacuum-time=1h should do the job.

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 :-) Commented Oct 8, 2020 at 12:09
  • 1
    @Wieland Ah, yes. I thought the most upvoted one was... Commented Oct 8, 2020 at 22:37
5

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
1
  • 1
    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. Commented Feb 22, 2024 at 3:26
1

All the other answers are quite useful for actually deleting the coredumps on disk, but also note that you can clean up the coredump index/list as well:

# journalctl --rotate --vacuum-time=1s --unit=systemd-coredump

Since it is stored in the journal. Ref: https://unix.stackexchange.com/a/769895/768802

Improve this answer
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
Improve this answer
3
  • 24
    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! Commented Dec 2, 2018 at 11:24
  • @EnzoR actually an excellent sollution. Who needs those logs really? Commented Mar 22 at 16:37
  • Honestly I would prefer my core dumps and logs were under my control since boot with no default hijacking by systemd. Deleting all logs and dumps is never a GENERAL solution. Logs are rather tiny and easily compressible and yet useful for real world system managemet. Critical systems can keep also dumps upon request. The original question/problem was only about core dumps. Commented Mar 23 at 8:28

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.