4

I pretend I've already tried everything out there, but my Debian 8 keeps creating core dumps when something crashes. It's happening about once or twice in a month. It's a production server for a few websites, with packaged Apache 2.4, php5-fpm and mysql. I suspect it's php5-fpm crashing because I get the dump file in the DocumentRoot folder. The file I get is named "core" and it is somewhere in the order of gigabytes in size.

Here is what I've already done to disable core dumps, without success:

ln -s /dev/null /etc/systemd/coredump.conf

and then rebooted. No dice.

echo '*               hard    core    0' >> /etc/security/limits.conf
echo "fs.suid_dumpable = 0" >> /etc/sysctl.conf
sysctl -p

and then rebooted. Still no dice. I've NOT set kernel.suid_dumpable to 0, because I found it later but when I found it I also read that zero is its default. These settings should not make any difference anyway, because php5-fpm is not setuid. The same goes for Apache and mysql, just in case it's not php5-fpm crashing.

For the time being there is a script that looks for core dumps and deletes them. Crontab does the rest, but it is not the best solution.

How do I globally and unconditionally disable core dumps in Debian 8?

Lucio Crusca
  • 420
  • 3
  • 12
  • 33

2 Answers2

4

After Michael Hampton's comment to the Froggiz' answer, I noticed that Debian seems to lack a coredump.conf manpage, so I've looked for it on the internet and found it. That manpage contains a lot of useful informations and I wonder why Debian ships without it (maybe Debian is shipping without the whole systemd-coredump thing?).

However from that manpage and the systemd-coredump manpage it seems that the core files I get do not come from systemd, because systemd puts them in /var/lib/systemd/coredump or in the journal depending on the Storage option, but never in the working directory of the crashed process. Moreover the systemd-coredump manpage (also missing in Debian) says that for the core dump functionality to work, you need to configure the kernel.core_pattern sysctl parameter to make the kernel actually hand the core dump to systemd-coredump.

I've then looked at Debian value for kernel.core_pattern: Debian comes with that parameter set to "core" by default, which happens to be exactly the name of the core dump files I get.

I now suppose that setting 

kernel.core_pattern=|/bin/true

(or /bin/false for that matter) in sysctl.conf as per the core(5) manpage will solve the problem.

I'm going to evetually accept my answer in a few weeks if I notice the server stops creating core files. I'm sorry I can't accept Michael's comment as answer, but many thanks to him for pointing me in what I believe is the right direction.

EDIT: I've found here a way to test the configuration without having to wait for a spontaneous crash and I confirm this is the correct answer.

Lucio Crusca
  • 420
  • 3
  • 12
  • 33
  • 1
    Debian is kind of a bizarre distribution. They make strange and usually ill-considered changes to upstream packages all over the place. I can't recommend using it, or anything derived from it. – Michael Hampton Nov 19 '15 at 18:04
  • Points of view. I like it a lot, though I admit it is sometimes cryptic to understand. – Lucio Crusca Nov 19 '15 at 18:22
  • 1
    This is not really a point of view. It's _important_. When a package doesn't behave as expected because the distribution changed how it behaves, you have a recipe for frustration at the very least. – Michael Hampton Nov 19 '15 at 18:32
  • There actually isn't any custom behavior here. It's just a default kernel configuration. The Debian systemd does behave as expected and so does the Debian kernel. It seems Debian does not use systemd-coredump at all, and I can only support such a choice, because a quick "systemd-coredump" google search brings up mostly people trying to disable it. – Lucio Crusca Nov 19 '15 at 18:40
  • `systemd-coredump` is shipped in a different package that is not installed by default – Bigon May 29 '20 at 09:25
  • @Bigon that was not the case in Debian 8 (Jessie), which is what my question targets – Lucio Crusca May 29 '20 at 10:37
  • For what I can see, it was not even enabled in the version released in debian 8 (215-17). According to the change log it was disabled in version 43-1 and re-enabled (and put in a different package) in 227-3, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744964 – Bigon May 29 '20 at 12:51
2

You can try this : https://wiki.archlinux.org/index.php/Systemd#Disabling_application_crash_dumps_journaling

Disabling application crash dumps journaling Edit the file /etc/systemd/coredump.conf by adding this line: Storage=none

and run: systemctl daemon-reload to reload the configuration.

Froggiz
  • 3,043
  • 1
  • 19
  • 30
  • How is that supposed to work, since I've already overridden any default coredump.conf with a symlink to /dev/null? I ask because each thing I try takes quite some time to test, so I prefer trying things only if I know they make sense. – Lucio Crusca Nov 19 '15 at 09:17
  • 3
    @LucioCrusca Because getting rid of the file does not stop core dumps. The file's absence only tells systemd to use its built-in defaults (which _do_ generate core dumps). This was documented in the `coredump.conf` man page. – Michael Hampton Nov 19 '15 at 12:24