The 1st instance of Tnm starts up straps. Straps works as it should,
receiving traps on its UDP port & forwarding them on to its connected
client AF_UNIX sockets. Subsequent instances of Tnm work fine too.
If the 1st instance of Tnm exits, straps doesn't see the close on its
socket, so every time it receives a UDP trap, it still sends it to the
(now defunct) client socket. Because nobody is reading this, the socket
write call soon blocks, thus hanging straps.
Straps does see socket closures on the 2nd & subsequent instances of Tnm,
its only the 1st socket close it doesn't see.
If I start straps by hand (rather than relying on Tnm to start it), it
does see the socket close on the 1st instance of Tnm. My guess is that
because the 1st instance of Tnm forks straps, straps inherits Tnm's open
file descriptors. Looking at the straps code, I see that somebody already
thought of this-
/*
* Close any "leftover" FDs from the parent. There is a relatively
* high probability that the parent will be scotty, and that the
client
* side of the scotty-straps connection is among the open FDs. This
* is bad news if the parent scotty goes away, since this will
eventually
* cause straps to "block against itself" in the "forward data to
client"
* write() calls below, since straps itself is not consuming data
from
* the client side of the leftover open socket.
*/
for (i = 3; i < FD_SETSIZE; i++) {
(void) close(i);
}
But this doesn't seem to work as it should. I'd appreciate some help
understanding this.
--
Les Smithson. Datastream/ICV, London.
-- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.