Multi app setup and segfault

qur2 commented 11 years ago

Here is a toy setup that brought me to a segfault. I probably do something wrong, but I was asked on twitter to report this so here is the story:

I'm trying to run django instances in a multiapp setup, in order to not have to decide how many workers per instance (is that a correct assumption?). I followed the tutorial at https://uwsgi-docs.readthedocs.org/en/latest/Python.html?highlight=applications but this just didn't work, because there is no such a uwsgi python module (I did installed it using pip). So I did things my way, with my current understanding of how it works:

master.py:

application = {
  '': 'django1.django1.wsgi.application',
  '/django2': 'django2.django2.wsgi.application',
  '/django3': 'django3.django3.wsgi.application',
}

And here comes the segfault:

uwsgi --pp=~/.virtualenvs/multi-django/lib/python2.7/site-packages/ --pp=. -s 127.0.0.1:3030 --master --module=master
*** Starting uWSGI 1.9.18.1 (64bit) on [Thu Oct 17 11:03:21 2013] ***
compiled with version: 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) on 16 October 2013 17:45:16
os: Darwin-11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64
nodename: danode
machine: x86_64
clock source: unix
detected number of CPU cores: 4
current working directory: /Users/daboy/src/multi-django
detected binary path: /Users/daboy/.virtualenvs/multi-django/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
your processes number limit is 709
your memory page size is 4096 bytes
detected max file descriptor number: 2560
lock engine: OSX spinlocks
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to TCP address 127.0.0.1:3030 fd 3
Python version: 2.7.5 (default, Jun  3 2013, 13:05:43)  [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x7fe393c0ba60
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 145568 bytes (142 KB) for 1 cores
*** Operational MODE: single process ***
added ~/.virtualenvs/multi-django/lib/python2.7/site-packages/ to pythonpath.
added ./ to pythonpath.
found a multiapp module...
!!! uWSGI process 42635 got Segmentation Fault !!!
*** backtrace of 42635 ***
0   uwsgi                               0x0000000104da2e42 uwsgi_backtrace + 50
1   uwsgi                               0x0000000104da2901 uwsgi_segfault + 49
2   libsystem_c.dylib                   0x00007fff8361acfa _sigtramp + 26
3   ???                                 0x7300000100000073 0x0 + 8286623318656680051
4   uwsgi                               0x0000000104dad66f uwsgi_python_init_apps + 655
5   uwsgi                               0x0000000104d9cdc3 uwsgi_init_all_apps + 211
6   uwsgi                               0x0000000104d9f774 uwsgi_start + 4612
7   uwsgi                               0x0000000104da27ef main + 9919
8   uwsgi                               0x0000000104d5e3e4 start + 52
9   ???                                 0x0000000000000007 0x0 + 7
*** end of backtrace ***

unbit commented 11 years ago

the segfault has just been fixed: https://github.com/unbit/uwsgi/commit/f462792c8ef5aca0f6149e7e89d87f354cff9670

it now correctly reports 'broken apps'

By the way:

using strings for the callable lead to errors (as in your case), while using modules is safer (the python vm will report specific problems)

the 'uwsgi' module exists only into the uWSGI environment, so you cannot make 'import uwsgi' from a python shell.

be sire to understand how PYTHONPATH works, multiple interpreters are hard to master, expecially with django that makes use of environment variables (DJANGO_SETTINGS_MODULE)

This kind of approach is pretty old-fashioned, having different instances controlled by the Emperor is the blessed way. Regarding the scaling of processes you have the --cheaper option to have a dynamic number of workers (based on the load)

For example:

--processes 20 --cheaper 2

will start 2 processes and will "gently" raise upto 20 based on load

qur2 commented 11 years ago

Thanks a lot for the quick fix and the explanation. I'll definitely have a look to emperor. I have to deal with a pretty awkward django project and I'm trying to find ways to make dev lives easier.

unbit / uwsgi-docs

Multi app setup and segfault #98