Неправильный PID: супервизорная программа с программным обеспечением Python

У меня есть сервер Python, который должен выполняться в среде с включенной коллекцией программного обеспечения. supervisord Конфигурационный файл выглядит примерно так:

[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

Затем, как описано, 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

Другие детали:

• Centos 7

РЕДАКТИРОВАТЬ: есть дополнительный подход, кроме 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 Затем программа config может указывать на этот сценарий оболочки в качестве команды.