Setting coredumpsize on a running process?

Jeremy Chadwick freebsd at
Tue Oct 18 14:43:16 UTC 2011

On Tue, Oct 18, 2011 at 04:32:11PM +0200, Ivan Voras wrote:
> I have PHP executing as fastcgi via the mod_fcgid module in Apache. I
> suspect there is a bug in PHP or one of its extensions which causes it
> to crash with sigsegv, but I cannot get any coredumps. I suspect
> something is setting coredumpsize to 0 - either Apache, mod_fcgid or PHP.
> So the question is: is there a way to set coredumpsize on a running
> process, with the intention of getting a core dump when it crashes? I
> already tried setting CoreDumpDirectory in Apache and also configuring
> apache22limits_args in /etc/rc.conf but without effect.

I ended up solving this on a machine where coredumps with Apache + PHP
were highly common by setting sysctl kern.corefile to
/var/cores/%P.%N.core, then made sure the /var/cores directory was
root:wheel, perms 1777.  Otherwise I could not get a coredump.
apache22limits_enable did not help either, nor did CoreDumpDirectory.
Here's an example from that box:

$ ls -ld /var/cores /var/cores/*
drwxrwxrwt    2 root      wheel          512 Oct  1 00:00 /var/cores/
-rw-------    1 root      wheel     14360576 Oct  1 00:00 /var/cores/53964.httpd.core

I imagine the issue might have to do with some cores being written by
the UID/GID which crashed (in your case, could be 80:80), which I assume
means the UID/GID needs to have write access to whatever it's cwd is at
the time of the crash.  Hence why setting kern.corefile to a static path
where the dir is 1777 (globally writeable + sticky bit) works around
that.  Just be aware that if anything else cores on the system it'll end
up there too.

Also be aware that to get even remotely useful data out of PHP and
Apache, you often have to rebuild everything with debugging enabled and
optimisations disabled.  That's semi-simple to do, but what may come as
a surprise is that the path to the PHP modules ends up having "-debug"
in it (I'm referring to /usr/local/lib/php/whatever), so you really do
have to rebuild not just PHP and Apache but all PHP modules too given
the path change.

Worse, certain modules like either eAccelerator or ZendOptimizer (I forget
which of the two) make the downright assumption that they are in use on
a PHP system where debugging is not enabled, thus do not behave quite
right when placed there.

Having fun yet?

| Jeremy Chadwick                                jdc at |
| Parodius Networking              |
| UNIX Systems Administrator                   Mountain View, CA, US |
| Making life hard for others since 1977.               PGP 4BD6C0CB |

More information about the freebsd-stable mailing list