u2t spawns living+zombied copies of self! & u2t log format?

Eating Before Swimming (mathboy@sizone.org)
Fri, 16 May 1997 22:31:31 -0400 (EDT)


I'm running my primary u2t gateway on NetBSD for our effort. It seems
that once in a while one of the perl scripts kinda gets stuck... there
are 3 running u2t scripts right now. Sometimes they disappear.

But sometimes they dont. In fact 5 of them have Zombied.

Is this because the master server connection flaky right now? It seems
that some of my clients are not getting key blocks right after they're
done, it might be taking a couple tries.

Wondering if anyone has experienced this and what they've done about
it. The zombies dont take any mem so thats ok, mebbe they're just finished
but zombied for a blocked child process stuck on a busy master server??

Is this a problem I should worry about?

** I THINK IT IS. While I was writing this I saw the tail -f u2t log
file flash like 20 lines up the screen. *SEE END OF MY POST BELOW*
(Matt C. and Justin will be interested in this) - the duplicate u2t
living gates are ALL getting responces and applying for keys, this
will block 3 times more of the keyspace up at once!

------------------------------------------------------------------------------
And, while we're at it, does anyone know the FORMAT of the u2t log files?
I think they're pretty easy when the master is working ok, but when
its not, things are strange. (TCP reply seems to mean to me "master server's
reply" to my proxy, but I got those when I couldnt connect my deschall
clients DIRECTLY to the server, so ... but then mebbe the HTTP/TCP master
gateway CAN serve keys at that moment while my clients cant talk to it...
I dunno).

Am I right in assuming the two numbers that I get in the TCP request
like "29 (buncha stuff) 30" means something like "I need 29 now and when
Im done that, I'll go to 30?" What about what was just completed.

------------------------------------------------------------------------------
My logfile sample from

nohup nice deschall-u2t.pl solar.upowered.org >> proxy.log 2&>1 &

U2T 2803: connection from solar.upowered.org [207.61.18.200] at port 2731 at Fri May 16 22:19:29 1997
U2T 2803: connection from deceit.sizone.org [209.50.72.20] at port 1227 at Fri May 16 22:19:29 1997
U2T 2803: connection from deceit.sizone.org [209.50.72.20] at port 1227 at Fri May 16 22:19:29 1997
U2T 2803: connection from deceit.sizone.org [209.50.72.20] at port 1227 at Fri May 16 22:19:30 1997
U2T 3229: sent TCP request: N2[FFFFFFFF/53091AE4] 29 A2 - - - 61024A1F01010101 D5C6D2409B7B4442 30 at Fri May 16 22:19:30 1997
U2T 3228: sent TCP request: N2[A9B87A6E/0FD2A71F] 28 A2 - - - 6425797C80010101 D0E1E1231A7B4442 29 at Fri May 16 22:19:30 1997
U2T 3231: sent TCP request: N2[FFFFFFFF/4E15D374] 29 A2 - - - 61025B4A01010101 D5C6C3159B7B4442 30 at Fri May 16 22:19:30 1997
U2T 3230: sent TCP request: N2[FFFFFFFF/4E15D374] 29 A2 - - - 61025B4A01010101 D5C6C3159B7B4442 30 at Fri May 16 22:19:30 1997
U2T 3232: sent TCP request: N2[FFFFFFFF/4E15D374] 29 A2 - - - 61025B4A01010101 D5C6C3159B7B4442 30 at Fri May 16 22:19:30 1997
U2T 3231: got TCP reply: A2 - - - 64014C4501010101 D0C5D41A9B7B4442 30 at Fri May 16 22:19:31 1997
U2T 3230: got TCP reply: A2 - - - 64014C4601010101 D0C5D4199B7B4442 30 at Fri May 16 22:19:31 1997
U2T 3228: got TCP reply: A2 - - - 64014C3E80010101 D0C5D4611A7B4442 29 at Fri May 16 22:19:32 1997
U2T 3229: got TCP reply: A2 - - - 64014C5701010101 D0C5D4089B7B4442 30 at Fri May 16 22:19:33 1997
U2T 3232: got TCP reply: A2 - - - 64014C4901010101 D0C5D4169B7B4442 30 at Fri May 16 22:19:33 1997

Not good. Note teh different numbers in the replies, which says to me Im
getting multiple responces.

I am going to manually kill a couple u2t redundant gateways. I have a script
that mails me the proc table grep'd for my des-related procs every 30
min so I can keep on it, but that will be a pain in the ass to go to
bed and wake up to 12 u2t's running! ;)

You probably have flags at the master server going up for my gateway
now too for reserving too much of the keyspace at once...

If this means anything - my home client's xload has a big notch in it,
showing that my client was idle for a second, probably timing out
on getting a key and having to retry. Is there some way that the server
being down would cause these multiple requests? I can see it:

client requests key, u2t #1 gets the request and goes for key, blocks waiting
client retries, u2t #2 ..............................., ...........
" " #3 ..............................., ...........

etc.

then the server wakes up suddenly, my u2t gateways ALL NOT having timed
out, and they all send their responces back to my client, which
probably just actually accepts the responce from the last one.

I dunno, you da experts.

/kc