StoreSCP is killed if daemonized when running under supervisord

[Ed McDonagh]

Not entirely sure of my facts, but this is the behaviour I have witnessed:

• OpenREM 0.7 b12
• Gunicorn/Nginx managed by supervisord as per this blog posting

If Store SCP is started from web interface, a subprocess is spawned from one of the supervisord gunicorn/wsgi processes. After about half an hour, the subprocess receives a SIGKILL message and dies.

SIGKILL was recorded using strace as per this post. I failed to get auditctl to tell me who sent the SIGKILL - was attempting to follow this post.

If Store SCP is started using the script in the shell, it runs forever. As far as I can tell.

My suspicion is that supervisord doesn't like the fact that pynetdicom spawns a new thread for the AE, or it lasts too long, and it gets killed. This supervisord doc stresses that daemonized processes should not be created under supervisord.

Refs #328 in that this is a result of ceasing to use Celery for the Store SCP.

[Ed McDonagh]

Can anyone who is using a real webserver (Apache, Nginx etc), but isn't using Supervisord, see what happens if they run StoreSCP from the web interface - does it live 'forever'?

If so, then I guess the docs need to advise users to either use supervisord or similar to manage the openrem_storescp script (and maybe have an option to remove the start and keep_alive options), or instead to use the web interface and the keep_alive script.

Help!

[Ed McDonagh]

StoreSCP has been removed in v1.0