没有办法钩入正在运行的python进程并获得合理的结果。如果进程锁定，我所做的是连接strace并试图弄清楚到底发生了什么。

不幸的是，strace通常是“修复”竞争条件的观察器，因此输出在那里也是无用的。

如果你需要用uWSGI来做这件事，它有内置的Python Tracebacker，这只是在配置中启用它的问题(编号附加在每个worker的名称上):

py-tracebacker=/var/run/uwsgi/pytrace

一旦你这样做了，你可以简单地通过连接到套接字打印反向跟踪:

uwsgi --connect-and-read /var/run/uwsgi/pytrace1

安装信号处理程序的建议很好，我经常使用它。例如，bzr默认安装一个SIGQUIT处理程序，调用pdb.set_trace()立即将您放入pdb提示符中。(参见bzrlib。进入模块的源代码以获取确切的细节。)使用pdb，您不仅可以获得当前堆栈跟踪(使用(w)here命令)，还可以检查变量等。

然而，有时我需要调试一个我没有预见到在其中安装信号处理程序的进程。在linux上，您可以将gdb附加到进程，并使用一些gdb宏获得python堆栈跟踪。将http://svn.python.org/projects/python/trunk/Misc/gdbinit放在~/中。gdbinit,然后:

附加gdb: gdb -p PID 获取python堆栈跟踪:pystack

不幸的是，它不是完全可靠的，但它在大多数时候都是有效的。参见https://wiki.python.org/moin/DebuggingWithGdb

最后，附加strace通常可以让您很好地了解进程正在做什么。

我不知道有什么类似于java对SIGQUIT的响应，所以您可能必须将其构建到应用程序中。也许您可以在另一个线程中创建一个服务器，以便在响应某种类型的消息时获得堆栈跟踪?

我正在寻找一段时间的解决方案来调试我的线程，我发现它在这里感谢haridsv。我使用稍微简化的版本，使用traceback.print_stack():

import sys, traceback, signal
import threading
import os

def dumpstacks(signal, frame):
  id2name = dict((th.ident, th.name) for th in threading.enumerate())
  for threadId, stack in sys._current_frames().items():
    print(id2name[threadId])
    traceback.print_stack(f=stack)

signal.signal(signal.SIGQUIT, dumpstacks)

os.killpg(os.getpgid(0), signal.SIGQUIT)

为了满足我的需要，我还按名称筛选线程。

我想对haridsv的回答加一个评论，但我缺乏这样做的声誉:

我们中的一些人仍然停留在2.6以上的Python版本(thread .ident需要)，所以我让代码在Python 2.5中工作(尽管没有显示线程名称):

import traceback
import sys
def dumpstacks(signal, frame):
    code = []
    for threadId, stack in sys._current_frames().items():
            code.append("\n# Thread: %d" % (threadId))
        for filename, lineno, name, line in traceback.extract_stack(stack):
            code.append('File: "%s", line %d, in %s' % (filename, lineno, name))
            if line:
                code.append("  %s" % (line.strip()))
    print "\n".join(code)

import signal
signal.signal(signal.SIGQUIT, dumpstacks)