Hi Benjamin, Benjamin Smith wrote: > I am controlling supervisord with an init script, and within that script > using 'supervisorctl shutdown' to cleanly shutdown everything when told > to stop. Some of the other sysadmins here habitually type restart > without checking the status of a process first. When doing so, if > supervisord isn't running, they get presented with a traceback. When > this happens, they get a tad freaked out and start banging on my door > asking what's up. While the traceback is self explanatory for most > (especially those of us with python experience), I think it's an ugly > way to let people know that supervisord, for whatever reason, isn't running. > > Before looking in the code, I assumed the problem was as simple as doing > a socket.connect() without trying to catch any exceptions. > > Sure enough, In the connect method of UnixStreamHTTPConnection, line > 485, it appears that a socket.connect is being done without catching any > exceptions. I'm writing to ask how you'd want to handle that, if at > all. It's a really, really simple change, but I wasn't sure if you all > had different ideas on how to tackle it or even wanted to.
Thanks for reporting this and your patch. I agree that we shouldn't dump a backtrace when supervisorctl can't connect to supervisord. I could not apply your patch as-is because the supervisor.xmlrpc module is used outside of supervisorctl (e.g. supervisor.childutils). Other programs that use supervisor.xmlrpc need to be able to catch the exception and deal with it as they choose. I have committed a fix to supervisorctl instead. It now prints a friendlier message with no backtrace. This will be included in the next release. Regards, Mike -- Mike Naberezny Maintainable Software http://maintainable.com _______________________________________________ Supervisor-users mailing list [email protected] http://lists.supervisord.org/mailman/listinfo/supervisor-users
