diff options
| -rw-r--r-- | NEWS | 13 | ||||
| -rw-r--r-- | driver.c | 4 | ||||
| -rw-r--r-- | fetchmail.c | 30 | ||||
| -rw-r--r-- | fetchmail.man | 10 |
4 files changed, 53 insertions, 4 deletions
@@ -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 -- @@ -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 |