> Gunnlaugur Thor Briem <gunnlaugur@...> writes: >> But with the fake callback, it doesn't segfault, but it doesn't respond >> to >> requests either > > More precisely: the application invocation succeeds and ny wsgi script > completes, after which uwsgi shows no reaction to incoming requests. > I attached gdb and found the stack looking like this: > > __psynch_cvwait () > _pthread_cond_wait () > PyThread_acquire_lock () > lock_import () > PyImport_ImportModuleLevel () > PyImport_Import () > PyImport_ImportModule () > uwsgi_python_reset_random_seed () at python_plugin.c:175 > uwsgi_python_post_fork () at python_plugin.c:204 > uwsgi_start (v_argv=0x104bcb7b0) at uwsgi.c:2652 > main (argc=<value temporarily unavailable, due to optimizations>, ... > > Process appears to hang while ... importing the "random" module? > > ... although I can't seem to repeat this experiment, because now when I > attach gdb I get: > > kevent(): Interrupted system call [event.c line 446] > waitpid(): No child processes [master.c line 789] > something horrible happened... > ...brutally killing workers... > > and the worker is dead. > > Not sure where to go from there :) > > uwsgi is working normally when I don't invoke application at init time. > > - Gulli >
Can you post your full uWSGI config ? I have seen this kind of setup only with simple master+preforking mode. Maybe some other option could break this. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
