2

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
EOF

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?

Larsen
  • 305
  • 2
  • 14
  • What is your production server? Bare metal? Some sort of virtualised system? What sort? – mc0e Mar 17 '16 at 17:20
  • It's a physical system. What other info might be helpful? – Larsen Mar 18 '16 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 08 '16 at 08:32

2 Answers2

1

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.

Artem Russakovskii
  • 973
  • 3
  • 11
  • 25
  • 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 09 '20 at 15:24
-1

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-
   duced:

   *  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).
mc0e
  • 5,786
  • 17
  • 31
  • 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 '16 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 '16 at 03: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 '16 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 '16 at 13:16