Subject: Re: pine not quitting on HUP

From: Joe Brennan <[email-masked]>
Date: Fri, 25 Mar 94 9:46:25 EST

J. Paul Holbrook wrote--
> Joe Brennan reported a problem with Pine exiting properly.
> Iwant to note that we've seen this problem quite freqently, on the order 
> of several times per week on our system of nearly 500 accounts.

We have 9000 accounts on a cluster of 8 Suns (5 login timeshares, 2
file servers, 1 mailhub).  We saw 20 problems per day.  This did not
happen with pine 3.05, the previous version we used.  The fix
described to pine-bugs by Marg Suarez of our staff has dropped that to
less than 1 per day.

We could not replicate the problem either and relied on the
.pine-debug files, gdb, and asking people until we got a few who had
clear memories.  You have to get disconnected just when pine is doing
an "important" operation like a file write.  It could probably be
replicated if you have the patience to try over and over.

It wasn't clear to me what was being done with our fix.  Hey guys, do
you want the diffs Marg offered?  Will this be in the next version?

Joseph Brennan     Academic Information Systems
                   Columbia University in the City of New York
                   [email-masked]

---

From: Joe Pollock <[email-masked]>
Date: Fri, 25 Mar 1994 10:23:07 -0800 (PST)

We're seeing this same problem on a regular basis, also.  It was quite 
common in 3.07, and still seems to be happening in 3.89, although because 
of Spring Break this rev is still untested by the masses... :-)

It's most common on modem dial-ups.  The two major factors seem to be 
user error and data communication problems.

1.   Our users, when confronted with a screen of garbage or non-response from
     their session, respond with a push of the reset button or hanging up of
     connection.  I keep working on this, but have had little success.  
     Ususlly, they will try some random sequence of ctrl-c, ctrl-z, 
     ctrl-q, ctrl-d, esc, - everything they have ever used to get out of 
     a program.  They are NOT comfortable with UNIX.  They don't understand
     the concept of logging off, and that turning off their computer doesn't
     do that for them. 

2.   If there is a severe data communication disruption, such as 9600 baud
     modems attempting to renegotiate the connection because of line noise,
     pine (actually, usually pico) hangs, and the connection breaks anyway,
     leaving a hung session that can often be captured by the next 
     dial-in on that port.  And this kind of disruption happens quite 
     often, usually when someone picks up an extension on the modem line.
     My guess is that the random data spewed out during a modem
     renegotiation puts pico into just the state required to generate a
     hang.  In fairness to the Pine folks, though, it should be noted that
     much of UNIX is vulnerable to severe errors from random data entry.

     Interestingly, the lock behavior of Pine 3.89 appears to exacerbate 
the problem.  At least with the older versions users were confronted with 
a locked inbox when they logged back in, and knew they had a problem.  
Now they just go on their way, and never realize they have another 
session active.  I've considered a process check at login, but need to 
think carefully about it to avoid confusing the issue further.

     This begins to depart a bit from pine-related information, but may 
help some sites with this problem.  We have a very complicated 
data-communications path - the dial-up modems are on a Micom data PBX 
which connects users to the terminal servers.  Although the connections 
appear correct, and a static hangup works fine, as does unplugging the 
phone line, etc., during a renegotiation attempt the resulting race 
conditions appear to break the hangup sequence, and the result is that 
the connection is maintained from the modem through the PBX and the 
terminal server.  The only connection dropped is the phone line.

     We plan to eliminate the Micom this summer, and go to modems 
directly on a terminal server in the hope of eliminating this problem.
I have some doubts, however.  My users have never failed to find a way to 
generate totally-unanticipated errors.

Joe Pollock
The Evergreen State College
Olympia, WA 98505