From owner-freebsd-questions Tue Nov 30 5:34: 6 1999 Delivered-To: freebsd-questions@freebsd.org Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191]) by hub.freebsd.org (Postfix) with ESMTP id 3CAA614DC1 for ; Tue, 30 Nov 1999 05:34:00 -0800 (PST) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id JAA80608; Tue, 30 Nov 1999 09:34:13 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Tue, 30 Nov 1999 09:34:13 -0400 (AST) From: The Hermit Hacker To: dante-misc@inet.no Cc: anders@fix.no, freebsd-questions@freebsd.org Subject: Re: iotimeout value in sockd.conf ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 > > > > > > 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