Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Nov 1999 09:34:13 -0400 (AST)
From:      The Hermit Hacker <scrappy@hub.org>
To:        dante-misc@inet.no
Cc:        anders@fix.no, freebsd-questions@freebsd.org
Subject:   Re: iotimeout value in sockd.conf ...
Message-ID:  <Pine.BSF.4.21.9911300929160.77701-100000@thelab.hub.org>
In-Reply-To: <Pine.BSF.4.21.9911300858150.77701-100000@thelab.hub.org>

next in thread | previous in thread | raw e-mail | index | archive | help

Okay, I'm very confused, but what is the point of io_gettimeout()?

According to the select() man page on FreeBSD, timeout "specifies a
maximum interval to wait for the selection to complete", in this case, *I
believe*, that's the iotimeout value I have set to 3600, right?

Why does it parse it through:

static struct timeval *
io_gettimeout(timeout) 
        struct timeval *timeout;
{                               
        time_t timenow;         
        int i;
           
        if (allocated() == 0 || config.timeout.io == 0)
                return NULL;            
   
        timeout->tv_sec = config.timeout.io;
        timeout->tv_usec        = 0;

        time(&timenow);
        for (i = 0; i < ioc; ++i)
                if (!iov[i].allocated)
                        continue;
                else
                        timeout->tv_sec = MAX(0, MIN(timeout->tv_sec,
                        difftime(config.timeout.io, (time_t)difftime(timenow, iov[i].time))));
  
        return timeout;                         
}                

First, instead of just setting 'timeout' and passing that to select()?  
Don't I want the select() to "wait" iotimeout seconds from when it was
called?

On Tue, 30 Nov 1999, The Hermit Hacker wrote:

> 
> Okay, at least we've finally been able to narrow down *some* problem here,
> now the question is what :(
> 
> Below is the top of my 'kill -INFO' session as of today...same two
> processes are "stuck" in the queue...there are *alot* more then that
> stuck, but I didn't figure anyone wanted the whole list...
> 
> Nov 30 08:44:24 demeter sockd[778]: dante v1.1.0 up 4 days, 0:49, a: 8509, c: 2013
> Nov 30 08:44:24 demeter sockd[778]: negotiators (1): a: 8509, h: 8366, c: 0
> Nov 30 08:44:24 demeter sockd[778]: requests (7): a: 8366, h: 4562, c: 0
> Nov 30 08:44:24 demeter sockd[778]: iorelayers (255): a: 4562, h: 4562, c: 2013
> Nov 30 08:44:24 demeter sockd[784]: 131.162.148.236.1044 <-> 142.177.199.166.26184: idle 339703s
> Nov 30 08:44:24 demeter sockd[1044]: 131.162.167.146.1701 <-> 131.162.167.157.21241: idle 338093s
> 
> 
> A quick grep of the log file shows that sockd, at least, feels that the
> timeout is there:
> 
> grep timeout /home/log/sockd.log
> Nov 24 09:24:02 demeter sockd[96274]: negotiate timeout: 30s
> Nov 24 09:24:02 demeter sockd[96274]: I/O timeout: 3600s
> Nov 24 18:34:13 demeter sockd[311]: negotiate timeout: 30s
> Nov 24 18:34:13 demeter sockd[311]: I/O timeout: 3600s
> Nov 26 07:54:33 demeter sockd[778]: negotiate timeout: 30s
> Nov 26 07:54:33 demeter sockd[778]: I/O timeout: 3600s
> 
> But it doesn't look like sockd (under FreeBSD) is honoring it...
> 
> 'anders@fix.no' just created a FreeBSD port of this, so I'm CC'ng him in
> on this email, to see if if can back me up, or if this is specific to just
> me.  I've also CC'd freebsd-questions on this, in the hopes that there are
> *at least* a few FreeBSD users out there using Dante and who can check
> their setups...
> 
> I'm running 3.3-STABLE on that machine from November 2nd...and from
> checking the CVS repository for FreeBSD, there have been no changes to the
> select() call, that I can tell, since August 30th or so....
> 
> If someone wants to give me some sort of direction on how to go about
> using gdb to debug this particular problem, I'm open to suggestions, I can
> do really simple things on core files with gdb, but that is about it at
> this time...
> 
> On Tue, 30 Nov 1999, Michael Shuldman wrote:
> 
> > The Hermit Hacker wrote,
> > > 
> > > I just did a cursory scan of the sources, and can see where its loaded,
> > > but can't find where its actually used...
> > > 
> > > Looking at hte output from kill -INFO, I have processes that have been
> > > around "forever":
> > > 
> > > Nov 29 13:15:08 demeter sockd[778]: dante v1.1.0 up 3 days, 5:20, a: 6277, c: 1613
> > > Nov 29 13:15:08 demeter sockd[778]: negotiators (1): a: 6277, h: 6178, c: 0
> > > Nov 29 13:15:08 demeter sockd[778]: requests (7): a: 6178, h: 3629, c: 0
> > > Nov 29 13:15:08 demeter sockd[778]: iorelayers (203): a: 3629, h: 3629, c: 1613
> > > Nov 29 13:15:08 demeter sockd[784]: 131.162.148.236.1044 <-> 142.177.199.166.26184: idle 269547s
> > > Nov 29 13:15:08 demeter sockd[1044]: 131.162.167.146.1701 <-> 131.162.167.157.21241: idle 267937s
> > > 
> > > 
> > > Even though my iotimeout is set to 3600 ...
> > 
> > Afraid I can't reproduce your problem here either. :-/  I just
> > tested this:
> > 
> > Nov 30 09:31:19 sockd[17101]: I/O timeout: 10s
> > 
> > Nov 30 09:40:15 sockd[14383]: pass(5): connect: 195.139.68.62.15678 -> 195.139.68.62.7
> > 
> > Nov 30 09:40:25 sockd[9819]: tcp: 0 -> 195.139.68.62.15678 -> 0,  0 -> 195.139.68.62.7 -> 0: connection i/o expired
> > 
> > openbsd2.3/i386 0$ date; socksify test/nc/nc bastesen 7 ; date
> > Tue Nov 30 09:40:15 CET 1999
> > Tue Nov 30 09:40:25 CET 1999
> > openbsd2.3/i386 0$ 
> > 
> > i.e. as you see the session was closed by the server 10 seconds
> > after it started. 
> > 
> > As for where it's used, run_io() (is the function that controls
> > the io process) has two select() calls, the last argument to both
> > is the timeout (of course), which is returned by io_gettimeout().
> > If you are able/have the time, you might try attaching to a io
> > process with gdb and try and see what is wrong.
> > 
> > 
> > -- 
> >   _ // 
> >   \X/ -- Michael Shuldman <michaels@inet.no>
> > 
> > 
> 
> Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
> Systems Administrator @ hub.org 
> primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 
> 
> 

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.9911300929160.77701-100000>