From 07513709eed70fe7fcf7361eaf17640ed74683bf Mon Sep 17 00:00:00 2001
From: "Eric S. Raymond" <esr@thyrsus.com>
Date: Sat, 19 Oct 1996 19:03:31 +0000
Subject: Avoid the socket-exhaustion bug.

svn path=/trunk/; revision=354
---
 NEWS          | 13 ++++++++++++-
 driver.c      |  4 ++--
 fetchmail.c   | 30 +++++++++++++++++++++++++++++-
 fetchmail.man | 10 ++++++++++
 4 files changed, 53 insertions(+), 4 deletions(-)

diff --git a/NEWS b/NEWS
index 3cce3688..10500dd6 100644
--- a/NEWS
+++ b/NEWS
@@ -1,10 +1,13 @@
+			Known problems:
+
+
 			Release Notes:
 
 fetchmail-1.9 ():
 
 features --
 
-* The first message from a query now includes the number of new messages
+* The first message from a query now includes the number of old messages
   when this can be determined (that is not under POP2).
 
 * POP3 UID support really works now.  I make rude noises at the POP3 mavens
@@ -50,6 +53,14 @@ bugs --
 * Fixed various bugs in --check.  It now reports PS_SUCCESS only if
   there is new mail waiting.
 
+* Under Linux, if fetchmail is run in daemon mode with the network
+  inaccessible, each poll leaves a socket allocated but in CLOSE state
+  (this is visible in netstat(1)'s output).  These sockets aren't
+  garbage-collected until fetchmail exits.  When whatever kernel table
+  is involved fills up, fetchmail can no longer run even if the network is up.
+  To avoid this, fetchmail now commits seppuku after some number of
+  unsuccessful socket opens.
+
 fetchmail-1.8 (Fri Oct 11 15:08:10 EDT 1996):
 
 features --
diff --git a/driver.c b/driver.c
index 2436cc78..a10867cc 100644
--- a/driver.c
+++ b/driver.c
@@ -624,8 +624,8 @@ struct method *proto;		/* protocol method table */
 	else
 	{
 	    fprintf(stderr, "%d message%s", count, count > 1 ? "s" : ""); 
-	    if (new != -1)
-		fprintf(stderr, " (%d new)", new);
+	    if (new != -1 && (count - new) > 0)
+		fprintf(stderr, " (%d seen)", count-new);
 	    fprintf(stderr,
 		    " from %s for %s@%s.\n",
 		    queryctl->remotename,
diff --git a/fetchmail.c b/fetchmail.c
index 5c1023e7..3e5a991d 100644
--- a/fetchmail.c
+++ b/fetchmail.c
@@ -29,6 +29,8 @@
 #include "fetchmail.h"
 #include "getopt.h"
 
+#define DROPDEAD	6	/* maximum bad socjet opens */
+
 #ifdef HAVE_PROTOTYPES
 /* prototypes for internal functions */
 static int dump_options (struct hostrec *queryctl);
@@ -62,7 +64,7 @@ main (argc,argv)
 int argc;
 char **argv;
 { 
-    int mboxfd, st, bkgd;
+    int mboxfd, st, bkgd, lossage;
     struct hostrec def_opts;
     int parsestatus, implicitmode;
     char *servername, *user, *home, *tmpdir, tmpbuf[BUFSIZ]; 
@@ -394,12 +396,38 @@ char **argv;
      * Query all hosts. If there's only one, the error return will
      * reflect the status of that transaction.
      */
+    lossage = 0;
     do {
 	for (hostp = hostlist; hostp; hostp = hostp->next)
 	{
 	    if (hostp->active && !(implicitmode && hostp->skip))
 	    {
 		popstatus = query_host(hostp);
+
+		/*
+		 * Under Linux, if fetchmail is run in daemon mode
+		 * with the network inaccessible, each poll leaves a
+		 * socket allocated but in CLOSE state (this is
+		 * visible in netstat(1)'s output).  For some reason,
+		 * these sockets aren't garbage-collected until
+		 * fetchmail exits.  When whatever kernel table is
+		 * involved fills up, fetchmail can no longer run even
+		 * if the network is up.  This does not appear to be a
+		 * socket leak in fetchmail.  To avoid this
+		 * problem, fetchmail commits seppuku after five
+		 * unsuccessful socket opens.
+		 */
+		if (popstatus == PS_SOCKET)
+		    lossage++;
+		else
+		    lossage = 0;
+		if (lossage >= DROPDEAD)
+		{
+		    fputs("fetchmail: exiting, network appears to be down\n",
+			  stderr);
+		    termhook(0);
+		}
+
 		if (!check_only)
 		    update_uid_lists(hostp);
 	    }
diff --git a/fetchmail.man b/fetchmail.man
index 03a72a69..b2165186 100644
--- a/fetchmail.man
+++ b/fetchmail.man
@@ -642,6 +642,16 @@ to the mailserver.  This creates a risk that name/password pairs
 might be snaffled with a packet sniffer or more sophisticated
 monitoring software.
 .PP
+Under Linux, if fetchmail is run in daemon mode with the network
+inaccessible, each poll leaves a socket allocated but in CLOSE state
+(this is visible in netstat(1)'s output).  For some reason, these
+sockets aren't garbage-collected until \fIfetchmail\fR exits.  When
+whatever kernel table is involved fills up, fetchmail can no longer
+run even if the network is up.  This appears \fInot\fR to be a socket
+leak in \fIfetchmail\fR, but rather some glitch or misfeature in the system
+network code.  To avoid this problem, fetchmail commits seppuku after
+too many unsuccessful socket opens.
+.PP
 Send comments, bug reports, gripes, and the like to Eric S. Raymond
 <esr@thyrsus.com>.
 .SH SEE ALSO
-- 
cgit v1.2.3