Systemd – What is /var/lib/systemd/coredump and Can It Be Deleted?

core-dumpdisk-usagemanjarosystemd

I'm running Manjaro KDE and the /var/lib/systemd/coredump/ folder is around 500MB. What is it there for, and is it safe to delete it? sudo systemctl status shows running and no failed units.

Best Answer

/var/lib/systemd/coredump is where systemd-coredump stores core dumps. You can list them with coredumpctl.

If you don’t plan on investigating your core dumps any further, you can delete the contents of the directory.

Related Solutions

Why is the Systemd unit loaded, but inactive (dead)

Per jasonwryan's comment, while the default Type=simple works for many Systemd service files, it does not work when the script in ExecStart launches another process and completes, as is the case with graphite's carbon-cache.py. In these cases you need to explicitly specify Type=forking in the [Service] section so that Systemd knows to look at the spawned process rather than the initial one.

As explained in man systemd.service:

If set to forking, it is expected that the process configured with ExecStart= will call fork() as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main daemon process. This is the behavior of traditional UNIX daemons. If this setting is used, it is recommended to also use the PIDFile= option, so that systemd can identify the main process of the daemon. systemd will proceed with starting follow-up units as soon as the parent process exits.

Graphite-Specific Answer

While the above solved my Systemd issue, I quickly ran into graphite-specific issues (with Twisted) and ended up going back to the default Type.

Graphite < 0.9.12

In previous versions of Graphite one can only avoid forking by using the --debug option:

[Service]
ExecStart=/opt/graphite/bin/carbon-cache.py --debug start

Graphite >= 0.9.13

In this pull request a --no-daemon option was merged:

[Service]
ExecStart=/opt/graphite/bin/carbon-cache.py --no-daemon start

What Starts Units Generated by Systemd Generator – Systemd Guide

Generated unit files are not automatically activated by systemd. There's nothing special about them as far as systemd is concerned. Each individual generator has to explicitly create symbolic links that connect a generated unit to a target, so that activating the target activates the generated unit via a dependency in the normal way.

This takes advantage of the fact that not all connections between units are expressed inside the unit files. Wants and Requires dependencies can be expressed with symbolic link farms in *.wants/ and *.requires/ subdirectories. And those symbolic link farms encompass subdirectories of /run/systemd/ amongst other things.

In other words: Rather than write out a unit with WantedBy=local-fs.target and then have to explicitly invoke sytemctl enable to make the symbolic link (which is what enabling does), the generator short-circuits the process and makes the symbolic link itself. And it makes it in an ephemeral place, which systemctl enable normally would not, thereby preventing the symbolic link from continuing to exist after the next shutdown and confusing the next startup.

Specifically, you'll find on your system that /run/systemd/generator/boot.mount is symbolically linked from /run/systemd/generator/local-fs.target.wants/boot.mount. systemd-fstab-generator created this symbolic link, and it makes boot.mount wanted by local-fs.target. The generator is run early in the bootstrap before the system gets around to activating local-fs.target, which means that when it does get around to activating local-fs.target the generated dependency is there to be followed.