I had forgotten, the versions of Vanessa are : libvanessa_adt-0.0.9 libvanessa_logger-0.0.10 libvanessa_socket-0.0.12 Perhaps I should check for this patch if errno is not EAGAIN and is EWOULDBLOCK for allowing Perdition parent process to fail if errno is EWOULDBLOCK?? At this stage I’m still trying to see if this patch solves the issue…. Best regards, Egoitz Aurrekoetxea Departamento de sistemas 944 209 470 Parque Tecnológico. Edificio 103 48170 Zamudio (Bizkaia) egoitz(a)sarenet.es <mailto:egoitz@sarenet.es> www.sarenet.es <http://www.sarenet.es/> Antes de imprimir este correo electrónico piense si es necesario hacerlo.

______________________________________________ Perdition-users mailing list Perdition-users(a)vergenet.net http://lists.vergenet.net/listinfo/perdition-users

El 6/3/2015, a las 13:46, Egoitz Aurrekoetxea &lt;egoitz(a)sarenet.es&gt; escribió: Good morning, Thanks a lot for your help. If I’m taking a look to errno.h : cat /usr/include/errno.h | grep EAGA /* 11 was EAGAIN */ #define EAGAIN 35 /* Resource temporarily unavailable */ #define EWOULDBLOCK EAGAIN /* Operation would block */ So, both are the same perhaps in FreeBSD?? The parent process exists in the order shown below, let me see you the corresponding output with the patch below (the literals in the dying moment) : Mar 5 08:30:18 perdition.imap4s[99711]: __vanessa_socket_server_accept: Falla accept con el error Mar 5 08:30:18 perdition.imap4s[99711]: __vanessa_socket_server_accept: ========================= Mar 5 08:30:18 perdition.imap4s[99711]: __vanessa_socket_server_accept: 53 Mar 5 08:30:18 perdition.imap4s[99711]: __vanessa_socket_server_accept: ========================= Mar 5 08:30:18 perdition.imap4s[99711]: __vanessa_socket_server_accept: Falla accept con el error Mar 5 08:30:18 perdition.imap4s[99711]: __vanessa_socket_server_accept: ========================= Mar 5 08:30:18 perdition.imap4s[99711]: __vanessa_socket_server_accept: 35 Mar 5 08:30:18 perdition.imap4s[99711]: __vanessa_socket_server_accept: ========================= Mar 5 08:30:18 perdition.imap4s[99711]: __vanessa_socket_server_acceptv: EGOITZ STATUS -----> 0 Mar 5 08:30:18 perdition.imap4s[99711]: main: vanessa_socket_server_accept Mar 5 08:30:18 perdition.imap4s[99711]: Fatal error accepting child connection. Exiting. And no… I have no idea… Should say instead one clarification; we have updated this machines to FreeBSD 10.1-RELEASE-p6 and Perdition 2.1 (with Vanessa’s versions shown in previous email) last week just, when the problems began. Have been taking a look at FreeBSD source code and SVN but am not being able to see any kind of modification in accept() syscall… Thank you so much, Best regards, Egoitz Aurrekoetxea Departamento de sistemas 944 209 470 Parque Tecnológico. Edificio 103 48170 Zamudio (Bizkaia) egoitz(a)sarenet.es <mailto:egoitz@sarenet.es> www.sarenet.es <http://www.sarenet.es/> Antes de imprimir este correo electrónico piense si es necesario hacerlo.

