I think this is too much for coredumps… Is any way to restrict this one on space and probably date permanently?
Yes - there is (and please - use text - copy paste the text - not images of text)
cat /etc/systemd/coredump.conf
1 Like
systemd-tmpfiles-clean.timer should be running by default, which would trigger a cleanup of these core dumps every 3 days 2 weeks.
And you can also clean manually
sudo rm -f /var/lib/systemd/coredump/*
Is it safe?
Yes, but maybe better is
systemctl start systemd-tmpfiles-clean.service
or
sudo systemd-tmpfiles --clean
2 Likes
A small correction: the (auto)cleaning service seems like having a default for cleaning the coredumps every 2 weeks and not 3 days
[teo@teo-lenovo-v15 ~]$ cat /usr/lib/tmpfiles.d/systemd.conf |grep coredump
d /var/lib/systemd/coredump 0755 root root 2w
…and to automate daily cleanup of temporary directories, enable the timer to trigger the service:
systemctl enable systemd-tmpfiles-clean.timer
I mentioned the timer above, and it should be enabled by default.
First response
Though it does seem I used dated wiki info, which was corrected above.
So you did. 
So if dumps stack up quite quickly I’ll have huge side of it …hm. 2 weeks quite long
I think the default limit was 4GB and it should not grow above that, but you can make it smaller in the config, or tell the cleaner to clean more often, or both. (see the posts above, in systemd.conf 2w is 2 weeks, you can make it 3d - 3 days for example; in coredump.conf it is the Maxusage= line)
systemctl cat systemd-tmpfiles-clean.timer
lists the timer - it looks like it runs daily
Do you need the coredumps stored at all?
(they are present until the next boot)
edit /etc/systemd/coredump.conf
and set Storage=none
or to Storage=journal
then you have them managed the same way you manage the size to which your journal is allowed to grow
man coredump.conf
1 Like
the timer as a whole yes, but you can configure the different folders and components to clean separately, and the coredumps are by default configured for 2 weeks. It is also logical that they survive a little longer, if one really needs them for debugging
that is a bad idea, in this particular case. He has managed to fill 4G of dumps in less than 2 weeks. So he has something very big that is crashing (the system components that occasionaly crash unnoticed in the background like file manager or perl or python are usually a couple of MB). Probably a game, or a VM, or CAD/Video editing, only smth like that produces gigabytes of dump from one crash. So it will fill his entire journal and leave less space for the journal stuff itself
I think that is the best advice so far for this particular case (i just did this to my config, thanks for the idea :))
hmm - I didn’t really look at all that
Thank you, I guess 
I just wanted to mention the possibilities and also found it unlikely that those coredumps will ever be being looked at (by him) - so: why have them stored at all
Of course that was my implicit speculation.
re the Storage=journal - this would work for me as well, because I configured the journal to not be kept across reboots as well, with:
Storage=volatile
in /etc/systemd/journald.conf
I have never had a need to look at old logs - but that may be seen differently by someone who is not just using the system as a desktop.
If the need should arise - I know how to turn the option back on …
In my current situation I regard it as a waste of space. 
Cheers!
1 Like