28 Jun
2018
28 Jun
'18
4:35 p.m.
I have updated the elproxy.tar.gz file on my webserver:
http://pe1chl.nl.eu.org/Softw/elproxy.tar.gz
There was a race condition in the code that ultimately resulted in some proxies being
stuck in the authentication
phase. It can be recognized by the debug info in square brackets appearing in the QSO
column
of the /dev/shm/elproxy status file, like [st4 fd20 t0]
It is normal when such info briefly appears, but when it remains for a few seconds that
proxy is stuck
into a BUSY state without an actual user. This can be checked using:
fgrep [st /dev/shm/elproxy
and when output appears, repeat it 30 seconds or so later and see if it is still there.
On our PI9NOZ proxies, after running 230 proxies for over two months, 6 proxies were
stuck.
Hard-to-locate problem...
Finally, Jann Traschewski has found this bug! Thanks for debugging it and mailing me the
patch!
The bookkeeping of the usage of filedescriptors was somehow getting out of sync (that I
already knew...)
and he found it happened in the error handling of TCP connections to the directory
server.
I had been looking in this area for quite some time, but somehow forgot about the fd used
for that
purpose and only traced all the paths of open/close of the fd used for the actual user
connection...
To update, re-fetch the elproxy.tar.gz and unpack (only elproxy.c is changed), re-run make
and re-start
the program (I run it from its /home/elproxy home directory, when you put it in
/usr/local/bin or similar
of course remember to move it there again)
This is the patchfile of the change, you can apply that using "patch
--ignore-whitespace elproxy.c" instead of
downloading it again.
--- elproxy.c.orig 2016-11-24 10:02:22.000000000 +0100
+++ elproxy.c 2018-06-26 23:43:22.908000000 +0200
@@ -1428,6 +1428,7 @@
buf[0] = 1;
close(fd);
+ pr->tcp_fd = 0;
} else {
ds->proxy = pr;
ds->timeout = now + ADDR_SOCKET_TIMEOUT;
@@ -1638,6 +1639,7 @@
close(fd);
unregisterfd(fd);
+ pr->tcp_fd = 0;
if (pr->state == BUSY)
proxy_message(pr,PROXY_MSG_TCP_CLOSE,0,NULL,0);
Again thanks to Jann for finding this!
Rob