El 6/3/2015, a las 14:27, Simon Horman &lt;horms(a)verge.net.au&gt; escribió: On Fri, Mar 06, 2015 at 01:46:52PM +0100, Egoitz Aurrekoetxea wrote: It seems so. What is the name associated with error 53 on your system? > The parent process exists in the order shown below, let me see you the corresponding output with the patch below (the literals in the dying moment) : > > Mar 5 08:30:18 perdition.imap4s[99711]: __vanessa_socket_server_accept: Falla accept con el error > Mar 5 08:30:18 perdition.imap4s[99711]: __vanessa_socket_server_accept: ========================= > Mar 5 08:30:18 perdition.imap4s[99711]: __vanessa_socket_server_accept: 53 > Mar 5 08:30:18 perdition.imap4s[99711]: __vanessa_socket_server_accept: ========================= > Mar 5 08:30:18 perdition.imap4s[99711]: __vanessa_socket_server_accept: Falla accept con el error > Mar 5 08:30:18 perdition.imap4s[99711]: __vanessa_socket_server_accept: ========================= > Mar 5 08:30:18 perdition.imap4s[99711]: __vanessa_socket_server_accept: 35 > Mar 5 08:30:18 perdition.imap4s[99711]: __vanessa_socket_server_accept: ========================= > Mar 5 08:30:18 perdition.imap4s[99711]: __vanessa_socket_server_acceptv: EGOITZ STATUS -----> 0 > Mar 5 08:30:18 perdition.imap4s[99711]: main: vanessa_socket_server_accept > Mar 5 08:30:18 perdition.imap4s[99711]: Fatal error accepting child connection. Exiting. > > And no… I have no idea… Should say instead one clarification; we have updated this machines to FreeBSD 10.1-RELEASE-p6 and Perdition 2.1 (with Vanessa’s versions shown in previous email) last week > just, when the problems began. Have been taking a look at FreeBSD source code and SVN but am not being able to see any kind of modification in accept() syscall… > > Thank you so much, > Best regards, > > > Egoitz Aurrekoetxea > Departamento de sistemas > 944 209 470 > Parque Tecnológico. Edificio 103 > 48170 Zamudio (Bizkaia) > egoitz(a)sarenet.es <mailto:egoitz@sarenet.es> > www.sarenet.es <http://www.sarenet.es/> > Antes de imprimir este correo electrónico piense si es necesario hacerlo. > >> El 6/3/2015, a las 12:45, Simon Horman &lt;horms(a)verge.net.au&gt; escribió: >> >> Hi Egoitz, >> >> I'd like to try and clarify the situation. >> >> 1. Is the following correct? >> >> EAGAIN = 53 >> EWOULDBLOCK = 35 >> >> 2. If so is the problem that the listening process exits if >> errno is EWOULDBLOCK? >> >> If so do you have any idea why EWOULDBLOCK is being returned? >> >> On Fri, Mar 06, 2015 at 10:34:00AM +0100, Egoitz Aurrekoetxea wrote: >>> I had forgotten, the versions of Vanessa are : >>> >>> libvanessa_adt-0.0.9 >>> libvanessa_logger-0.0.10 >>> libvanessa_socket-0.0.12 >>> >>> Perhaps I should check for this patch if errno is not EAGAIN and is EWOULDBLOCK for allowing Perdition parent process to fail if errno is EWOULDBLOCK?? >>> >>> At this stage I’m still trying to see if this patch solves the issue…. >>> >>> Best regards, >>> >>> >>> Egoitz Aurrekoetxea >>> Departamento de sistemas >>> 944 209 470 >>> Parque Tecnológico. Edificio 103 >>> 48170 Zamudio (Bizkaia) >>> egoitz(a)sarenet.es <mailto:egoitz@sarenet.es> <mailto:egoitz@sarenet.es <mailto:egoitz@sarenet.es>> >>> www.sarenet.es <http://www.sarenet.es/> <http://www.sarenet.es/ <http://www.sarenet.es/>> >>> Antes de imprimir este correo electrónico piense si es necesario hacerlo. >>> >>>> El 5/3/2015, a las 16:59, Egoitz Aurrekoetxea &lt;egoitz(a)sarenet.es <mailto:egoitz@sarenet.es>> escribió: >>>> >>>> God afternoon, >>>> >>>> I’m running some issues in a FreeBSD 10.1 RELENG machine with Perdition 2.1. Once or twice a day the parent process of POP3 or IMAP4 service dies. After doing some >>>> investigations have seen the problem comes when at vanessa_socket_server.c file at __vanessa_socket_server_accept() when it does the accept(). It seems accept() is failing >>>> with 53 (which continues) and later with 35 (talking about errno of course) with which exits with -1. So later is returning to __vanessa_socket_server_acceptv() and this one returns to >>>> vanessa_socket_server_acceptv due to : >>>> >>>> if (child < 0) >>>> return status; >>>> >>>> At this function (the last one) does exist : >>>> >>>> child = __vanessa_socket_server_acceptv(&g, ufds[i].fd, >>>> listen_socketv, >>>> maximum_connections, >>>> return_from, return_to, flag); >>>> VANESSA_LOGGER_DEBUG("EGOITZ 1E"); >>>> if (child < 0) { >>>> VANESSA_LOGGER_DEBUG( >>>> "__vanessa_socket_server_acceptv"); >>>> goto err; >>>> >>>> >>>> Perhaps this file be (please ignore the debugging literals) could be like this ? >>>> >>>> --- vanessa_socket_server.c 2010-06-22 09:21:37.000000000 +0200 >>>> +++ vanessa_socket_server.c 2015-03-05 16:50:25.000000000 +0100 >>>> @@ -388,10 +388,20 @@ >>>> addrlen = sizeof(from); >>>> *g = accept(listen_socket, (struct sockaddr *) &from, &addrlen); >>>> if (*g < 0) { >>>> + char codigo[20]; >>>> + sprintf(codigo, "%d", errno); >>>> + VANESSA_LOGGER_DEBUG("Falla accept con el error"); >>>> + VANESSA_LOGGER_DEBUG("========================="); >>>> + VANESSA_LOGGER_DEBUG(codigo); >>>> + VANESSA_LOGGER_DEBUG("========================="); >>>> + if (errno == EAGAIN) >>>> + { >>>> + VANESSA_LOGGER_DEBUG("TENEMOS UN EAGAIN"); >>>> + } >>>> if(errno == EINTR || errno == ECONNABORTED) { >>>> continue; /* Ignore EINTR and ECONNABORTED */ >>>> } >>>> - if (errno == EAGAIN || errno == EWOULDBLOCK) >>>> + if (errno == EWOULDBLOCK || errno == EAGAIN) >>>> return -1; /* Don't log EAGAIN or EWOULDBLOCK */ >>>> VANESSA_LOGGER_DEBUG_ERRNO("accept"); >>>> return(-1); >>>> @@ -551,7 +561,10 @@ >>>> flag); >>>> if (child < 0) { >>>> if (errno == EAGAIN || errno == EWOULDBLOCK) >>>> + { >>>> status = 0; >>>> + VANESSA_LOGGER_DEBUG("EGOITZ STATUS -----> 0"); >>>> + } >>>> else { >>>> VANESSA_LOGGER_DEBUG("__vanessa_socket_server_accept"); >>>> status = -1; >>>> @@ -561,6 +574,7 @@ >>>> if (!(opt & O_NONBLOCK) && child && >>>> fcntl(listen_socket, F_SETFL, opt) < 0) { >>>> VANESSA_LOGGER_DEBUG_ERRNO("fcntl: F_SETFL 2"); >>>> + VANESSA_LOGGER_DEBUG("ERROR 0000001 AAAAA"); >>>> status = -1; >>>> } >>>> >>>> @@ -570,6 +584,7 @@ >>>> if (!(opt & O_NONBLOCK) && (flag & VANESSA_SOCKET_NO_FORK || !child) && >>>> fcntl(*g, F_SETFL, opt) < 0) { >>>> VANESSA_LOGGER_DEBUG_ERRNO("fcntl: F_SETFL 3"); >>>> + VANESSA_LOGGER_DEBUG("ERROR 0000002 BBBB"); >>>> status = -1; >>>> } >>>> >>>> @@ -632,6 +647,10 @@ >>>> "__vanessa_socket_server_acceptv"); >>>> goto err; >>>> } >>>> + if (!child && g < 0) >>>> + { >>>> + break; >>>> + } >>>> if (flag & VANESSA_SOCKET_NO_FORK || !child) { >>>> status = g; >>>> goto out; >>>> >>>> Mainly talking about : >>>> >>>> + if (!child && g < 0) >>>> + { >>>> + break; >>>> + } >>>> >>>> That way polling again socket fds instead of exiting and stop servicing the affected protocol in each case (POP3 or IMAP4)?? >>>> >>>> Have done this last modification without having the luck of having an abnormal termination again, in order to check if this works… >>>> >>>> Has anyone have noticed about something similar?. >>>> >>>> Thank you so much, >>>> Regards, >>>> >>>> >>>> Egoitz Aurrekoetxea >>>> Departamento de sistemas >>>> 944 209 470 >>>> Parque Tecnológico. Edificio 103 >>>> 48170 Zamudio (Bizkaia) >>>> egoitz(a)sarenet.es <mailto:egoitz@sarenet.es> <mailto:egoitz@sarenet.es <mailto:egoitz@sarenet.es>> >>>> www.sarenet.es <http://www.sarenet.es/> <http://www.sarenet.es/ <http://www.sarenet.es/>> >>>> Antes de imprimir este correo electrónico piense si es necesario hacerlo. >>>> >>>> ______________________________________________ >>>> Perdition-users mailing list >>>> Perdition-users(a)vergenet.net >>>> http://lists.vergenet.net/listinfo/perdition-users >>> >> >>> ______________________________________________ >>> Perdition-users mailing list >>> Perdition-users(a)vergenet.net >>> http://lists.vergenet.net/listinfo/perdition-users >

