Hello, for work we are experimenting using supervisord to supervise things like celeryd (http://celeryproject.org), which uses multiprocessing internally.
In case supervisor needs to resort to send a SIGKILL to the supervised process when stopping it (because it's hanging, or there's a long running job we don't care about and want to stop everything quickly*), the multiprocessing children would hang around anyway. I have created a fork on github with a branch that adds an optional killasgroup per program option/feature: https://github.com/pedronis/supervisor/tree/killasgroup if set when sending a final SIGKILL it gets sent to the whole process group of the supervised process, this terminates brutally also the children which is what we want in this case. The branch has some tests and a doc update. I don't think the sending to the whole group of other signals makes sense in general, the parent process for other signals can handle them and do what is more appropriate, so this is for SIGKILL only. I have looked at the pending pull request to give a multi option to pidproxy, but at least in our case sending SIGTERM to all children is not really what we need and it wouldn't cover anyway the SIGKILL situation, because SIGKILL cannot be handled/redirected anyway. I can make a pull request out of the branch on github, I would be thankful if this optional feature could be considered for inclusion. regards, Samuele Pedroni * yes, for people with Celery knowledge, we are assuming acks_late=True here _______________________________________________ Supervisor-users mailing list [email protected] http://lists.supervisord.org/mailman/listinfo/supervisor-users
