🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.bash.bug
Article #397

Re: Runaway bash

#397
From: Jason S. Molenda
Date: Sun, 30 Jul 1989 18:47
55 lines
2712 bytes
bfox@AUREL.CALTECH.EDU (Brian Fox) writes:


>   Date: Wed, 26 Jul 89 15:20:30 -0400
>   From: James J Dempsey <jjd@bbn.com>

>   I have had over a dozen cases where a bash of mine gets into some very
>   tight infinite loop and eats up gobs of cpu time.  I have tried to get
>   a core dump, but the only signal they will respond to is SIGKILL, so I
>   have been unsuccessful.


>The only thing that comes to mind is that bash is trying to do some
>output, (or read some input) and just keeps trying instead of getting
>blocked, or stopped, or something.

>If these runaway shells won't respond to SIGTSTP or SIGSTOP, then it is
>likely that they are login shells.

>If anyone gets more information on this problem, I would like to hear
>about it.

>Brian

I've had this happen to me twice.  Once on our Sequent Symmetry S27
running a BSD 4.3-similar OS and once on one of our NeXT cubes.

As James noticed, it is not easy to notice when one of these processes
start..  If you're using a single-CPU machine it just starts to act
very sluggishly.

The only difference is that when it happened on the Sequent, the bash
process had no controlling terminal (e.g. there was a "?" reported for
the terminal by a "ps aux").  When it happened on the NeXT yesterday,
there was a controlling terminal (/dev/ttyp1).

The only similarity was that I'm pretty sure I was using windowing
systems both times (X on the sequent and the NeXT environment on the
NeXT), and as we all know occasionally something can go wrong when
you're working in one of those windowing environments and the whole
thing can crash really quickly...  so I'm thinking that maybe the
bash programs managed to ignore some kind of signal that they were
sent.

Both times they appear to be polling for input; they definitely
aren't blocked.  On the sequent where we have top, I saw the bash
process eating up 98% of the CPU time on one of our processors.  On
the NeXT it had accumulated about 27 minutes of cpu time before I
figured it out.

-------
Jason Molenda,  University of Minnesota, Computer Science dept.
Internet:       molenda@umn-cs.cs.umn.edu,
Uucp:           ..!rutgers!umn-cs!molenda
Real life:      "hey you!"
Technical Details
Message-ID: <14839@umn-cs.CS.UMN.EDU>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uakari.primate.wisc.edu!indri!nic.MR.NET!umn-cs!molenda
References: <8907261931.AA29540@life.ai.mit.edu> <8907271354.AA29470@aurel.caltech.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uakari.primate.wisc.edu!indri!nic.MR.NET!umn-cs!molenda
From: molenda@umn-cs.CS.UMN.EDU (Jason S. Molenda)
Newsgroups: gnu.bash.bug
Subject: Re: Runaway bash
Message-ID: <14839@umn-cs.CS.UMN.EDU>
Date: 30 Jul 89 18:47:17 GMT
References: <8907261931.AA29540@life.ai.mit.edu> <8907271354.AA29470@aurel.caltech.edu>
Distribution: gnu
Organization: University of Minnesota, Minneapolis
Lines: 55