[PERDITION-USERS] Issues with Perdition 2.1 in FreeBSD

[Egoitz Aurrekoetxea]

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)
***@sarenet.es <mailto:***@sarenet.es>
www.sarenet.es <http://www.sarenet.es/>
Antes de imprimir este correo electrónico piense si es necesario hacerlo.

[Egoitz Aurrekoetxea]

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)
***@sarenet.es <mailto:***@sarenet.es>
www.sarenet.es <http://www.sarenet.es/>
Antes de imprimir este correo electrónico piense si es necesario hacerlo.

Post by Egoitz Aurrekoetxea
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
if (child < 0)
return status;
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;
+ 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)
www.sarenet.es <http://www.sarenet.es/>
Antes de imprimir este correo electrónico piense si es necesario hacerlo.
______________________________________________
Perdition-users mailing list
http://lists.vergenet.net/listinfo/perdition-users

[Simon Horman]

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?

Post by Egoitz Aurrekoetxea
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)
www.sarenet.es <http://www.sarenet.es/>
Antes de imprimir este correo electrónico piense si es necesario hacerlo.

Post by Egoitz Aurrekoetxea
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
if (child < 0)
return status;
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;
+ 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)
www.sarenet.es <http://www.sarenet.es/>
Antes de imprimir este correo electrónico piense si es necesario hacerlo.
______________________________________________
Perdition-users mailing list
http://lists.vergenet.net/listinfo/perdition-users

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

[Simon Horman]

Good morning,
Thanks a lot for your help.
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??

It seems so. What is the name associated with error 53 on your system?

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)
www.sarenet.es <http://www.sarenet.es/>
Antes de imprimir este correo electrónico piense si es necesario hacerlo.

Post by Simon Horman
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?

Post by Egoitz Aurrekoetxea
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)
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.

Post by Egoitz Aurrekoetxea
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
if (child < 0)
return status;
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;
+ 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)
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
http://lists.vergenet.net/listinfo/perdition-users

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

[Simon Horman]

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.

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 <***@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 <***@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]

[Egoitz Aurrekoetxea]

Good morning,

Answering below and in black :)


Egoitz Aurrekoetxea
Departamento de sistemas
944 209 470
Parque Tecnológico. Edificio 103
48170 Zamudio (Bizkaia)
***@sarenet.es <mailto:***@sarenet.es>
www.sarenet.es <http://www.sarenet.es/>
Antes de imprimir este correo electrónico piense si es necesario hacerlo.

Post by Simon Horman

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.

Post by Simon Horman
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,

Post by Simon Horman
http://hg.vergenet.net/vanessa/vanessa_socket/rev/86186acdf27e
# HG changeset patch
# Date 1305777845 -32400
# Node ID 86186acdf27ef7dca5f927448c1a07126f491caa
# Parent f09d51ca6e578d74b99da38f0ddf563e44e32af5
Use freeaddrinfo() in on success in vanessa_socket_server_bind()
This resolves a memory leak
--- 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]

[Egoitz Aurrekoetxea]

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 :



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)
***@sarenet.es <mailto:***@sarenet.es>
www.sarenet.es <http://www.sarenet.es/>
Antes de imprimir este correo electrónico piense si es necesario hacerlo.

Good morning,
Answering below and in black :)
Egoitz Aurrekoetxea
Departamento de sistemas
944 209 470
Parque Tecnológico. Edificio 103
48170 Zamudio (Bizkaia)
www.sarenet.es <http://www.sarenet.es/>
Antes de imprimir este correo electrónico piense si es necesario hacerlo.

Post by Simon Horman

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

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.

Post by Simon Horman
I am wondering if you could try either the current hg tree
of vanessa socket.
http://hg.vergenet.net/vanessa/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,

