Hi Simon, Thanks for letting me know what to look at next. Should I enable connection_logging as well; or just debug? Umel F

It doesn't happen every day but at least a couple of times a week. After turning on debug and seeing those logs fill up; I finally caught it crashing. The only thing that shows up that sticks out in debug is: Aug 12 12:35:20 proxy0 perdition[35537]: main: vanessa_socket_server_accept and in maillog the error from before: Aug 12 12:35:20 proxy0 perdition[35537]: Could not remove pid file [/var/run/perdition.pop3.pid]: Permission denied Hope that helps =[ eric c On Mon, Aug 9, 2010 at 5:03 PM, Simon Horman <horms(a)verge.net.au> wrote:

On Mon, Aug 16, 2010 at 10:56:18AM +0900, Simon Horman wrote: Hi Eric, unfortunately I didn't have time that week. And now that I do have time I'm still left scratching my head. What I suspect is happening is that vanessa_socket_server_accept() is returning an error because accept() returned an error and errno was set to EINTR or ECONNABORTED. The reason that I suspect that is because it would lead to the error logs that you report - any other error should leave some more log entries. However, I'm completely unsure how this could occur, as it should only happen if the socket is marked non-blocking, which it isn't. With this in mind I am supplying two alternate patches. * 1.patch just adds some more debuging information which ought to be able to confirm or refute my suspicion. And in the latter case, provide some extra information that may help locate the problem. * 2.patch adds the same debugging information as 1.patch and also alters the error handling in the case where my suspicion is correct. The error handling is changed so that perdition just tries to accept again (i.e. wait for another connection) rather than exiting. This ought to be safe, but as I'm a bit unsure about what is going on you may prefer not to run it in a production environment, which I why I also supplied 1.patch.