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

On Sun, 2003-09-07 at 19:40, gregory mott wrote: 
> 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

fwiw the following tweaks have made no difference:

  #  cd /proc/sys/net/ipv4
  #  echo 60   >| ipfrag_time
  #  echo 6000 >| inet_peer_maxttl
  #  echo 6000 >| inet_peer_minttl
  #  echo 0    >| tcp_timestamps


-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list

Reply via email to