1

Hi I am getting following following message on trying to load my web page deployed through apache

"Truncated or oversized response headers received from daemon process"

and in apache log

[info] mod_wsgi (pid=16368): Initializing Python.
[info] mod_wsgi (pid=16368): Process 'esapp' has died, deregister and restart it.
[info] mod_wsgi (pid=16368): Process 'esapp' terminated by signal 1
[info] mod_wsgi (pid=16368): Process 'esapp' has been deregistered and will no longer be monitored.

I am using ctypes of module to load cpp library in setting file of django project like this

VELEC_API_LIB = ctypes.cdll.LoadLibrary('/var/www/eswebsite/libvelec.so')

If I stop loading my cpp .so library and restart apache it runs fine and I am able to load web pages. But when I try to load my .so library the above mentioned error comes every time.

I want to load my .so library as it is part of my project on c-side.

any help will be appreciated??

mnille
  • 1,328
  • 4
  • 16
  • 20
Mahesh Chaurasia
  • 133
  • 1
  • 1
  • 10

1 Answers1

0

The process is crashing when you load your extension.

Try setting directive in Apache config of:

WSGIApplicationGroup {GLOBAL}

This forces use of main Python interpreter context which can help with extension modules which aren't implemented correctly to work in sub interpreters.

If that doesn't help the issue may be that extension module needs a shared library but it isn't being linked in properly and so crashes when trying to call it.

Graham Dumpleton
  • 57,726
  • 6
  • 119
  • 134
  • Hi Graham I am still getting that message. I applied your suggestion but that didn't work. Any work around?? – Mahesh Chaurasia Jul 31 '16 at 14:51
  • What do you get if you run ``ldd /var/www/eswebsite/libvelec.so``? Ensure that when you run this that the ``LD_LIBRARY_PATH`` environment variable is not set. – Graham Dumpleton Jul 31 '16 at 21:21
  • gettig following--- linux-vdso.so.1 => (0x00007fff0e1ff000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fafb4df1000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fafb49d3000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fafb47b6000) libz.so.1 => /lib64/libz.so.1 (0x00007fafb459f000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fafb4299000) libm.so.6 => /lib64/libm.so.6 (0x00007fafb4015000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fafb3dfe000) libc.so.6 => /lib64/libc.so.6 (0x00007fafb3a6a000) /lib64/ld-linux-x86-64.so.2 (0x0000003e21600000) – Mahesh Chaurasia Aug 01 '16 at 06:03
  • Nothing obvious in the way of unresolved libraries or libraries that may cause conflicts. Can only suggest you ensure you are using daemon mode of mod_wsgi and then use steps outlined in http://modwsgi.readthedocs.io/en/develop/user-guides/debugging-techniques.html#debugging-crashes-with-gdb to capture a stack trace of where it core dumps when you trigger the code using a web request. That is, don't load at global scope, defer it until web request done so can better capture it. – Graham Dumpleton Aug 01 '16 at 07:10
  • I am running in daemon mode. following message come during gdb (gdb) c Continuing. Detaching after fork from child process 6473. [Thread 0x7fd4e591d700 (LWP 31661) exited] [Thread 0x7fd4e6d1f700 (LWP 31659) exited] [Thread 0x7fd4e631e700 (LWP 31660) exited] Program exited with code 01. – Mahesh Chaurasia Aug 01 '16 at 07:29
  • You should see a lot more information than that if doing it correctly. Looks like you may be attaching to the wrong process. Next time use gist.github.com to post a more complete trace for all threads if can get it, if you can't edit your original question and add it. – Graham Dumpleton Aug 01 '16 at 07:49
  • I quick checked that apache is not working with small size .so library. I tested just by making simple cpp program which opens a file and and writes few line and close it. when I loaded that .so apache still receives Signal 1. python development server is working fine. tomorrow I will give you stacktrace of threads on gist.github.com – Mahesh Chaurasia Aug 02 '16 at 17:20