El 7/3/2015, a las 6:36, Simon Horman &lt;horms(a)verge.net.au&gt; escribió: On Fri, Mar 06, 2015 at 02:50:58PM +0100, Egoitz Aurrekoetxea wrote: 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.

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.

http://hg.vergenet.net/vanessa/vanessa_socket/rev/86186acdf27e # HG changeset patch # User Simon Horman &lt;horms(a)verge.net.au&gt; # 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 &lt;horms(a)verge.net.au&gt; --- 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]

El 9/3/2015, a las 10:57, Egoitz Aurrekoetxea &lt;egoitz(a)sarenet.es&gt; escribió: Good morning, Applied the following patch (your’s one gave me error of malformed patch) obtained from diff-ing hg current version of vanessa_socket_server.c and the version I’m running without my patch : <parche_vanesasocket.patch> Although If I seen correctly (have looked slightly fast but… well anyway) child is going to be 0 not a negative value and so… is not going to continue in the loop…. For continuing in the loop I assume it should be : f (child < 0) { VANESSA_LOGGER_DEBUG( "__vanessa_socket_server_acceptv"); goto err; } if (!child) instead of < 0…. But anyway… Applied as it’s, I’ll keep you informed, Best regards, Egoitz Aurrekoetxea Departamento de sistemas 944 209 470 Parque Tecnológico. Edificio 103 48170 Zamudio (Bizkaia) egoitz(a)sarenet.es <mailto:egoitz@sarenet.es> www.sarenet.es <http://www.sarenet.es/> Antes de imprimir este correo electrónico piense si es necesario hacerlo. ______________________________________________ Perdition-users mailing list Perdition-users(a)vergenet.net <mailto:Perdition-users@vergenet.net> http://lists.vergenet.net/listinfo/perdition-users <http://lists.vergenet.net/listinfo/perdition-users>