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?

Improve this question
3
  • What is your production server? Bare metal? Some sort of virtualised system? What sort? Commented Mar 17, 2016 at 17:20
  • It's a physical system. What other info might be helpful? Commented 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). Commented Apr 8, 2016 at 8:32

2 Answers 2

Reset to default
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.

Improve this answer
1
  • 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. Commented Mar 9, 2020 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).
Improve this answer
4
  • 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. Commented 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. Commented 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. Commented 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"... Commented Mar 16, 2016 at 13:16

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.