Я экспериментирую с переносом проекта с веб-фреймворка Cherrypy на Pyramid. У меня небольшая часть конвертирована и обратите внимание, что Ctrl + C не остановит приложение Pyramid. Версия cookiecutter остановится с помощью Ctrl + C. В конечном итоге мне нужно убивать процесс каждый раз.
Я использую команду pserve, которая использует сервер WSGI официантки в обоих случаях...
pserve development.ini
Я также должен отметить: я запускаю Debian Stretch в виртуальной виртуальной машине.
Есть ли способ узнать, почему поведение изменилось или как восстановить выключение Ctrl + C? Как я мог знать, что теперь что-то блокирует это?
- Дополнительная информация, заданная в комментариях -
Использование 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())
Чтобы диагностировать, где я столкнулся с проблемами, я сделал следующие шаги, руководствуясь многими комментариями, сделанными по этому вопросу.
Я проверил процесс, чтобы убедиться, что сигналы действительно пойманы.
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 ранее, поэтому эта ошибка существовала в течение длительного времени, и некоторые работы по разработке Linux для проекта выявили ее.