Question

My web application runs on multpile apache instances and I am having multiprocess logging issues because of this. I am currently using a SocketHandler for logging to a daemon using SocketServer that then writes logs to a single log file (similar to this example).

Now that I am using a SocketHandler for logging I am having trouble discovering if/when the socket server crashes. For example, if I try creating a SocketHandler for a port that has no listening socket server, no exception arises. I would like to catch this type of error and log it to a file.

My question is, when logging using SocketHandler how can I discover when the socket being used is not currently being listened to?

Answer 1

When a socket creation operation fails (e.g. because there is no server listening), the default behaviour is to retry the next time an event is logged, with an exponential back-off algorithm. Here are some approaches you could try:

1. Subclass SocketHandler, override the createSocket method and handle exceptions how you will in your implementation.
2. Note that the sock attribute of the SocketHandler instance will be None if no socket has been created yet. If the value is None after you’ve logged an event, most likely the SocketHandler wouldn’t have sent it.
3. Note that the makeSocket method of the handler is used to actually create and connect the socket. So, you could call makeSocket yourself before logging anything, and if it throws an exception, you know that your server is probably not listening. If it returns success, then you can just close the returned value.

4. Subclass SocketHandler, override the emit method, and in your subclass, have a reference to an alternate handler instance (e.g. FileHandler or SMTPHandler) which you want to use. In your emit code, try to create the socket using

   if self.sock is None:
       self.createSocket()
   if self.sock is None:
       # creation failed: do self.alternate_handler.handle(record)
   else:
       # creation succeeded: defer to superclass implementation
   

Of course, this may not catch any errors that occur if the server goes down in the middle of sending a message, but it should at least alert you to some problems with your servers.