Unable to acquire core dump from mod_wsgi daemon process

[GoogleCodeExporter]

I've been experiencing spurious segmentation faults in my mod_wsgi application 
and tried to figure out how to acquire a core dump from a crashed mod_wsgi 
daemon process. Despite all my efforts, I couldn't make it work.

My WSGI configuration looks like:

WSGIDaemonProcess myapp processes=4 threads=1 display-name=%{GROUP}
WSGIProcessGroup myapp
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias /       /home/myapp/myapp/myapp.wsgi

Also I've configured:

apache2.conf: "CoreDumpDirectory /var/tmp"
sysctl.conf: "kernel.core_pattern = /var/tmp/core.%p.sig%s.%ts" (and yes I ran 
sysctl -p afterwards)
/etc/default/apache2: "ulimit -c unlimited" (this file is executed from the 
Apache init script)
/etc/security/limits.conf: "* hard core unlimited"

When I 'kill -SEGV' an Apache worker process, I successfully get a core file in 
/var/tmp. However, that does not work with a mod_wsgi daemon process.

This is on x86_64, Ubuntu 10.10 with Apache 2.2.16, mod_wsgi 3.2, Python 2.6.6

Why, oh why, does mod_wsgi make my debugging efforts so difficult?

Original issue reported on code.google.com by ma...@juffo.org on 30 Sep 2011 at 10:55

[GoogleCodeExporter]

I'm getting nothing but segmentation faults. I think the trick to getting the 
core dump is to remember that your running a daemon, so it's not the httpd 
process owned by apache but some other process - hence the ulimit in the apache 
init script is irrelevant. I got core dumps by setting ulimit in the global 
profile (/etc/profile on my redhat system). 

Original comment by another....@gmail.com on 20 Mar 2012 at 3:00

[GoogleCodeExporter]

> remember that your running a daemon, so it's not the httpd process owned by 
apache
> but some other process - hence the ulimit in the apache init script is 
irrelevant

Limits are inherited by child processes and I don't see why Apache or mod_wsgi 
would need to override them. In fact, they *aren't* changed in the wsgi process:

# cat /proc/5118/limits |grep core
Max core file size        unlimited            unlimited            bytes     

Yet no core files appear anywhere.

> I got core dumps by setting ulimit in the global profile (/etc/profile on my
> redhat system).

Well I tried this, still no help. AFAICT this works out to the same effect as 
setting it in limits.conf

Original comment by ma...@juffo.org on 20 Mar 2012 at 3:35

[GoogleCodeExporter]

Hmm, here's another report of this problem: 
http://stackoverflow.com/questions/5833218/coredumpdirectory-isnt-working-on-ubu
ntu-getting-segmentation-fault-in-apache2

Maybe this is an Ubuntu/Debian problem...

Original comment by ma...@juffo.org on 20 Mar 2012 at 3:42

[GoogleCodeExporter]

Ok, further digging led me to a comment in Apache docs saying "If Apache starts 
as root and switches to another user, the Linux kernel disables core dumps even 
if the directory is writable for the process"

So I read the core(5) man page and it turns out I have to set sysctl 
'fs.suid_dumpable=2', which finally gave me the core file! So turns out this is 
not a mod_wsgi bug, but an unexpected side-effect of Apache being launched as 
root and hot the way mod_wsgi starts its daemon processes.

Original comment by ma...@juffo.org on 20 Mar 2012 at 4:13

[GoogleCodeExporter]

Closing out old issue. Don't see any specific code change which is required.

Original comment by Graham.Dumpleton@gmail.com on 12 Nov 2014 at 10:33

• Changed state: WontFix

[GoogleCodeExporter]

Perhaps a documentation change, however?

Original comment by ma...@juffo.org on 12 Nov 2014 at 11:53