PID errado: programa supervisord com um Python de coleções de software

Question

Eu tenho um servidor Python que deve ser executado por um ambiente habilitado para Coleções de software. O arquivo supervisord config é parecido com isto:

[program:xxx]
command=/usr/bin/scl enable rh-python35 -- /myenv/bin/python server.py
stdout_logfile=/var/log/xxx.log
redirect_stderr=true

O programa é iniciado corretamente, mas supervisord acha que o processo scl é o processo real, mas o servidor Python tem um PID diferente. Quando chegar a hora de SIGTERM (parar, reiniciar, etc.), o processo scl é finalizado, mas o servidor Python continua em execução.

Eu poderia fazer meu servidor gravar um arquivo PID e, em seguida, usar o programa pidproxy fornecido por supervisord , conforme descrito aqui:

link

Em seguida, conforme descrito, supervisord enviaria sinais para o PID correto. No entanto, eu preferiria, se possível, evitar alterar o código do servidor para criar um arquivo PID.

Pergunta: Existe alguma outra maneira de configurá-lo?

Observe que a execução direta do executável python dentro da coleção de software não funciona:

[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

Outros detalhes:

• Centos 7

EDIT: Existe uma abordagem adicional além de pidproxy , que envolve um shell script intermediário. Esta entrada da lista de discussão descreve um enable script (em oposição ao comando scl enable ):

link

Isso pode ser usado dentro de um script de shell da seguinte forma:

exec 2>&1
test -f /opt/rh/rh-python35/enable && source /opt/rh/rh-python35/enable
exec /myenv/bin/python server.py

Como exec substitui o processo de shell, a configuração do programa supervisord pode apontar para esse script de shell como o comando.