Re: Help fetchmail socket error?
> I've posted with one kind attempt at fixing a problem. My ISP's mail
> went down then said the problem was fixed. I'm still getting prblems
> where eveything was ok before. Mostly I'm getting a socket error and
> expected length problems. I have a selected log of the highlights
> andadditional details if anyone can help. I'm not including the file
so
> as to not clog the list, even though it's 20k...
I trust that you've already checked Fetchmail's FAQ here
http://www.tuxedo.org/~esr/fetchmail/fetchmail-FAQ.html, but if not,
there's a few items related to socket errors and dying during mail
fetching.
====================
Here they are:
R7. Fetchmail randomly dies with socket errors.
Check the MTU value in your PPP interface reported by /sbin/ifconfig. If
it's over 600, change it in your PPP options file. (/etc/ppp/options on
my box). Here are option values that work:
mtu 552
mru 552
====================
R9. Fetchmail is timing out after fetching certain messages but before
deleting them
There's a TCP/IP stalling problem under Redhat 6.0 (and possibly other
recent Linuxes) that can cause this symptom. Brian Boutel writes:
TCP timestamps are turned on on my Linux boxes (I assume it's now the
default). This uses 12 extra bytes per segment. When the tcp connection
starts, the other end agrees a MSS of 1460, and then fragments 1460 byte
chunks into 1448 and 12, because is is not allowing for the timestamp.
Then, for reasons I can't explain, it waits a long time (typically 2
minutes) after the ack is sent before sending the next (fragmented)
packet. Turning off tcp timestamps avoids the fragmentation and restores
normal behaviour. To do this, [execute]
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
I'm still unclear about the details of why this is happening. At least
[now] I am now getting good performance and no queue blocking.
====================
R10. Fetchmail is timing out during message fetches
This is probably a general networking issue. Sending a "RETR" command
will cause the server to start sending large amounts of data, which
means large packets. If your networking layer has a packet-fragmentation
problem, that's where you'll see it.
====================
Good luck !
Hall Stevenson
Reply to: