rra at stanford.edu
Fri Oct 1 05:28:07 UTC 2004
Jeffrey M Vinocur <jeff at litech.org> writes:
> I have no idea why since rc.c hasn't changed in ages, but since the
> 2.4.2 prerelease or so I've had innd hang several times in the following
> fashion. I suppose it could be coincident with some other system
> changes around here, but even if there's something wrong with our
> identd, innd shouldn't die as a result...
> #0 0x40127a98 in read () from /lib/libpthread.so.0
> #1 0xbffff0a0 in ?? ()
> #2 0x080653f8 in GoodIdent (fd=96, identd=0x80d4b10 "news") at rc.c:190
> #3 0x080661f9 in RCreader (cp=0xbffff0a0) at rc.c:642
> #4 0x0805b173 in CHANreadloop () at chan.c:1015
> #5 0x0805d630 in main (ac=2, av=0x8243880) at innd.c:666
The ident code currently implements no timeouts whatsoever. Hm. That's a
I'm afraid that the correct solution here is going to be annoying. We
really need to put the connection into a different mode, open a new file
descriptor for the ident callback, create a new type of channel for
accepting the ident callback, and put that channel into the main select
loop. That's... incredibly annoying, but I don't see any good
alternatives if we want to support ident.
I assume that you do have ident checking turned on (via setting identd in
This is more work than I'm going to be able to do right now. I'll make a
note to look at this later, and in the meantime will add a caution to the
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
More information about the inn-workers