rnews processes sleeping on connect

[Nick Burrett]

INN version 2.4.1, destination news server is INN 2.4.0.

The use of 'fgets' in lib/remopen.c::NNTPconnect() occasionally gets 
stuck whilst waiting for a reponse string from the news server, during 
a run of 'rnews':

(gdb) bt
#0  0xffffe002 in ?? ()
#1  0x420d23f3 in read () from /lib/tls/libc.so.6
#2  0x421328d4 in __DTOR_END__ () from /lib/tls/libc.so.6
#3  0x4206e382 in _IO_file_read_internal () from /lib/tls/libc.so.6
#4  0x4206d67c in _IO_new_file_underflow () from /lib/tls/libc.so.6
#5  0x4206fe1d in _IO_default_uflow_internal () from /lib/tls/libc.so.6
#6  0x4206facd in __uflow () from /lib/tls/libc.so.6
#7  0x42063308 in _IO_getline_info_internal () from /lib/tls/libc.so.6
#8  0x42063203 in _IO_getline_internal () from /lib/tls/libc.so.6
#9  0x42061fc5 in fgets () from /lib/tls/libc.so.6
#10 0x0805de1b in NNTPconnect (host=3D0x806c738 "\210$=AD=FB", port=3D433, 
FromServerp=3D0xfffffe00, ToServerp=3D0x1000, errbuff=3D0xbffff250 "") at 
remopen.c:179
#11 0x0804afdd in OpenRemote (server=3D0xbfffff7b "my.news.server", 
port=3D-512, buff=3D0xbffff250 "") at rnews.c:775
#12 0x0804b323 in main (ac=3D0, av=3D0xbffff250) at rnews.c:886
(gdb)

If left unchecked, I find that the number of stalled 'rnews' processes 
grows somewhat:

-bash-2.05b$ ps auxfw | grep -c rnews
851

Would it not be better to simply to use the unbuffered read() function 
directly on the socket descriptor rather than buffering through stdio ? 
At least in the case of the former, we could apply better timeouts to 
the read operations, or close off a read-operation quicker if we start 
to receive unexpected information.

I notice that the CURRENT snapshot still uses the same fdopen/fgets 
combination of calls.

Any comments or thoughts ?


Regards,


Nick.


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.