Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Nov 1999 09:22:48 -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.9911300858150.77701-100000@thelab.hub.org>
In-Reply-To: <19991130094608.64999@bastesen.inet.no>

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

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 



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.9911300858150.77701-100000>