Given you have been using mod_wsgi so long I assume you have tried the
trick of forcing the main interpreter using:
WSGIApplication %{GLOBAL}
I can't remember mongodb clients having sub interpreter issues.
Of interest is that this also came up today:
http://stackoverflow.com/questions/8424033/weirdness-with-mongoengine-referencefield
Have you perhaps also tried embedded mode.
The line:
write(5, "X"..., 1)
is likely part of the mod_wsgi 3.3 signal handler code. This is
specific to daemon mode.
The question is what is generating a SIGINT to the process to trigger
that in the first place.
The mod_wsgi code does send SIGINT's to itself, but messages would
have to imply that it is getting stuck in some sort of loop to be
continually sending them to itself. The only place I could see that
easily happening is if in the monitor thread, which is what handles
deadlock timeout etc. Not sure how it could go haywire though and
cause a rapid SIGINT loop. Worst case it should only generate a SIGINT
once a second and that only in a state where the main thread which is
waiting on reading off that fd=5 of socketpair was failing to read the
"X" and not exit the process. It would take something closing and
replacing fd=5 to really screw with that.
Setting:
LogLevel debug
and:
WSGIVerboseDebugging On
may provide some more information but not sure if will be helpful.
FWIW, latest Python 2.7 has screwed up ability to use fork() in sub
interpreters, but that would be totally unrelated as far as can tell.
Graham
On 8 December 2011 05:17, Michael P. Jung <[email protected]> wrote:
> I'm currently trying to deploy a Django application on a server with
> mod_wsgi 3.3 and python 2.7.2. The application itself runs fine with
> "manage.py runserver". As soon as running it via mod_python (with
> daemon processes) simple requests that do not utilize the database
> (django-mongodb with pymongo 2.0.1) work fine but anything else causes
> the daemon process to hang. I tried attaching "strace" and got the
> following output. I first attached strace and did then request the URL
> that did not work
>
> Process 4816 attached - interrupt to quit
> restart_syscall(<... resuming interrupted call ...>) = ?
> ERESTART_RESTARTBLOCK (To be restarted)
> --- SIGINT (Interrupt) @ 0 (0) ---
> write(5, "X"..., 1) = 1
> rt_sigreturn(0x1728d90) = -1 EINTR (Interrupted system
> call)
> poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
> mmap(NULL, 2101248, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|
> MAP_32BIT, -1, 0) = 0x41bc0000
> mprotect(0x41bc0000, 4096, PROT_NONE) = 0
> clone(child_stack=0x41dc0210, flags=CLONE_VM|CLONE_FS|CLONE_FILES|
> CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CL
> futex(0x172930c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x1729308,
> {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
> futex(0x1729234, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x1729230,
> {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
> futex(0x1729084, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x1729080,
> {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
> futex(0x428bd9e0, FUTEX_WAIT, 4828, NULL) = ? ERESTARTSYS (To be
> restarted)
> --- SIGINT (Interrupt) @ 0 (0) ---
> write(5, "X"..., 1) = 1
> rt_sigreturn(0x1728d90) = -1 EINTR (Interrupted system
> call)
> futex(0x428bd9e0, FUTEX_WAIT, 4828, NULL) = ? ERESTARTSYS (To be
> restarted)
> --- SIGINT (Interrupt) @ 0 (0) ---
> write(5, "X"..., 1) = 1
> rt_sigreturn(0x1728d90) = -1 EINTR (Interrupted system
> call)
> futex(0x428bd9e0, FUTEX_WAIT, 4828, NULL <unfinished ...>
> Process 4816 detached
>
>
> The SIGINT lines keeps repeating (reduced to two outputs) and neither
> the deadlock timeout nor anything else is able to kill the process.
> I've been running mod_wsgi for a long time now on other servers and
> never had such an issue so I'm completely baffled.
>
> I checked the PYTHONPATH when running the application with "manage.py
> runserver" and mod_wsgi and found no difference. All natives are
> compiled with the correct python version (otherwise manage.py
> runserver shouldn't work either). The same code runs fine on another
> box with Python 2.6 and the same mod_wsgi version and it works
> flawless there.
>
> I do not know if it's a problem of mod_wsgi+pymongo problem. I'm going
> to try pymongo without the C extension and will report back.
>
> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/modwsgi?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en.
