Subject: moo cpu hog with closed sockets?

From: Jacqueline Hamilton <[email-masked]>
Date: Tue, 11 May 1993 09:22:32 -0700

I've just booted up a moo (1.7) on an HP (HP-UX feenix A.08.07 A 9000/705)
and have noticed what seems to be a serious problem.  I dont know if
this is a problem with my compiled version on the HP, or if it's common
to moos, but one thing's for sure - we can't run a moo there with this
sort of thing happening.

Here's the situation:  if a player gets netburped, or disconnects without
quitting, the moo immediately starts crunching up the cpu time, and a look
at 'netstat' shows the connection in a 'close_wait' state.

Some info:

[10:32:52] Load averages: 0.98  0.43  0.32.  Pages: 0 -   0.00% Idle
65 Processes: 61 Sleeping, 2 Running, 1 Stopped, 1 Zombie, 0 Others.
Memory:   8.57M  (   3.01M ) real,    7.37M  (   2.83M ) virtual,  25.05M free

S  USER      SUID  PID  NI PRI    SIZE     RSS  %WCPU    TIME CMD
R kira        303 20053 20 227   2.19M   1.88M 98.21%   18: 7 moo <----
R srl         202  6216 20 178    388K    376K  0.73%    0: 1 yamm
S bobf       1002  5034 20 154     64K    108K  0.16%    0: 8 telnet
S wjm        1000  4838 20 156    192K    132K  0.00%    0: 1 NewsMeister
S srl         202 28970 20 168    204K    160K  0.00%    0: 0 -csh
S parag       236  4445 20 158    280K     76K  0.00%    0: 0 -ksh
S ftp         500   224 20 154    296K    148K  0.00%    0: 6 gopherd
T bobf       1002  3449 20 178     80K    136K  0.00%    0: 0 telnet
S bobf       1002  1592 20 168    440K    256K  0.00%    0: 4 -tcsh
S parag       236  4456 20 154     80K    132K  0.00%    0: 2 telnet
Z ftp         500  5696 20 181      0K      0K  0.00%    0: 0 gopherd

Active Internet connections
Proto Recv-Q Send-Q Local Address          Foreign Address        (state)
tcp    0    335  feenix.ftp-data        cc4.kuleuven.ac.be.1479
                                                                 FIN_WAIT_1
tcp    0      0  feenix.ftp             cc4.kuleuven.ac.be.1468
                                                             ESTABLISHED
tcp    0      3  feenix.3851            pip.shsu.edu.2222      ESTABLISHED
tcp    0      0  feenix.3673            csclass.utdallas.edu.telnet
                                                                 ESTABLISHED
tcp    0      0  feenix.telnet          CORPGATE.NT.COM.2805   ESTABLISHED
tcp    0      0  feenix.8888            widcat.Widener.EDU.3438
                                                                 ESTABLISHED
tcp    0      0  feenix.3599            pip.shsu.edu.telnet    ESTABLISHED
tcp    0      0  feenix.8888            smd6.jsc.nasa.gov.4381 CLOSE_WAIT<----
udp    0      0  feenix.domain          *.*
udp    0      0  127.0.0.1.domain       *.*

Something about this close_wait connection... I had been netburped off 
the moo at around 10:30.  Tried an experiment later on by quitting emacs
without logging off.  Same thing happened... cpu usage skyrocketed from
0.15% to 35% to 52% on up.

On a side note, perhaps related, perhaps not:  after initally compiling
the moo on the HP, I was able to boot up the server, but could not 
connect - all connections were immediately disconnected.  Someone advised
me to change line 65 of net_bsd_tcp.c to :

    proto->believe_eof = 0;

(previous value was 1), and things worked again.  I dunno if this is
related to the cpu problem or not.

Anyone have any advice on how to keep the moo from chewing up the cpu
on closed connections?  I'd prefer if disconnected players were really
disconnected; I don't know why the moo keeps them "connected" in some
fashion, but it's definitely giving the moo a bad name here, as nobody
is too pleased about 98% cpu usage from a moo.

Thanks.

-j.

---

From: Pavel Curtis <[email-masked]>
Date: Tue, 11 May 1993 16:08:33 -0700

> Date:	Tue, 11 May 1993 09:22:32 -0700
> From:	Jacqueline Hamilton <[email-masked]>
> 
> ...

This is your problem.  The server is now in a constant reading loop for all
remote-disconnected users since it never believes that the far side has closed
the connection.  I don't know why things didn't work before you changed this,
but the fix was wrong.  I'll contact you directly to see about looking more
closely at the original problem (which is looking like a bug in HP/UX right
now).

	Pavel