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>