From roman at rs-labs.com Thu Oct 15 04:34:59 2009 From: roman at rs-labs.com (Roman Medina-Heigl Hernandez) Date: Thu, 15 Oct 2009 10:34:59 +0200 Subject: [imapproxy-info] Imapproxy quitting when IMAP server is unavailable In-Reply-To: <5006_1241509067_n457bjwi015796_49FFECC9.6000100@rs-labs.com> References: <5002_1241451020_n44FUIUI029695_49FF0A07.3010503@rs-labs.com> <49FF0AA0.2060505@andrew.cmu.edu> <5006_1241509067_n457bjwi015796_49FFECC9.6000100@rs-labs.com> Message-ID: <29316_1255595707_n9F8Z5FG013396_4AD6DEB3.1090301@rs-labs.com> More on this (sorry, I hadn't time to review it before). The reported bug is *not* fixed (not at least in latest 1.2.6 or 1.2.7rc2; I checked both of this). This is the final excerpt from ServerInit() in main.c: ==== ... syslog(LOG_INFO, "%s: Proxying to IMAP port %s", fn, PC_Struct.server_port ); /* * fill in the address family, the host address, and the * service port of our global socket address structure */ ISD.airesults = ai; ISD.srv = NULL; for ( ; ai != NULL; ai = ai->ai_next ) { if ( ( sd = socket( ai->ai_family, ai->ai_socktype, ai->ai_protocol ) ) < 0 ) continue; if ( connect( sd, (struct sockaddr *)ai->ai_addr, ai->ai_addrlen ) ) continue; close( sd ); ISD.srv = ai; break; } if ( ai == NULL ) { syslog( LOG_ERR, "%s: %s -- exiting", fn, strerror( errno ) ); exit( EXIT_FAILURE ); } } ==== So when imapproxy is started, it tries to connect to imap server. If connect() doesn't succeed, it will return -1 so the "if" statement evaluates to "true" and a "continue" is executed. Then "for" loop iterates until "ai==NULL". Finally, the "for" loop finishes and the next "if" statement executes, performing an exit(). Before that, syslog registers something like that: "ServerInit(): Connection refused -- exiting" So, no, it's not fixed. And it's a problematic bug since it usually takes a litte time for imapd to get ready (at least Cyrus), so when booting a machine, imapproxy will get started before imapd is really ready, connect() will fail and the bug will be triggered so you'll end up with a system with imapproxy being down. Of course you could make a quick fix at the "sysadmin" level by pausing/delaying the execution of imapproxy init script, but I think this is not the right way to go... I don't have time to code a fix but it should be pretty straightforward. The idea would be the same you applied to the case in which the server hostname couldn't be resolved, and that you haved coded as: ==== for( ;; ) { if ( ( gaierrnum = getaddrinfo( PC_Struct.server_hostname, PC_Struct.server_port, &aihints, &ai ) ) ) { syslog( LOG_ERR, "%s: getaddrinfo() failed to resolve hostname of remote IMAP server: %s -- retrying", fn, gai_strerror( gaierrnum ) ); sleep( 15 ); } else { break; } } ==== PS: I'm cc'ing Debian developper in charge of imapproxy (Jos? Luis Tall?n) since I don't know for sure whether he is monitoring this list... I finally had to disable imapproxy because this behaviour creates a single point of failure in my email infrastructure. It affects to security (lost of "availability") and I don't agree Jose Luis, who marked the bug as "wish-list" (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517331) Cheers, -Rom?n Roman Medina-Heigl Hernandez escribi?: > Dave McMurtrie escribi?: >> Roman Medina-Heigl Hernandez wrote: >>> Hello, >>> >>> I filed a Debian bug on imapproxy package some time ago: >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517331 >>> >>> Basically, when starting imapproxy, it quits inmediately when IMAP server >>> is unavailable, so if you have a network outage just in the same moment >>> when you're trying to start imapproxy, it will refuse to start. IMHO, the >>> logical behaviour should be not to die but instead keep daemon in >>> background and retry connection to imap server later. >>> >>> I'd like to know your opinion about this, whether or not this is a known >>> bug and finally if perhaps (luckily) the bug is already solved (in this >>> case, which imapproxy version? Any patch available for the stated >>> problem?) >> That's been fixed since 1.2.4. It will now try to connect to the imap >> server forever upon startup. > > > Hello Dave, > > I saw this in imapproxy's changelog (2003-10-09 entry): > > * main.c: Changes to allow configurable tcp keelalive support. > Added retry logic for the initial socket connection to the > real imap server (patch submitted by Gary Mills > ). > > But I'm suffering the problem in Debian 5.0 (Lenny), which comes with > imapproxy 1.2.6 (which it's supposed to be fixed). :-? Do you have any > similar reports? > > Is the fix perhaps disabled by default or maybe I need to set up some > configuration option to enable/tune the retrying action? > > I have keepalives disabled (Debian default): > send_tcp_keepalives no > Maybe the retry logic depends on this? (IMHO it shouldn't...). > > Cheers, > -Roman > > _______________________________________________ > imapproxy-info mailing list > imapproxy-info at lists.andrew.cmu.edu > https://lists.andrew.cmu.edu/mailman/listinfo/imapproxy-info From dave64 at andrew.cmu.edu Thu Oct 15 19:38:35 2009 From: dave64 at andrew.cmu.edu (Dave McMurtrie) Date: Thu, 15 Oct 2009 19:38:35 -0400 Subject: [imapproxy-info] Imapproxy quitting when IMAP server is unavailable In-Reply-To: <4AD7A0FD.60307@adv-solutions.net> References: <5002_1241451020_n44FUIUI029695_49FF0A07.3010503@rs-labs.com> <49FF0AA0.2060505@andrew.cmu.edu> <5006_1241509067_n457bjwi015796_49FFECC9.6000100@rs-labs.com> <4AD6DEB3.1090301@rs-labs.com> <4AD7A0FD.60307@adv-solutions.net> Message-ID: On Oct 15, 2009, at 6:23 PM, Jos? Luis Tall?n wrote: > Roman Medina-Heigl Hernandez wrote: >> More on this (sorry, I hadn't time to review it before). >> >> [snip] >> >> PS: I'm cc'ing Debian developper in charge of imapproxy (Jos? Luis >> Tall?n) >> since I don't know for sure whether he is monitoring this list... > Nope. I'm not subscribed to the list. Thanks many. >> I finally >> had to disable imapproxy because this behaviour creates a single >> point of >> failure in my email infrastructure. It affects to security (lost of >> "availability") and I don't agree Jose Luis, who marked the bug as >> "wish-list" (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517331) >> > > Since you have essentially provided the solution, I can prepare a > fixed > package for you to test. > We can then reopen the bug and upload the newer package. > > Dave, would you release 1.2.7 with my patch included soonish, so > that it > can (hopefully) go into Squeeze ? > > Absolutely. Thanks for taking care of it! Dave