Как диагностировать, почему Ctrl + C не останавливает pserve

1

Я экспериментирую с переносом проекта с веб-фреймворка 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())
  • 1
    Я не знаком с проектами, с которыми вы работаете, но два способа, которыми я знаю, чтобы поймать Ctrl + C , описаны здесь .
  • 1
    Спасибо за это, но меня действительно больше интересует, как узнать, что блокирует что-то, что, по-видимому, работает по умолчанию, как отследить это (возможно, GDB?) Или как узнать, почему оно перестало работать ...
Показать ещё 11 комментариев
Теги:
signals
pyramid

1 ответ

1

Чтобы диагностировать, где я столкнулся с проблемами, я сделал следующие шаги, руководствуясь многими комментариями, сделанными по этому вопросу.

Я проверил процесс, чтобы убедиться, что сигналы действительно пойманы.

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 для проекта выявили ее.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню