Hello all, At my company we're in the middle of using supervisor for the deployments of lots of daemons/apps and it works really well for us. One issue I've been running into more and more is supervisor getting into a bad state due to file descriptor limits on the OS. If child applications soak up file descriptors, it can prevent supervisor from opening up sockets to even get logs. (I am going to generate a small test case for this to substantiate it.)
This got me thinking about the overall architecture of supervisord, and as it stands it seems like running the process as a child with a simple fork may not be the most robust over the long term. I was wondering if, rather than keeping a pipe to the stderr/stdout and running all of the jobs as direct subprocesses, supervisord could run processes as daemons (perhaps using the nice python daemon library [1]) and separately watch the PIDs to achieve the same state management supervisor does today. I will probably embark on trying a branch of supervisor that behaves this way, but was wondering if anyone has any insight into issues that may arise with this paradigm shift. Cheers, Mike Axiak 1: https://pypi.python.org/pypi/python-daemon/
_______________________________________________ Supervisor-users mailing list [email protected] https://lists.supervisord.org/mailman/listinfo/supervisor-users
