Subject: Runaway Pine Processes

From: "Sherry H. Lake" <[email-masked]>
Date: Wed, 8 Feb 1995 15:29:29 -0500 (EST)

Machine: DEC 2100 (alpha) running OSF/1 3.0
Pine 3.91

Problem:  Users are not properly logging off their accounts and pine 
processes are eating between 10 and 60 % of the CPU.

I spoke to a few users, and they turned off their PC while still logged 
on and in the pine program.

Is there anything we can do (besides educating our users) with these
runaway jobs.  If the user was not in pine, and turned off their PC
without logging off, the login shell goes away once the connection is 
gone.  But because they are in pine, the login shell does not go away 
(and neither does the pine).

   Is this a feature of pine? :-)

----
Sherry H. Lake			[email-masked]
Electronic Mail Consultant
George Mason University

---

From: [email-masked] (Steve Holstead)
Date: 10 Feb 1995 18:28:24 GMT

Sherry H. Lake ([email-masked]) wrote:
: Machine: DEC 2100 (alpha) running OSF/1 3.0
: Pine 3.91

: Problem:  Users are not properly logging off their accounts and pine 
: processes are eating between 10 and 60 % of the CPU.

This is also happening on AIX3.25 with a default shell of tcsh. This 
problem is quite serious, due to our 400 concurrent users over 3 machines.

I did experience Sherry's problem in a OSF/1 2.0 environment, and the 
problem went away by changing the default shell to tcsh.

Any info would be *greatly* appericiated! 

--
______________________________________________________________________________

      Steve Holstead                      University of Alberta
  [email-masked]          Computer and Network Services
    Tel.: (403) 492-4854                  System Software Group
    Fax.: (403) 492-1729              #154 General Services Building
                                         Edmonton, Alberta T6G-2H1
                                               C A N A D A

---

From: Terry Gray <[email-masked]>
Date: Sat, 11 Feb 1995 17:54:49 -0800 (PST)

Steve,
On the AIX system, do you mean that if someone disconnects *and* their 
shell is tcsh, then Pine runs wild?  Or does it happen with tcsh even if 
you are not disconnected?

In contrast, are you saying that switching to tcsh *solved* the problem 
on OSF?

-teg

---

From: Steve Holstead <[email-masked]>
Date: Sun, 12 Feb 1995 12:27:37 -0700 (MST)

On Sat, 11 Feb 1995, Terry Gray wrote:

> shell is tcsh, then Pine runs wild?

That is correct. My experience on both OSF1/2.0 and AIX/3.25 has produced 
this annoyance. When users in the PC labs disconnect, pine spins out. 
The method of the disconnect was something to do with a Cntrl+X type of 
disconnect. I could do some more digging if it would help. 

> Or does it happen with tcsh even if you are not disconnected?
> 

Yes. I could recreate the problem with csh and OSF. By moving to tcsh, I 
was able to eliminate the problem. 

I did some tests with AIX and csh with earlier versions of pine without 
being able to recreate the problem. Now with pine3.91, I see the same 
problem I encountered with OSF. 

I was hoping that someone was aware of this problem and that there was a 
solution already out there. If you wish I could do some more testing of 
this?

---

From: [email-masked] (Steve Holstead)
Date: 12 Feb 1995 19:41:11 GMT

Terry Gray ([email-masked]) wrote:
: Steve,
: On the AIX system, do you mean that if someone disconnects *and* their 
: shell is tcsh, then Pine runs wild? 

Yes.

: Or does it happen with tcsh even if 
: you are not disconnected?

: In contrast, are you saying that switching to tcsh *solved* the problem 
: on OSF?

Yes

: -teg

: On 10 Feb 1995, Steve Holstead wrote:

: > Sherry H. Lake ([email-masked]) wrote:
: > : Machine: DEC 2100 (alpha) running OSF/1 3.0
: > : Pine 3.91
: > 
: > : Problem:  Users are not properly logging off their accounts and pine 
: > : processes are eating between 10 and 60 % of the CPU.
: > 
: > This is also happening on AIX3.25 with a default shell of tcsh. This 
: > problem is quite serious, due to our 400 concurrent users over 3 machines.
: > 
: > I did experience Sherry's problem in a OSF/1 2.0 environment, and the 
: > problem went away by changing the default shell to tcsh.
: > 
: > Any info would be *greatly* appericiated! 
: > 
: > --
: > ______________________________________________________________________________
: > 
: >       Steve Holstead                      University of Alberta
: >   [email-masked]          Computer and Network Services
: >     Tel.: (403) 492-4854                  System Software Group
: >     Fax.: (403) 492-1729              #154 General Services Building
: >                                          Edmonton, Alberta T6G-2H1
: >                                                C A N A D A
: > 
: >

---

From: [email-masked] (Andrew Bennett)
Date: Sun, 12 Feb 1995 23:57:08 GMT

>disconnect. I could do some more digging if it would help. 

I have seen similiar problems under BSDI and Pine 3.91.  A user disconnects,
and their Pine image goes hog-wild in the background, sucking up as much CPU
time as it can get.

>was able to eliminate the problem. 