Post by Simon Horman
http://hg.vergenet.net/vanessa/vanessa_socket/rev/86186acdf27e <http://hg.vergenet.net/vanessa/vanessa_socket/rev/86186acdf27e>
# HG changeset patch
# Date 1305777845 -32400
# Node ID 86186acdf27ef7dca5f927448c1a07126f491caa
# Parent f09d51ca6e578d74b99da38f0ddf563e44e32af5
Use freeaddrinfo() in on success in vanessa_socket_server_bind()
This resolves a memory leak
--- 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]

______________________________________________
Perdition-users mailing list
http://lists.vergenet.net/listinfo/perdition-users <http://lists.vergenet.net/listinfo/perdition-users>

[Egoitz Aurrekoetxea]

Good morning list! :)

The patch you provided by you has done the trick


I hadn’t looked at 640 and 641 after patching vanessa_socket_server.c
.

Rebuilding machines with this patch :) :)

Thank you so much!!!

Regards!



Egoitz Aurrekoetxea
Departamento de sistemas
944 209 470
Parque Tecnológico. Edificio 103
48170 Zamudio (Bizkaia)
***@sarenet.es <mailto:***@sarenet.es>
www.sarenet.es <http://www.sarenet.es/>
Antes de imprimir este correo electrónico piense si es necesario hacerlo.

Good morning,
<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
.
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)
www.sarenet.es <http://www.sarenet.es/>
Antes de imprimir este correo electrónico piense si es necesario hacerlo.

Good morning,
Answering below and in black :)
Egoitz Aurrekoetxea
Departamento de sistemas
944 209 470
Parque Tecnológico. Edificio 103
48170 Zamudio (Bizkaia)
www.sarenet.es <http://www.sarenet.es/>
Antes de imprimir este correo electrónico piense si es necesario hacerlo.

Post by Simon Horman

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

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.

Post by Simon Horman
I am wondering if you could try either the current hg tree
of vanessa socket.
http://hg.vergenet.net/vanessa/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,

Post by Simon Horman
http://hg.vergenet.net/vanessa/vanessa_socket/rev/86186acdf27e <http://hg.vergenet.net/vanessa/vanessa_socket/rev/86186acdf27e>
# HG changeset patch
# Date 1305777845 -32400
# Node ID 86186acdf27ef7dca5f927448c1a07126f491caa
# Parent f09d51ca6e578d74b99da38f0ddf563e44e32af5
Use freeaddrinfo() in on success in vanessa_socket_server_bind()
This resolves a memory leak
--- 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]

______________________________________________
Perdition-users mailing list
http://lists.vergenet.net/listinfo/perdition-users <http://lists.vergenet.net/listinfo/perdition-users>

______________________________________________
Perdition-users mailing list
http://lists.vergenet.net/listinfo/perdition-users <http://lists.vergenet.net/listinfo/perdition-users>

[Simon Horman]

Post by Egoitz Aurrekoetxea
Good morning list! :)
The patch you provided by you has done the trick…
I hadn’t looked at 640 and 641 after patching vanessa_socket_server.c….
Rebuilding machines with this patch :) :)
Thank you so much!!!

Thanks, I will see about making a release of vanessa socket.

[Egoitz Aurrekoetxea]

In case it helps, previous machines were running FreeBSD 9 RELENG
 with Vanesa libraries all of them version 0.0.7 and Perdition 1.17.1



Egoitz Aurrekoetxea
Departamento de sistemas
944 209 470
Parque Tecnológico. Edificio 103
48170 Zamudio (Bizkaia)
***@sarenet.es <mailto:***@sarenet.es>
www.sarenet.es <http://www.sarenet.es/>
Antes de imprimir este correo electrónico piense si es necesario hacerlo.

Good morning,
Thanks a lot for your help.
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??
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)
www.sarenet.es <http://www.sarenet.es/>
Antes de imprimir este correo electrónico piense si es necesario hacerlo.

Post by Simon Horman
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?

Post by Egoitz Aurrekoetxea
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)
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.

Post by Egoitz Aurrekoetxea
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
if (child < 0)
return status;
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;
+ 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)
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
http://lists.vergenet.net/listinfo/perdition-users

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