I have seen several questions regarding this, and must have tried nearly everything, but still, Apache won't create a core dump on the production server.

This is the setup that actually works on my VM:

apt-get install gdb apache2-dbg php5-dbg libapr1-dbg libaprutil1-dbg

mkdir /tmp/apache-coredumps
chmod g+w,o+w /tmp/apache-coredumps/

cat <<EOF > /etc/apache2/conf.d/debugging
CoreDumpDirectory /tmp/apache-coredumps

ulimit -c unlimited
apache2ctl -t && service apache2 restart

On the VM, with "kill -11 " I can see "possible coredump in /tmp/apache-coredumps" in the logfile, but this part is missing on the production server.

This is what I also tried:

Server and VM both are Debian Wheezy running Apache 2.2.22 (mpm-prefork), PHP 5.4.45.

What else might be blocking the creation of a core dump?

  • What is your production server? Bare metal? Some sort of virtualised system? What sort?
    – mc0e
    Mar 17, 2016 at 17:20
  • It's a physical system. What other info might be helpful?
    – Larsen
    Mar 18, 2016 at 17:14
  • Haven't found a solution so far, but ain't gonna check further as we found APC to be responsible (when deactivated, there didn't occur any segfaults on logrotation).
    – Larsen
    Apr 8, 2016 at 8:32

2 Answers 2


Hope this helps someone.

Note that if you have PrivateTmp=true set in your /usr/lib/systemd/system/apache2.service (or whatever it's called on your system), meaning Apache actually looks for /tmp inside something like /tmp/systemd-private-c27fc5b152d546159d675e170641529b-apache2.service-IcEt0m/, Apache won't be able to write to that dir and you won't get cores dumped at all (due to the systemd tmp directory having 700 root-only perms).

The solution is to either set PrivateTmp=false or modify the permission of the systemd tmp directory after the server starts.

I wasted hours on this to only just now finally realize what the problem was.

  • Can't verify this as we don't have an appropriate server running Debian Wheezy anymore, but thanks. In case someone else can verify, please comment so I can accept this as a solution.
    – Larsen
    Mar 9, 2020 at 15:24

man core has a list you should go over. The first one looks likely, since /var/cache/apache2 is typically only writeable by root, as is /var/www, which is the www-data user's usual home directory on debian:

   There are various circumstances in which a core dump file is  not  pro-

   *  The  process  does  not have permission to write the core file.  (By
      default the core file is called core, and is created in the  current
      working  directory.   See below for details on naming.)  Writing the
      core file will fail if the directory in which it is to be created is
      nonwritable,  or  if  a  file  with  the same name exists and is not
      writable or is not a regular file (e.g., it is a directory or a sym-
      bolic link).
  • But the directory in "/tmp" is writeable for everyone, so this shouldn't be the problem. Also, there is no indication in the log message, that Apache even tries to write a core dump. Will have a look at the man page, though.
    – Larsen
    Mar 14, 2016 at 16:40
  • Maybe so, so long as you didn't simultaneously set CoreDumpDirectory /var/cache/apache2 as you describe. Given that there are a few ways to set the directory, and that the per process setting overrides the generic one, I'd be inclined to use the CoreDumpDirectory directive to point to somewhere writable.
    – mc0e
    Mar 16, 2016 at 3:53
  • Have a look at my post again: "/var/cache/apache2" was only used as a test. "/tmp/apache-coredumps" was set before and this is writable.
    – Larsen
    Mar 16, 2016 at 13:06
  • Checked man core but didn't come to a solution. I am still wondering why the log message is missing the "possible coredump"...
    – Larsen
    Mar 16, 2016 at 13:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.