Date: Tue, 18 Oct 2011 07:43:12 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-stable@freebsd.org Subject: Re: Setting coredumpsize on a running process? Message-ID: <20111018144312.GA17496@icarus.home.lan> In-Reply-To: <j7k2lb$k85$1@dough.gmane.org> References: <j7k2lb$k85$1@dough.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111018144312.GA17496>