[771] in arla-drinkers
Re: arla hanging on freebsd 3.1-stable
daemon@ATHENA.MIT.EDU (Magnus Ahltorp)
Wed Apr 21 12:59:49 1999
From owner-arla-drinkers@stacken.kth.se Wed Apr 21 16:59:48 1999
Return-Path: <owner-arla-drinkers@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 29806 invoked from network); 21 Apr 1999 16:59:47 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 21 Apr 1999 16:59:47 -0000
Received: (from majordom@localhost)
by sundance.stacken.kth.se (8.8.8/8.8.8) id SAA10685
for arla-drinkers-list; Wed, 21 Apr 1999 18:53:27 +0200 (MET DST)
Received: from grey07.nada.kth.se (grey07.nada.kth.se [130.237.226.21])
by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id SAA10681
for <arla-drinkers@stacken.kth.se>; Wed, 21 Apr 1999 18:53:23 +0200 (MET DST)
Received: (from d95-mah@localhost)
by grey07.nada.kth.se (8.8.7/8.8.7) id SAA09784;
Wed, 21 Apr 1999 18:53:21 +0200 (MET DST)
To: "Paul Ewing Jr." <ewing@ima.umn.edu>
Cc: arla-drinkers@stacken.kth.se
Subject: Re: arla hanging on freebsd 3.1-stable
References: <199904211628.LAA09387@purple.ima.umn.edu>
From: Magnus Ahltorp <map@stacken.kth.se>
Content-Type: text/plain; charset="iso-8859-1"
Date: 21 Apr 1999 18:53:21 +0200
In-Reply-To: "Paul Ewing Jr."'s message of "Wed, 21 Apr 1999 11:28:11 -0500 (CDT)"
Message-ID: <ixdr9pdoqym.fsf@grey07.nada.kth.se>
Lines: 23
X-Mailer: Gnus v5.6.45/Emacs 19.34
Sender: owner-arla-drinkers@stacken.kth.se
Precedence: bulk
> It usually hangs while running configure. Sometimes I can run it
> serveral times in row without problems; other times it hangs on the
> first attempt. I can kill the configure process to get out of the
> hang, but from then an `ls -l' in that directory hangs. (Plain `ls'
> doesn't, so it's likely a stat() call that's hanging.) Everytime a
> process hangs, another arlad worker is used up. Eventually I run out
> of workers. Restarting arlad gets things working again.
>
> [...]
>
> Any idea what might be causing this?
Yes, this is most likely caused by a bug in the timeout mechanism. Rx
is keeping a timer (using setitimer/getitimer), and that timer is for
some reason reset. This should normally not happen, since the timer is
set to a timeout of about a year/several years.
My suspicion is that, somewhere, there is a call to setitimer after
the first one (with a lower value), but I cannot find such a call. I'm
currently working on this issue.
/Magnus
map@stacken.kth.se