ty for answering, i should have mentioned before, my previous experience with heavy dialup traffic has shown that round trip time for pings can be longer than 15 seconds for sure, possibly longer than 30. so i expect that i'm on the hunt for some timeout that is not waiting long enough.
also fetchmail exitcode=2 (socket error) means "An error was encountered when attempting to open a socket to retrieve mail." so i suspect there's some timeout somewhere relevant to opening a connection. so if anyone has an idea where to look.. tia, -greg On Fri, 2003-09-05 at 23:46, Sean Estabrooks wrote: > On 05 Sep 2003 12:32:15 +0100 gregory mott <[EMAIL PROTECTED]> wrote: > > hi redhatters, > > > > fetchmail has a parameter for timeout, but apparently that parameter > > doesn't affect whatever timeout results in exitcode=2, socket error. > > > > i bet the relevant timeout is in the kernel, not fetchmail? > > > > this is happening alot when our dialup is busy with other things, like > > rsync, or up2date, or other traffic between lan and internet.. > > > > any idea where to cast the tweaking eye? > > Hi Gregory, > > The default keepalive values will let a connection persist > for over 11 minutes without an answer. If this is what is > causing your disconnects you have some _serious_ > congestion. Perhaps it's something else but you can > take a look at /proc/sys/net/ipv4/tcp_keepalive_* > > Also, from the fetchmail FAQ: > > 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. > > It also recommends disabling tcp_timestamps if you see > timeout problems: > > echo 0 > /proc/sys/net/ipv4/tcp_timestamps > > Good luck, > Sean -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list