Re: perdition stops accepting connections?

Simon Horman <[email protected]>
Newsgroups gmane.mail.perdition.user
Message-ID <[email protected]>
On Mon, Aug 16, 2010 at 10:56:18AM +0900, Simon Horman wrote:
> Thanks Eric,
> 
> I should be able to track the problem down from here.
> I'm currently (finishing) travelling, but I hope to have time to look into
> this some time this week.

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.

______________________________________________
Perdition-users mailing list
[email protected]
http://lists.vergenet.net/listinfo/perdition-users
1.patch (text/x-diff, 533 B)
diff -r fb0b252302db perdition/perdition.c
--- a/perdition/perdition.c	Fri Nov 27 11:09:50 2009 +1100
+++ b/perdition/perdition.c	Sun Aug 29 22:18:27 2010 +0900
@@ -597,7 +597,7 @@
 				      (struct sockaddr *) peername,
 				      (struct sockaddr *) sockname, 0);
     if(s < 0){
-      VANESSA_LOGGER_DEBUG("vanessa_socket_server_accept");
+      VANESSA_LOGGER_DEBUG_ERRNO("vanessa_socket_server_acceptv");
       VANESSA_LOGGER_ERR("Fatal error accepting child connection. Exiting.");
       perdition_exit_cleanly(-1);
     }
2.patch (text/x-diff, 806 B)
diff -r fb0b252302db perdition/perdition.c
--- a/perdition/perdition.c	Fri Nov 27 11:09:50 2009 +1100
+++ b/perdition/perdition.c	Sun Aug 29 22:16:07 2010 +0900
@@ -593,14 +593,19 @@
     }
   }
   else{
+    while (1) {
     s = vanessa_socket_server_acceptv(g, opt.connection_limit,
 				      (struct sockaddr *) peername,
 				      (struct sockaddr *) sockname, 0);
     if(s < 0){
-      VANESSA_LOGGER_DEBUG("vanessa_socket_server_accept");
+      VANESSA_LOGGER_DEBUG_ERRNO("vanessa_socket_server_acceptv");
+      if (errno == EAGAIN || errno == EWOULDBLOCK)
+        continue;
       VANESSA_LOGGER_ERR("Fatal error accepting child connection. Exiting.");
       perdition_exit_cleanly(-1);
     }
+    break;
+    }
 
     /* Child processes don't clean up the pid file */
     pid_file = NULL;
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.