[news.software.b] rrn fails if timeout on NNTP connection occurred

whna@ciba-geigy.ch (Heinz Naef) (07/17/90)

We experience various kinds of rrn failures if a timeout occurs on the
NNTP/IP connection while an rrn is running (sleeping) in a shelltool
window. 

Here is the last part of a trace:

[...]
ioctl (2, 0x8004747e, 0x24e46) = 0
write (1, "\33[7mEnd of article 415 (of 418)-".., 53) = 53
ioctl (0, 0x4004667f, 0x24e38) = 0
close (13) = 0
unlink ("/tmp/rrn415.9056") = 0
open ("/tmp/rrn416.9056", 03002, 0666) = 13
write (7, "HEAD 416\r\n", 10) = 10
read (3, "503 Timeout after 7200 seconds, ".., 4096) = 53
close (13) = 0
unlink ("/tmp/rrn416.9056") = 0
ioctl (0, 0x4004667f, 0x24e38) = 0
read (0, " ", 1) = 1
open ("/tmp/rrn416.9056", 03002, 0666) = 13
write (7, "HEAD 416\r\n", 10) = -1 EPIPE (Broken pipe)
- SIGPIPE (13)

For some reason rrn seems to continue using the NNTP connection even though
it must have recognized in get_server that the 503 response arrived. 
Shouldn't it go through termination processing (finalize) at this point?

By the way, after the crash the window remains in an insane state:

speed 9600 baud, 34 rows, 80 columns
parenb -parodd cs7 -cstopb -hupcl cread -clocal -crtscts 
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl -iuclc 
ixon -ixany -ixoff imaxbel 
isig -icanon -xcase -echo echoe echok -echonl -noflsh -tostop 
echoctl -echoprt echoke 
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel -tabs 
min 1, time 0
erase  kill   werase rprnt  flush  lnext  susp   intr   quit   stop   eof
^H     ^X     ^W     ^R     ^O     ^V     ^Z/^Y  ^C     ^\     ^S/^Q  

We are running NNTP 1.5.7 and rn level 47.

--
Heinz Naef, CIBA-GEIGY AG, R-1045.3.37, P.O.Box, CH-4002 Basel, Switzerland
 E-mail: whna@ciba-geigy.ch - Phone: +41 61 697 2675 - Fax: +41 61 697 3288

guy@auspex.auspex.com (Guy Harris) (07/19/90)

>By the way, after the crash the window remains in an insane state:

Actually, that tty state is quite sane from "rn"s standpoint - it's
"uncooked, no echo" mode, as you'd expect; the problem is that "rn" dies
without putting the old modes back.  It probably doesn't catch SIGPIPE
and restore the modes to what they were before it fired up.