Perdition-users December 2011

perdition-users@vergenet.net

6 participants
3 discussions

Zombie pop3s (and imaps?) processes in connect state

by Christian Balzer

Hello, we've been using perdition as a pop3/pop3s/imap/imaps proxy for about four years now, first with Debian Sarge package and now under Etch. And throughout this time I've seen pop3s (and from the looks of it the same happens with imaps) processes stuck in connect, like this: --- 16836 ? S 5:31 0 120 32179 2204 0.0 perdition.pop3s 28070 ? S 0:00 0 120 32311 1564 0.0 \_ perdition.pop3s: connect 7782 ? S 0:00 0 120 32311 1564 0.0 \_ perdition.pop3s: connect 24468 ? S 0:00 0 120 32311 1568 0.0 \_ perdition.pop3s: connect 14180 ? S 0:00 0 120 32311 1568 0.0 \_ perdition.pop3s: connect 13503 ? S 0:00 0 120 32311 1564 0.0 \_ perdition.pop3s: connect --- They never die off, keep the connection open, there is no traffic and the other end might be long gone. Last trace in the logs is always like this: --- Feb 5 22:05:16 pp11 perdition[7782]: Connect: hi.mi.ts.u->203.216.5.113 --- It must be something related to the SSL'ness of these service, since I'm not seeing this happening ever for imap/pop3. Alas a lot of people do use TLS with those, so it's not a generic SSL issue. Maybe the master process could kick a child handling connections in the head after "timeout" seconds in connect state? If more information is needed I can try to provide it, but note that with a rate of roughly 35 pops per second I'm a bit weary to turn on debugging. ^_- This may or may not be related to another SSL related issue, which will be for the sake of making searches in the archive more likely to find good keywords in a separate mail. Regards, Christian -- Christian Balzer Network/Systems Engineer NOC chibi(a)gol.com Global OnLine Japan/Fusion Network Services http://www.gol.com/

10 years, 11 months

perdition crash on v1.18

by Eric Yiu

