Bug 14932

Summary: "more" eating up CPU on users with shell=/bin/sh if telnetd disconnects
Product: Base System Reporter: bruce <bruce>
Component: miscAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description bruce 1999-11-17 01:30:00 UTC
On 3.3 RELEASE, on a user with login shell of /bin/sh,
if a user runs "more /etc/passwd" (or something) and then
has their /bin/sh or telnetd killed (either manually with
kill -9 or if the telnetd keepalive mechanism terminates a
disconnected connection) "more" starts spinning, and quickly goes to
the top of "top", eating 50% CPU or more

Fix: 

2 fixes known...

 - use login shell = /bin/csh
 - use 3.1 RELEASE
How-To-Repeat: set login shell = /bin/sh
login
type
  more /etc/passwd
walk away after one screenful, go to another terminal, from
root determine their parent /bin/sh or telnetd, and kill
it with SIGKILL.  Run "top" and see "more" chugging

Problem is repeatable on 3 different boxes, and I received a
response from offsite from Douglas Hedges <hedges@atlantic.edu>
who repeated the problem on 3.3R.  Also had feedback from offsite from
Sheldon Hearn <sheldonh@uunet.co.za> who tried 3.3 STABLE and could
*not* repeat the problem.
Comment 1 Sheldon Hearn 1999-11-17 10:53:08 UTC
On Tue, 16 Nov 1999 17:26:16 PST, bruce@engmail.uwaterloo.ca wrote:

> On 3.3 RELEASE, on a user with login shell of /bin/sh, if a user
> runs "more /etc/passwd" (or something) and then has their /bin/sh
> or telnetd killed (either manually with kill -9 or if the telnetd
> keepalive mechanism terminates a disconnected connection) "more"
> starts spinning, and quickly goes to the top of "top", eating 50% CPU
> or more

Hi Bruce,

As per my message sent earlier, please test with with 3.3-STABLE.
I can't reproduce the problem with 3.3-STABLE, and if a problem in
3.3-RELEASE doesn't exist in 3.3-STABLE, there's nothing we can do about
it now.

Also, note that the problem is not that more "eats up CPU" -- I'm pretty
sure it's just spinning on input, so if the system got busier, you'd
probably find that the CPU usage of the more processes would flatten
out.

The problem is simply that the children of the shell process should die
when you kill the shell.

Ciao,
Sheldon.
Comment 2 bruce 1999-11-19 18:42:01 UTC
The problem persists on 3.3 STABLE from Nov 17.   Our e-mail server,
which is heavily loaded regularly (load average 5-10
quite often), is pushed over the edge once a few "more" processes start
spinning, and the load average can climb to
20 or 30, rendering the e-mail server unuseable for all practical
purposes.

On our test machine that we upgraded to 3.3 STABLE, the source for
/bin/sh is unchanged from 3.3 RELEASE.

The source for /usr/bin/more has a number of changed files on Nov 17.

Results on test machine...

# uname -a
FreeBSD elsinore.uwaterloo.ca 3.3-STABLE FreeBSD 3.3-STABLE #0: Thu Nov
18 13:36:03 EST 1999
root@elsinore.uwaterloo.ca:/usr/src/sys/compile/ELSINORE  i386

# ps waux | grep junk
root    11183  0.0  1.3   876  380  p6  D+    1:03PM   0:00.01 grep junk

junk    11177  0.0  0.9   500  256  p5  Ss    1:02PM   0:00.03 -sh (sh)
junk    11178  0.0  1.8   860  508  p5  S+    1:02PM   0:00.01 more
/etc/passwd

# kill -KILL 11177
# !ps
ps waux | grep junk
junk    11178  7.1  1.7   860  492  p5- R     1:02PM   0:01.61 more
/etc/passwd
#

"top" outout...

  PID USERNAME PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU COMMAND

11178 junk     100   0   860K   492K RUN      7:21 98.97% 98.97% more
Comment 3 Tim Vanderhoek 2000-05-09 05:12:44 UTC
On Tue, Nov 16, 1999 at 05:26:16PM -0800, bruce@engmail.uwaterloo.ca wrote:
> 
> >Description:
> On 3.3 RELEASE, on a user with login shell of /bin/sh,
> if a user runs "more /etc/passwd" (or something) and then
> has their /bin/sh or telnetd killed (either manually with
> kill -9 or if the telnetd keepalive mechanism terminates a
> disconnected connection) "more" starts spinning, and quickly goes to
> the top of "top", eating 50% CPU or more

I've fixed more to exit after it reads two EOFs, but the more serious
problem here, of course, is that /bin/sh isn't propogating signals
correctly.

The updated more is in -current and 4-stable.  I'm not sure if I'll
merge it all the way back to 3-stable unless you need it there.  Being
from the evil university, you'd have to ask really really nicely...  ;-)


-- 
Signature withheld by request of author.
Comment 4 hoek freebsd_committer freebsd_triage 2000-05-13 14:59:40 UTC
State Changed
From-To: open->closed

Appears fixed in all current versions of FreeBSD.