rnews processes sleeping on connect
Nick Burrett
nick at sqrt.co.uk
Mon Jul 25 12:49:11 UTC 2005
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.
More information about the inn-bugs
mailing list