|
Graham Dumpleton
graham.dumpleton at gmail.com
Tue Jan 22 23:36:22 EST 2008
On 23/01/2008, Alec Matusis <matusis at yahoo.com> wrote: > > Hmmm, there should have been 39 other stack traces, one for each > > worker thread based on your Apache configuration. > > Looks like it has only one thread: Which almost suggests it was actually a fork of an Apache child process as that is possibly only way the other threads could have been killed off. This would sort of sit with idea that some code had tried to further fork and daemonise the process. This is the only thing that seems to fit at the moment. I can't find though any evidence of fork() being used direct in PIL code at least, but then the popen2 module uses fork() in Popen3 and Popen4 classes. Again, PIL, although it uses os.popen() doesn't use popen2 module. Also, that doesn't involved setsid(). The only place in standard Python modules that appears to use setsid() is pty.fork() and PIL doesn't use that. All I can suggest is you might in your loaded application dump out sys.modules and see if anything has imported pty module. Otherwise troll through all the Python code you know is used and see if anything for whatever reason uses fork(), setsid(), popen2 module, or pty.fork(). More nasty would be a C extension module doing forks and trying to do Python stuff in forked process but not doing necessary Python cleanup after the fork. Would have expected to see a C extension module stack frame in traceback if that was the case though. Anyway, running out of ideas. Graham > Orphaned sub process: > > # ps -mTp 3812 > PID SPID TTY TIME CMD > 3812 - ? 00:00:00 httpd > - 3812 - 00:00:00 - > > Normal sub-process: > > # ps -mTp 20205 > PID SPID TTY TIME CMD > 20205 - ? 00:00:10 httpd > - 20205 - 00:00:00 - > - 20207 - 00:00:00 - > - 20208 - 00:00:00 - > - 20209 - 00:00:00 - > - 20210 - 00:00:00 - > - 20211 - 00:00:00 - > - 20212 - 00:00:00 - > - 20213 - 00:00:00 - > - 20214 - 00:00:00 - > - 20215 - 00:00:00 - > - 20216 - 00:00:00 - > - 20217 - 00:00:00 - > - 20218 - 00:00:00 - > - 20219 - 00:00:00 - > - 20220 - 00:00:00 - > - 20221 - 00:00:00 - > - 20222 - 00:00:00 - > - 20223 - 00:00:00 - > - 20224 - 00:00:00 - > - 20225 - 00:00:00 - > - 20226 - 00:00:00 - > - 20227 - 00:00:00 - > - 20228 - 00:00:00 - > - 20229 - 00:00:00 - > - 20230 - 00:00:00 - > - 20231 - 00:00:00 - > - 20232 - 00:00:00 - > - 20233 - 00:00:00 - > - 20234 - 00:00:00 - > - 20235 - 00:00:00 - > - 20236 - 00:00:00 - > - 20237 - 00:00:00 - > - 20238 - 00:00:00 - > - 20239 - 00:00:00 - > - 20240 - 00:00:00 - > - 20241 - 00:00:00 - > - 20242 - 00:00:00 - > - 20243 - 00:00:00 - > - 20244 - 00:00:00 - > - 20245 - 00:00:00 - > - 20246 - 00:00:00 - > - 20247 - 00:00:00 - > > > > -----Original Message----- > > From: Graham Dumpleton [mailto:graham.dumpleton at gmail.com] > > Sent: Tuesday, January 22, 2008 7:00 PM > > To: Alec Matusis > > Cc: mod_python at modpython.org > > Subject: Re: [mod_python] remnant 'orphan' apache subprocesses > > > > On 23/01/2008, Alec Matusis <matusis at yahoo.com> wrote: > > > > (gdb) thread apply all bt > > > > > > Thread 1 (Thread 1111562592 (LWP 3812)): > > > #0 0x00002aaaab2c94df in sem_wait () from /lib64/tls/libpthread.so.0 > > > #1 0x00002aaaac204dcd in PyThread_acquire_lock (lock=0x5b7820, > > waitflag=1) > > > > Hmmm, there should have been 39 other stack traces, one for each > > worker thread based on your Apache configuration. > > > > Don't necessarily post them all, but you should look and see what is > > in frame #0 for all of them and see if there is anything odd such as > > one blocking in a call out to some external C library. If no such > > thing and they are all stuck on Python mutex locks, then must be > > internal deadlock. > > > > This still doesn't explain though how the process has been associated > > with PPID of 1, which would still only seem possible if something had > > tried to daemonise process. > > > > Graham > > > > Graham > >
|