From owner-freebsd-questions  Fri Nov 10 19:44:47 1995
Return-Path: owner-questions
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id TAA27058
          for questions-outgoing; Fri, 10 Nov 1995 19:44:47 -0800
Received: from irbs.irbs.com (irbs.com [199.182.75.129])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA27051
          for <questions@freebsd.org>; Fri, 10 Nov 1995 19:44:39 -0800
Received: (from jc@localhost) by irbs.irbs.com (8.6.12/8.6.6) id WAA04872; Fri, 10 Nov 1995 22:43:04 -0500
From: John Capo <jc@irbs.com>
Message-Id: <199511110343.WAA04872@irbs.irbs.com>
Subject: Re: INN and FreeBSD 2.0.5
To: pete@puffin.pelican.com (Pete Carah)
Date: Fri, 10 Nov 1995 22:43:03 -0500 (EST)
Cc: msmith@atrad.adelaide.edu.au, questions@freebsd.org
In-Reply-To: <m0tDxxK-0000ReC@puffin.pelican.com> from "Pete Carah" at Nov 10, 95 10:13:00 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1633      
Sender: owner-questions@freebsd.org
Precedence: bulk

Pete Carah writes:
> 
> In article <199511090030.AAA08171@genesis.atrad.adelaide.edu.au> you write:
> 
> >Richard W. Gross stands accused of saying:
> >> I have problems with my news machine with the following:
> --
> >> Nov 8 14:20:16 inout /kernel: pid 21668: sh: uid0: exited on signal 11
> >> ---
> 
> >Sounds like hardware problems; sig11 is a great indicator of bad memory.
> 
> If he's running INN, it is a well-known problem; you can't run innwatch
> with the freebsd default shell; you *MUST* use bash (maybe pdksh, but
> bash certainly works).  (there is apparently a problem with how ash
> handles IFS; there may be more problems too; several INN scripts count
> on non-standard IFS and innwatcch is one of them).
> 
> >> And one of the hard drives starts seeking back and forth...
> 
> >Is it actually doing anything?
> Yes, saving core files of the shell about once/second.  Good for keeping
> nearly anything else from happening.
> 
> >> Any ideas what this means?
> 
> >What hardware are you running? 
> 
> Not relevant.  Go and put #!/bin/bash (or whatever your path to bash is)
> in the top of *all* the INN scripts in place of #! /bin/sh and the
> problem will go away.
> 
> This should be documented in our port of INN (which I have never used,
> preferring to customize a bit from the distribution so as to get
> the streaming patch in and such.)
> 
> -- Pete
> 

There was a bug that was tickled by this loop in innwatch.  It has been
fixed in 2.1 and -current.  I have not had an innwatch problem since.

while { sleep ${NEXTSLEEP} & wait; } ; : ; do
    NEXTSLEEP=${SLEEPTIME}
...


John Capo
IRBS Engineering