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;