Answering below and in black :)

Egoitz Aurrekoetxea

Departamento de sistemas

944 209 470
Parque Tecnológico. Edificio 103
48170 Zamudio (Bizkaia)

www.sarenet.es

Antes de imprimir este correo electrónico piense si es necesario hacerlo.

El 7/3/2015, a las 6:36, Simon Horman <horms@verge.net.au> escribió:

On Fri, Mar 06, 2015 at 02:50:58PM +0100, Egoitz Aurrekoetxea wrote:
cat /usr/include/errno.h | grep 53
#define ECONNABORTED 53 /* Software caused connection abort */

That’s it :)

Thanks. The reason that I ask is that the numeric value of error numbers
may vary between different systems. For example on x86_64 Linux
ECONNABORTED is 103.

Yep I supposed that was the matter, I have checked this too previous to asking in this list, to modify appropriately the code in case you have developed this code for Glibc perhaps…

Should say the wrote patch has done something positive and has done what was expected, take a look please :

Mar  6 19:43:09 perdition.imap4[16640]: __vanessa_socket_server_accept: Falla accept con el error

Mar  6 19:43:09 perdition.imap4[16640]: __vanessa_socket_server_accept: =========================

Mar  6 19:43:09 perdition.imap4[16640]: __vanessa_socket_server_accept: 53

Mar  6 19:43:09 perdition.imap4[16640]: __vanessa_socket_server_accept: =========================

Mar  6 19:43:09 perdition.imap4[16640]: __vanessa_socket_server_accept: Falla accept con el error

Mar  6 19:43:09 perdition.imap4[16640]: __vanessa_socket_server_accept: =========================

Mar  6 19:43:09 perdition.imap4[16640]: __vanessa_socket_server_accept: 35

Mar  6 19:43:09 perdition.imap4[16640]: __vanessa_socket_server_accept: =========================

Mar  6 19:43:09 perdition.imap4[16640]: __vanessa_socket_server_accept: TENEMOS UN EAGAIN

Mar  6 19:43:09 perdition.imap4[16640]: __vanessa_socket_server_acceptv: EGOITZ STATUS -----> 0

it’s does not die later...

At least seems that saying the code : "in case you have not been able to fork (because accept has failed with a concreted errno and so you have not forked) go to poll again the set of fds and when see some fd

status changed loop again". I’m not very used to work with sockets in C but I assume perhaps the only disadvantage of doing this, is that in case no fd changes in the set suddenly (due to no any kind of traffic) it

will get the actual established connections stalled because it’s not entering the accept and fork loop meanwhile something changes in some fd of the set. This is not in my case a big problem, because I have very

constant traffic 24*7. Please (for learning) correct me if I’m wrong.

I am wondering if you could try either the current hg tree
of vanessa socket.

http://hg.vergenet.net/vanessa/vanessa_socket/

Or the following patch on top of 0.0.12. Unfortunately its changelog does
not seem to accurately describe everything that it does.

Sure I will!! :), although it has to be on Monday, I’ll try not to make changes on the servers during weekend, mainly when the patch has done some positive work :) No problem with the changelog :) don’t worry :)

I will write you at Monday evening CET timezone for telling you how has it gone…. because as said before too… it’s not easy or possible (at least don’t know how) to reproduce the issue and the patch’s behavior…

As always Simon, a pleasure and thank you so much :) :)

Regards,

http://hg.vergenet.net/vanessa/vanessa_socket/rev/86186acdf27e

# HG changeset patch
# User Simon Horman <horms@verge.net.au>
# Date 1305777845 -32400
# Node ID 86186acdf27ef7dca5f927448c1a07126f491caa
# Parent f09d51ca6e578d74b99da38f0ddf563e44e32af5
Use freeaddrinfo() in on success in vanessa_socket_server_bind()

This resolves a memory leak

Signed-off-by: Simon Horman <horms@verge.net.au>

--- a/libvanessa_socket/vanessa_socket_server.c Tue Oct 06 16:17:48 2009 +1100
+++ b/libvanessa_socket/vanessa_socket_server.c Thu May 19 13:04:05 2011 +0900
@@ -110,6 +110,7 @@
goto err_close;
continue;
}
+ freeaddrinfo(res);
return s;
} while ((res = res->ai_next));

@@ -353,7 +354,7 @@
     const unsigned int maximum_connections,
     struct sockaddr *return_from,
     struct sockaddr *return_to,
-      vanessa_socket_flag_t flag)
+      vanessa_socket_flag_t flag, long opt)
{
unsigned int addrlen;
pid_t child = 0;
@@ -370,7 +371,8 @@
if(errno == EINTR || errno == ECONNABORTED) {
continue; /* Ignore EINTR and ECONNABORTED */

    0K . }
- if (errno == EAGAIN || errno == EWOULDBLOCK)
+ if (opt & O_NONBLOCK &&
+    (errno == EAGAIN || errno == EWOULDBLOCK))
return -1; /* Don't log EAGAIN or EWOULDBLOCK */
VANESSA_LOGGER_DEBUG_ERRNO("accept");
return(-1);
@@ -447,12 +449,19 @@
{
pid_t child;
int g;
+ long opt;
+
+ opt = fcntl(listen_socket, F_GETFL, NULL);
+ if (opt < 0) {
+ VANESSA_LOGGER_DEBUG_ERRNO("fcntl: F_GETFL");
+ return -1;
+ }

while (1) {
child = __vanessa_socket_server_accept(&g, listen_socket, NULL,
      maximum_connections,
      return_from, return_to,
-       flag);
+       flag, opt);
if (child < 0) {
VANESSA_LOGGER_DEBUG("__vanessa_socket_server_accept");
return -1;
@@ -527,14 +536,14 @@
listen_socketv,
maximum_connections,
return_from, return_to,
- flag);
+ flag, opt);
if (child < 0) {
- if (errno == EAGAIN || errno == EWOULDBLOCK)
- status = 0;
- else {
+ status = -1;
+ if (errno == EAGAIN || errno == EWOULDBLOCK) {
.+ if (opt & O_NONBLOCK)
+ status = 0;
+ } else
VANESSA_LOGGER_DEBUG("__vanessa_socket_server_accept");
- status = -1;
- }
}

if (!(opt & O_NONBLOCK) && child &&
@@ -607,6 +616,8 @@
maximum_connections,
return_from, return_to, flag);
if (child < 0) {
+ if (errno == EAGAIN || errno == EWOULDBLOCK)
+ continue;
VANESSA_LOGGER_DEBUG(
"__vanessa_socket_server_acceptv");
goto err;

                                                    15.5K=0.2s

2015-03-07 14:35:50 (15.5 KB/s) - written to stdout [2509]