All the problems on the machine I administer have been with the tcsh shell
and Pine.  Most of the users use tcsh anyways.

It is a most annoying problem, though.

Andrew
--
(c) 1995, Andrew Bennett
[email-masked], [email-masked]
<a href="http://hyperreal.com/~abennett/>My Page</a>

---

From: [email-masked] (Frank Yao)
Date: Mon, 13 Feb 1995 09:08:48 GMT

>and their Pine image goes hog-wild in the background, sucking up as much CPU

The former sysadmin at this side had pine aliased to a script that
would run pine, and then at the end of the session would check to see
if the sucker was still going.  I think he also killed the process if
it was, but he at least sent a message to the user, reminding them to
cleanup their pine processes.  

- frank

-- 
**********************************************************************
*  You may be right.  I may be crazy.  But it just may be a lunatic  *
*  you're looking for. 			- Billy Joel 		     *
*************************** Frank Yao, [email-masked] ******

---

From: Steve Holstead <[email-masked]>
Date: Mon, 13 Feb 1995 10:37:01 -0700

On Mon, 13 Feb 1995, John Andrea wrote:

> In comp.mail.pine you write:
> This is very interesting, i've always seen it happen on AIX and Ultrix
> and assumed it was a standard unix bug. Have you ever figured out what
> tcsh does differently ? Do you know if anyone has posed the question to
> IBM (or DEC) ?

I have not figured out why tcsh fixed the problem on OSF1/2.0 nor have I 
figured out why it doesn't fix the problem on AIX/3.25. I do however have 
it on my TODO list. I hope to get into this soon. 

I have talk to DEC. They say "Yeah, looks like a problem to me.". The 
trouble is, their response was to use tcsh. That is not my idea of a DEC 
fix. I fough with their support people for *6* MONTHS for a csh fix. 
Their reply was "thats the way csh is designed.". I gave up on DEC.

> 
> I find it happening to kermit when people hangup the phone too.

This could very well be related.

---

From: [email-masked] (Michael J. Ellis)
Date: 14 Feb 1995 01:26:36 -0500

>> tcsh does differently ? Do you know if anyone has posed the question to

Hey, you IBM and DEC people think you got all the fun :-)

I'm running a Sun SparcIIk with Solaris 2.4..... you got it,
the same problem. (with ksh)

I'm not sure what can be done about it, but if I come up with anything 
I'll post it here.

(my current solution is a script that kills certain things if that 
process is running without a user connected. (ie not in the "who" list).

I don't like this though, since with 200+ people online, this script does 
more harm than good...

Enjoy,

	MikeE
-- 
-------------------------------------------------------------------------------
Michael John J. Ellis             |
Systems Programmer                |            ZIMA ZUCKS!
SCT				  |

---

From: [email-masked] (Greg Fausak)
Date: 14 Feb 1995 14:04:02 GMT

I've been experiencing run-away imap processes on the hp.
Anybody else see this problem? The build and installation
were clean.

---greg
-- 
Greg Fausak, Chandelle Consulting, Inc.  V214-393-7976   [email-masked]

---

From: Chip Old <[email-masked]>
Date: Sat, 18 Feb 1995 08:23:09 -0500 (EST)

> processes are eating between 10 and 60 % of the CPU.
 
We're seeing the same problem here (Pine 3.91.SOL, SunSparc Server,
Solaris 2.3, ksh). 
 
--------------------------------------------------------------------
Francis E. Old (Chip Old)         Internet: [email-masked]
Internetworking Administrator     Voice:    (410) 887-6180
Baltimore County Public Library   FAX:      (410) 887-2091
320 York Road
Towson, Maryland 21204 USA

---

From: [email-masked] (jeff sumler)
Date: 22 Feb 1995 06:01:44 GMT

In article <[email-masked]>,
>Their reply was "thats the way csh is designed.". I gave up on DEC.

I've seen variations of this problem on every major unix platform -
hpux, ultrix, osf, aix, solaris . . . . Curses programs seem
particularly prone to it - tin and lynx (especially lynx) are both
problems for me - a user drops carrier or otherwise terminates
incorrectly and these programs run wild. Pine does this occasionally
under hpux and ultrix . . . perhaps once out of 27000 * 30 invocations
per month (on our primary mail host running hpux 9.04). Shell scripts
can also evince this behavior. I've seen sh scripts that have lost their
controlling tty and promptly eat the machine on which they're running.

Anyone dipped into the source yet to figure out what's going on ? I keep
pushing that job down to the "not very interesting" part of my list :)

jeff sumler
Systems Engineer, Indiana University

---

From: [email-masked] (J.J.Bailey)
Date: Wed, 22 Feb 1995 15:02:36 -0800 (PST)

> controlling tty and promptly eat the machine on which they're running.

I've seen this too.  In most cases it can be reduced to one or more of
these problems:

 The modem is connected to a logical device which doesn't send SIGHUP
 to processes associated with it when carrier is lost.

 The processes are ignoring SIGHUP.

 The modem is configured to force DCD high.

 The driver is configured to force DCD high.

-- 
J.J.Bailey
Consultant
[email-masked]