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

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

0 голосов
/ 16 октября 2018

Я экспериментирую с переносом проекта из Cherrypy в веб-фреймворк Pyramid.Я преобразовал небольшую часть и заметил, что Ctrl + C не остановит приложение Pyramid.Версия cookiecutter остановится нажатием Ctrl + C.В конечном итоге мне приходится каждый раз останавливать процесс.

Я работаю с помощью команды pserve, которая использует WSGI-сервер официантки в обоих случаях ...

pserve development.ini

Следует также отметить: я запускаю Debian Stretch на виртуальной машине VirtualBox.

Есть ли способ узнать, почему изменилось поведение или как восстановить выключение 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 Ответ

0 голосов
/ 18 октября 2018

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

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

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

...