У меня есть сервер Python, который должен выполняться средой с поддержкой Software Collections. В supervisord config файл выглядит примерно так:
[program:xxx]
command=/usr/bin/scl enable rh-python35 -- /myenv/bin/python server.py
stdout_logfile=/var/log/xxx.log
redirect_stderr=true
Программа запускается нормально, но supervisord думает, что scl процесс - это фактический процесс, но Сервер Python имеет другой PID. Когда приходит время SIGTERM (остановка, перезапуск и т. Д.), scl процесс завершается, но сервер Python продолжает работать.
я мог заставить мой сервер записать файл PID, а затем использовать pidproxy программа предоставлена supervisord, как описано здесь:
http://supervisord.org/subprocess.html#pidproxy-program
Затем, как описано, supervisord будет отправлять сигналы на правильный PID. Однако я бы предпочел, если это возможно, избегать изменения кода сервера для создания файла PID.
Обратите внимание, что прямое выполнение python исполняемый файл внутри коллекции программного обеспечения не работает:
[user@xxx gpsengine]$ /opt/rh/rh-python35/root/bin/python -V
/opt/rh/rh-python35/root/bin/python: error while loading shared libraries: libpython3.5m.so.rh-python35-1.0: cannot open shared object file: No such file or directory
Другие детали:
РЕДАКТИРОВАТЬ: существует дополнительный подход, кроме pidproxy который включает промежуточный сценарий оболочки. Эта запись в списке рассылки описывает enable сценарий (в отличие от scl enable команда):
https://www.redhat.com/archives/sclorg/2016-June/msg00008.html
Это можно использовать внутри сценария оболочки следующим образом:
exec 2>&1
test -f /opt/rh/rh-python35/enable && source /opt/rh/rh-python35/enable
exec /myenv/bin/python server.py
поскольку exec заменяет процесс оболочки, supervisord Затем конфигурация программы может указывать на этот сценарий оболочки как на команду.