Subject: Pine running wild when user's session disconnected

From: [email-masked] (Richard L. Hamilton)
Date: 2 Nov 1994 00:56:46 -0500

I've noticed pine processes associated with users whose sessions
ended with either a non-zero return code or a hangup signal running
wild, i.e. apparently looping to no particular end, and eating CPU time
(some hours after the login session had been terminated).

I've got a wild guess that where it is looping is line 392 of
pine3.91/pine/ttyin.c, i.e.:

         if(errno == EINTR)
           return(NO_OP_COMMAND);

Now, since errno is *not* cleared by successful calls, there is currently
no way to know whether this test is being satisfied as a consequence of
the read() call on line 381, that is:

     res = read(STDIN_FD, &c, 1);

If my wild guess is right, adding:

     errno = 0;

*before* the read() call in line 381 should take care of it.

Now for the bottom line:

1. has anyone had similar problems?

2. any comments on the possible explanation/fix?

FYI, this is happening on a system running DG/UX ("./build d-g").
And the printer problems are happening there too, not that I think
that relates to the problem I'm bringing up.
-- 
                      I compute, therefore I am.
My opinions are strictly by own, and should not be construed to represent
anyone else.

---

From: Mike Brudenell <[email-masked]>
Date: Fri, 4 Nov 1994 09:12:31 +0000 (GMT)

Yes, we've seen similar behaviour (a looping Pine) here on our SGI platforms.

Interestingly, some sessions go into tight CPU burning loops, whilst 
others just sit clocking up about a seconf od CPU every eleapsed minute 
or so.  I haven't managed to isolate what people did to get into that state.

I have also had similar problems with imapd's, which may point the finger 
elsewhere as well/instead of the source you suggest.

Mike Brudenell
------------------------------------------------------------------------------
The Computing Service, University of York, Heslington, York, YO1 5DD, UK
Phone: +44-1904-433811  FAX: +44-1904-432767

---

From: Barry Cornelius <[email-masked]>
Date: Fri, 4 Nov 1994 15:52:57 +0000 (GMT)

> or so.  I haven't managed to isolate what people did to get into that state.

In 3.90, we had a lot of runaway processes on SunOS 5.3 but none on our
HP-UX 9000/{710,730,750} boxes (that I recall).

Since 3.91, most of our problems have been with left-over dormant
processes that don't eat up time.  All of these have appeared with HP-UX
9.01 (but not with SunOS 5.3).  We currently have about 12 HP-UX
workstations with such processes.  If another user tries to run a Pine
session, then on 10 of the 12 this is OK whereas on the other 2 it led to
an error message like: 
   Pid Killed Text I/O modification
or some words like that.  I have just killed processes on the two whereas I 
have done nothing with the 10 yet (as they are relatively harmless!).

--
Barry Cornelius                      Telephone: (0191 or +44 191) 374 4717
IT Service, Science Site,    IT Service Office: (0191 or +44 191) 374 2892   
University of Durham,                      Fax: (0191 or +44 191) 374 3741
Durham, DH1 3LE, UK                   E-mail: [email-masked]

---

From: [email-masked] ()
Date: 6 Nov 1994 00:29:08 GMT

Richard L. Hamilton ([email-masked]) wrote:
: I've noticed pine processes associated with users whose sessions
: ended with either a non-zero return code or a hangup signal running
: wild, i.e. apparently looping to no particular end, and eating CPU time
: (some hours after the login session had been terminated).

: I've got a wild guess that where it is looping is line 392 of

We've had no problems with 3,89 or 3.90, but have noticed this with 3.91. 
We are running Linux 1.1.59 and are not running imapd.  I'm not sure what
caused the entry into the loop, but I have noticed a pine process
belonging to a disconnected user eating processor time on 2 different
occasions in the last week. 

George Nemeyer
System Administrator
Tigerden.com

---

From: [email-masked] (Klaus Desinger)
Date: 6 Nov 1994 02:36:52 +0100

>We are running Linux 1.1.59 and are not running imapd.  
[...]

We're still at 3.87 on Sun's Solaris. Same problem here.
Any pointers are appreciated.

Klaus

-- 
Klaus Desinger                           email [email-masked]
Rechenzentrum Garching               annoyance number +49 89-3299-2168