Date: Thu, 13 Nov 1997 13:03:01 -0800 (PST) From: Archie Cobbs <archie@whistle.com> To: brianc@milkyway.com (Brian Campbell) Cc: hackers@freebsd.org Subject: Re: unkillable process Message-ID: <199711132103.NAA27953@bubba.whistle.com> In-Reply-To: <19971113154657.06089@milkyway.com> from Brian Campbell at "Nov 13, 97 03:46:57 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711132103.NAA27953>