I have a Python server that must be executed by a Software Collections enabled environment. The supervisord config file looks something like this:
[program:xxx]
command=/usr/bin/scl enable rh-python35 -- /myenv/bin/python server.py
stdout_logfile=/var/log/xxx.log
redirect_stderr=true
The program starts up fine, but supervisord thinks that the scl process is the actual process, but the Python server has a different PID. When time comes for SIGTERM (stop, restart, etc.), the scl process is terminated but the Python server keeps running.
I could make my server write a PID file, and then use the pidproxy program provided by supervisord, as described here:
http://supervisord.org/subprocess.html#pidproxy-program
Then, as described, supervisord would send signals to the correct PID. However, I would prefer, if possible, to avoid changing the server code to create a PID file.
Question: Is there some other way of setting it up?
Note that directly executing the python executable inside the software collection does not work:
[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
Other details:
- Centos 7
EDIT: There is an additional approach besides pidproxy which involves an intermediate shell script. This mailing list entry describes an enable script (as opposed to the scl enable command):
https://www.redhat.com/archives/sclorg/2016-June/msg00008.html
This can be used inside a shell script like so:
exec 2>&1
test -f /opt/rh/rh-python35/enable && source /opt/rh/rh-python35/enable
exec /myenv/bin/python server.py
Since exec replaces the shell process, the supervisord program config can then point to this shell script as the command.
