From owner-freebsd-hackers Thu Nov 13 13:03:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA20675 for hackers-outgoing; Thu, 13 Nov 1997 13:03:48 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA20664 for ; Thu, 13 Nov 1997 13:03:40 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id NAA14850; Thu, 13 Nov 1997 13:03:07 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma014846; Thu Nov 13 13:03:01 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id NAA27953; Thu, 13 Nov 1997 13:03:01 -0800 (PST) From: Archie Cobbs Message-Id: <199711132103.NAA27953@bubba.whistle.com> Subject: Re: unkillable process In-Reply-To: <19971113154657.06089@milkyway.com> from Brian Campbell at "Nov 13, 97 03:46:57 pm" To: brianc@milkyway.com (Brian Campbell) Date: Thu, 13 Nov 1997 13:03:01 -0800 (PST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Campbell writes: > On Thu, Nov 13, 1997 at 10:48:17AM -0800, Archie Cobbs wrote: > > Simon Shapiro writes: > > > Hi Archie Cobbs; On 12-Nov-97 you wrote: > > > > 1. Create a named pipe > > > > 2. Start typing into it using cat > > > > 3. Hit control-C as many times as you want > > > > > > > > You'll see that the process will not die even with kill -9, > > > > as it is stuck in uninterrupible disk sleep ("fifo"). > > > > > > > > But as soon as you read from the other end of the pipe, > > > > the process exits. > > > > > > > > Is there a missing PCATCH flag to tsleep() somewhere? > > > > Is this appropriate behavior? (hint: rhetorical question) > > > > > > From what I remember, this is a typical (if ugly Unix behavior. > > > > Hmm... does anyone else besides me have the opinion that, > > while it may be typical, this behavior is also *broken*? > > I don't think my 2.2.5 system behaves as you describe. > > `mkfifo p; cat >p` followed by ^C complains about not being able to > create p. It does, however, interrupt immediately. If you type some > stuff before hitting ^C, cat still hasn't managed to open the fifo > (same complaint) but the command is still immediately interrupted. > > If you use `cat <>p` (to open the fifo read-write so the open doesn't > have to wait for a reader), the open will succeed and you can write > some data that will be readable by another process, unless you > interrupt it in which case the command immediately exits and the data > is lost. > > Perhaps you're seeing some funny behaviour due to your shell? You're right.. it must be a tcsh(1) problem... the following command hangs in tcsh but not sh: $ mkfifo p; cat > p ^C But it's still a kernel bug, no? The tcsh process is stuck in some kind of uninterruptible sleep, which is not appropriate here: UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 4042 4041 0 10 0 612 868 ppwait Ds p2 0:01.09 -tcsh (tcsh) 0 4177 4042 0 2 0 612 888 fifo SV+ p2 0:00.01 -tcsh (tcsh) I can kill the second process (pid 4177) but not the first (pid 4042), even with kill -9. -Archie P.S. How do you annotate a previously sent bug report? :-) ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com