Я нашел первопричину.
При повторном -подключении экрана сигнал SIGWINCH был отправлен родительскому процессу django. Процесс не справляется с этим и просто падает, оставляя ребенка сиротой.
Затем его можно легко перезапустить, изменив размер термина или используя kill -28 PID
.
Я не уверен, почему это происходит только в экземплярах GCP, может быть что-то другое в версии среды (python? ), во всяком случае, это дает мне больше подсказок о том, где найти решение.
Редактировать:
После недолгих поисков основная причина заключалась в том, что одна из наших зависимостей django импортировала readline
в свой исходный код.
Строка чтения в python является привязкой к библиотеке gnureadline
, и похоже, что обработка сигналов в gnureadline
мешает обработке сигналов в python/django.
Учитывая, что это происходит только на машине GCP, но не на наших предыдущих машинах, я подозреваю, что gnureadline, установленный на нашей машине GCP, отличается (либо с точки зрения версии, либо с точки зрения используемых параметров компиляции ), что приводит к другому поведению при обработке сигналов.
Полагаю, вы ищете grep с несколькими шаблонами.
grep 'pattern1\|pattern2' logfile
ИЛИ
grep -E 'pattern1|pattern2' logfile
Количество паттернов может быть любым. Он напечатает строки, соответствующие pattern1
ИЛИ pattern2
.