> > hmm. But I don't have any other descriptors opened. (which may've been
> > randomly closed). And following the man page, if I don't have any opened
> > f-descriptors, close would return -1 and EBADF.
>
> You do; you have the listening socket (sock_s) open. If you closed all
> descriptors prior to the `sock_s=socket(...)', then sock_s will be
> zero. If sock_a happens to be zero initially, then you will end up
> closing the listening socket.
ah. Yes. Overlooked this detail. Thanks.
> > I removed it. (I close the same descriptor in process_connection()
> > function, called by child), things started working.. hmm. looks like the
> > problem with libc, I guess.
>
> Looks like sock_a may have been zero to start with.
yep. Checked this. On BSD machines sock_a gets some random value, while on
Linux it's always zero. This was the cause why it was stuck in accept. By
the way, is there way in gdb to check what filedescriptors are opened in
some process, so I could investigate such behaviour in future?
> > tcp 1 45761 192.168.230.4:2000 192.168.5.4:1146 LAST_ACK
> > ^^^^^ machine were server runs.
> >
> > Looks like I broke the connection, and kernel still waits for last_ack
> > from remote. Is there way to flush such things?
>
> The kernel should keep resending the FIN until the other end
> acknowledges it.
within certain timeout, right?
> There isn't any mechanism to forcibly change a
> socket's state (although I guess you could use spak to send a fake
> ACK).
yep.probably it would work, but is it the only way to fix it? and.. I will
need SYN/ACK numbers here, is there a way to get (within a C code) these
pack. numbers which kernel expect? (probably it could be possible for
setuids by examining certain areas of memory, since kernel saves these
numbers somewhere anyway, but is the a "proper" way?)
> Unless you've closed the listening socket, that is. Although this
> should cause accept() to return immediately with errno set to EBADF.
yeah. maybe something's still a trouble in that libc.. maybe not.