Hi, We migrated the perdition machine to a VM as well as upgrade the package from perdition-1.17 to perdition-1.18. >From Time to time, this new perdition is just dead randomly a few times a day. I finally have a time to strace the perdition.pop3 dead of what is happening, here is the info: accept(4, {sa_family=AF_INET, sin_port=htons(53846), sin_addr=inet_addr("<IP Address so show>")}, [6256062840960974864]) = 5 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2b1169929a80) = 21625 close(5) = 0 fcntl(4, F_SETFL, O_RDWR) = 0 poll([{fd=4, events=POLLIN}], 1, -1) = -1 EINTR (Interrupted system call) --- SIGCHLD (Child exited) @ 0 (0) --- rt_sigaction(SIGCHLD, {0x405260, [CHLD], SA_RESTORER|SA_RESTART, 0x2b1167c4f2d0}, {0x405260, [CHLD], SA_RESTORER|SA_RESTART, 0x2b1167c4f2d0}, 8) = 0 wait4(4294967295, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG, NULL) = 21609 wait4(4294967295, 0x7fffcd9be574, WNOHANG, NULL) = 0 rt_sigreturn(0xffffffff) = -1 EINTR (Interrupted system call) poll([{fd=4, events=POLLIN}], 1, -1) = -1 EINTR (Interrupted system call) --- SIGCHLD (Child exited) @ 0 (0) --- rt_sigaction(SIGCHLD, {0x405260, [CHLD], SA_RESTORER|SA_RESTART, 0x2b1167c4f2d0}, {0x405260, [CHLD], SA_RESTORER|SA_RESTART, 0x2b1167c4f2d0}, 8) = 0 wait4(4294967295, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG, NULL) = 21622 wait4(4294967295, 0x7fffcd9be574, WNOHANG, NULL) = 0 rt_sigreturn(0xffffffff) = -1 EINTR (Interrupted system call) poll([{fd=4, events=POLLIN}], 1, -1) = 1 ([{fd=4, revents=POLLIN}]) fcntl(4, F_GETFL) = 0x2 (flags O_RDWR) fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0 accept(4, {sa_family=AF_INET, sin_port=htons(2005), sin_addr=inet_addr("<IP Address so show>")}, [15350237863505559568]) = 5 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2b1169929a80) = 21626 close(5) = 0 fcntl(4, F_SETFL, O_RDWR) = 0 poll([{fd=4, events=POLLIN}], 1, -1) = 1 ([{fd=4, revents=POLLIN}]) fcntl(4, F_GETFL) = 0x2 (flags O_RDWR) fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0 accept(4, {sa_family=AF_INET, sin_port=htons(51774), sin_addr=inet_addr("<IP Address so show>")}, [4524428784237019152]) = 5 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2b1169929a80) = 21627 close(5) = 0 fcntl(4, F_SETFL, O_RDWR) = 0 poll([{fd=4, events=POLLIN}], 1, -1) = 1 ([{fd=4, revents=POLLIN}]) fcntl(4, F_GETFL) = 0x2 (flags O_RDWR) fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0 *accept(4, 0x7fffcd9be920, [4524428784237019264]) = -1 ECONNABORTED (Software caused connection abort) accept(4, 0x7fffcd9be920, [4524428784237019264]) = -1 EAGAIN (Resource temporarily unavailable)* fcntl(4, F_SETFL, O_RDWR) = 0 time([1323309467]) = 1323309467 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2183, ...}) = 0 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2183, ...}) = 0 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2183, ...}) = 0 sendto(3, "<19>Dec 8 12:57:47 perdition[73"..., 86, MSG_NOSIGNAL, NULL, 0) = -1 ENOTCONN (Transport endpoint is not connected) close(3) = 0 socket(PF_FILE, SOCK_DGRAM, 0) = 3 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 connect(3, {sa_family=AF_FILE, path="/dev/log"...}, 110) = 0 sendto(3, "<19>Dec 8 12:57:47 perdition[73"..., 86, MSG_NOSIGNAL, NULL, 0) = 86unlink("/var/run/perdition.pop3/perdition.pop3.pid") = 0 getrlimit(RLIMIT_NOFILE, {rlim_cur=4*1024, rlim_max=4*1024}) = 0 close(0) = 0 close(1) = 0 close(2) = 0 close(3) = 0 .... .. This is also catched similarly at different VM too. I checked the source, it seems 1.17 is using blockIO while 1.18 use nonBlockIO. At the vanessa_socket_server.c static pid_t __vanessa_socket_server_accept(int *g, int listen_socket, int *listen_socketv,... ... .. for(;;) { addrlen = sizeof(from); *g = accept(listen_socket, (struct sockaddr *) &from, &addrlen); if (*g < 0) { if(errno == EINTR || errno == ECONNABORTED) { continue; /* Ignore EINTR and ECONNABORTED */ } if (errno == EAGAIN || errno == EWOULDBLOCK) return -1; /* Don't log EAGAIN or EWOULDBLOCK */ VANESSA_LOGGER_DEBUG_ERRNO("accept"); return(-1); } .... .. So if the perdition face an ECONNABORTED, it accept() again, it will return -1 if there is no incoming socket, after a few return, it seems that (not sure) it will out of the loop and "goto out" and finally return to perdition to exit the program. Is there a patch for that? or the later version fix this? Eric

11 years, 11 months

Newbie Q: using incoming IP for rewrites?

by David E. Smith

I'm sure this is a newbie-level question, but I can't find it clearly answered in the docs or example configurations. Assuming a single instance of Perdition is bound to multiple IP addresses, can Perdition rewrite requests based solely on what IP address receives a login request? I'm replacing an old mail system where each domain has a separate IP address, and there are multiple instances where folks have the same username and password on different domains. Their mail clients are often configure with a user name of 'bob' as opposed to 'bob(a)domain.com', so I really need the IP address in addition to the username/password to figure out where a connection should go. I know I could get around this by having multiple instances of Perdition, each bound to a separate IP address, but there are about 40 domains (and 40 IPs) involved in this process. If there's an easier way to do it, I'd love to avoid having all those nearly-identical configuration files floating around, waiting to confuse me. David Smith MVN.net

11 years, 12 months

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Perdition-users December 2011