From owner-freebsd-questions Tue Nov 30 5:23: 1 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 5342514DC1 for ; Tue, 30 Nov 1999 05:22:57 -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 JAA80570; Tue, 30 Nov 1999 09:22:49 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Tue, 30 Nov 1999 09:22:48 -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: <19991130094608.64999@bastesen.inet.no> 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, 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message