From owner-freebsd-current Sun Aug 4 01:48:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA22813 for current-outgoing; Sun, 4 Aug 1996 01:48:05 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA22807 for ; Sun, 4 Aug 1996 01:48:02 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id SAA07448; Sun, 4 Aug 1996 18:29:04 +0930 From: Michael Smith Message-Id: <199608040859.SAA07448@genesis.atrad.adelaide.edu.au> Subject: Re: problem with -current system grinding to a halt... To: dg@root.com Date: Sun, 4 Aug 1996 18:29:03 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, current@freebsd.org In-Reply-To: <199608040744.AAA13305@root.com> from "David Greenman" at Aug 4, 96 00:44:46 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk David Greenman stands accused of saying: > > This can happen if your nameserver isn't reachable. Have you tried "w -n" ? > This disables the nameserver lookups and is useful for this specific problem. Nameserver lookup failures cause the whole system to grind to a halt, forcing a hard reset? Sorry, I know what nameserver timeouts look like, and that's not the problem. I wish it was. I should have been clearer I guess; the 'w' freeze was coincidental - the system dies _consistently_ after about 18 hours of uptime, with no console messages. Regardless of whether I'm logged in or not, and apparently unrelated to any specific system activity. I say 'apparently' because it's not easy to see exactly what the system is doing. We doubled the system's memory when it looked like heavy paging was a problem (it was), and now the system hardly pages at all. At the times when the hangs usually occur (around 6am) the system is as unloaded as it gets - there are no interactive users, and the background load which has been running nonstop since the system was booted. If there are any thoughts on possible resource leaks in the Linux emulation code, that'd give me somewhere to look. Other systems running the same load less the heavy IDL sessions have run happily for weeks with no signs of stress. > David Greenman -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[