如何诊断为什么 Ctrl + C 不停止 pserve答案

【问题标题】：How to diagnose why Ctrl + C not stopping pserve如何诊断为什么 Ctrl + C 不停止 pserve
【发布时间】：2018-10-19 00:46:09
【问题描述】：

我正在尝试将一个项目从 Cherrypy 移植到 Pyramid Web 框架。我已经转换了一小部分，并注意到 Ctrl+C 不会停止 Pyramid 应用程序。 cookiecutter 版本将使用 Ctrl+C 停止。我最终每次都需要终止该进程。

我正在使用 pserve 命令提供服务，在这两种情况下都使用 waitress WSGI 服务器...

保留 development.ini

我还要注意：我在 VirtualBox VM 中运行 Debian Stretch。

有没有办法知道行为改变的原因或如何恢复 Ctrl+C 关机？我怎么知道现在是否有什么东西阻止了这种情况的发生？

-- cmets 中要求的附加信息--

使用 grep Sig /proc/process_id/status 会产生以下结果：

SigQ:   0/15735
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000001001000
SigCgt: 0000000180004002 hex/binary 110000000000000000100000000000010

使用 GDB 并获取 py-bt

    (gdb) py-bt
Traceback (most recent call first):
  <built-in method select of module object at remote 0x7f914f837e58>
  File "/usr/lib/python3.5/asyncore.py", line 144, in poll
    r, w, e = select.select(r, w, e, timeout)
  File "/usr/lib/python3.5/asyncore.py", line 203, in loop
    poll_fun(timeout, map)
  File "/home/clutton/programs/python/webapps_pyramid/env/lib/python3.5/site-packages/waitress/server.py", line 131, in run
    use_poll=self.adj.asyncore_use_poll,
  File "/home/clutton/programs/python/webapps_pyramid/env/lib/python3.5/site-packages/waitress/__init__.py", line 17, in serve
    server.run()
  File "/home/clutton/programs/python/webapps_pyramid/env/lib/python3.5/site-packages/waitress/__init__.py", line 20, in serve_paste
    serve(app, **kw)
  File "/home/clutton/programs/python/webapps_pyramid/env/lib/python3.5/site-packages/paste/deploy/util.py", line 55, in fix_call
    val = callable(*args, **kw)
  File "/home/clutton/programs/python/webapps_pyramid/env/lib/python3.5/site-packages/paste/deploy/loadwsgi.py", line 189, in server_wrapper
    **context.local_conf)
  File "/home/clutton/programs/python/webapps_pyramid/env/lib/python3.5/site-packages/pyramid/scripts/pserve.py", line 239, in run
    server(app)
  File "/home/clutton/programs/python/webapps_pyramid/env/lib/python3.5/site-packages/pyramid/scripts/pserve.py", line 32, in main
    return command.run()
  File "/home/clutton/programs/python/webapps_pyramid/env/bin/pserve", line 11, in <module>
    sys.exit(main())

【问题讨论】：

我不熟悉你正在处理的项目，但我知道有两种方法可以捕捉 Ctrl+C are outlined here。
谢谢你，但我真的更感兴趣的是如何知道是什么阻止了默认情况下似乎工作的东西，如何追踪它（也许是 GDB？）或如何知道它的原因放弃工作...
Ctrl+C 信号传递比一般信号更复杂，涉及终端和进程组。当您下次有机会终止该进程时，您可以尝试kill -2 processid 并让我们知道这是否有效？
您能否运行grep Sig /proc/processid/status 并查看每行中的最后一个十六进制数字，并告诉我们其中任何一个中的第二低位是否打开？这将显示 SIGINT 是否被捕获或忽略或其他原因。
好的，它表明该进程有一个用于 SIGINT 的信号处理程序。这个过程是你有源代码的吗？如果您不确定，请使用gdb 附加到它，并使用bt 进行回溯，看看是否有什么熟悉的地方。

标签： python signals pyramid

【解决方案1】：

为了诊断我遇到问题的地方，我在许多 cmets 的指导下采取了以下步骤。

我检查了该过程以确保信号确实被捕获。

grep Sig /proc/process_id/status

这会产生以下信息：

SigQ:   0/15735  
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000001001000
SigCgt: 0000000180004002 hex/binary 110000000000000000100000000000010

SigCgt 表示确实正在收听的信号，在上面转换为二进制的十六进制值表明（从右到左）信号 2 和 15 确实已绑定。

此时我们需要诊断为什么会有一个处理程序但它似乎不起作用。所以剩下的问题是处理程序是什么。为了找出答案，我使用了 Python 信号模块并添加了一些代码，我可以在调试器中看到它...

import signal
s = signal.getsignal(2)

一旦我这样做了，我发现处理程序从作为项目一部分的独立脚本中引用了一个函数。我正在覆盖默认的信号处理程序，以便在终止进程之前进行清理，但是......我也在这个拥有自己进程的项目的一部分中导入它。由于该项目通常是在 Windows 上开发的，我之前使用 Ctrl-C 时可能会处理不同的信号，所以这个 bug 已经存在很长时间了，为该项目做一些 Linux 开发工作才发现它。

【讨论】：