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.
Personally, I'd be ok with just catching it, and exiting gracefully (with an
exit code of 1, of course).
Here's a quick diff of that proposal:
--- a/src/supervisor/xmlrpc.py Thu Sep 03 10:18:03 2009 -0400
+++ b/src/supervisor/xmlrpc.py Thu Sep 03 10:52:20 2009 -0400
@@ -482,7 +482,10 @@
def connect(self):
self.sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
# we abuse the host parameter as the socketname
- self.sock.connect(self.socketfile)
+ try:
+ self.sock.connect(self.socketfile)
+ except socket.error:
+ sys.exit('Cannot connect to supervisord, is it running?')
def gettags(comment):
""" Parse documentation strings into JavaDoc-like tokens """
Obviously there are other socket exceptions to test for, but that's the one
that gets raised in my case.
I'd like to know what you think. For now, I have a local copy for hacking
on and I'm ok with that :)
--
Benjamin Smith
http://just-another.net
http://twitter.com/benjaminws
_______________________________________________
Supervisor-users mailing list
[email protected]
http://lists.supervisord.org/mailman/listinfo/supervisor-users
