> /proc/net/tcp is an obsolete interface. It is inherently unreliable
> in that a record may be read using two read(2) calls. Those two calls
> may end up looking at two different records.
> So please use the netlink interface or ss(8) from the iproute package.
OK, so just out of sheer morbid curiousity, I added an ioctl which will
accept 4 parameters (the address/port pairs), and will return the user id
associated with that socket. I also changed pidentd to call this ioctl
instead of looking at /proc/net/tcp. This should theoretically get rid
of all race conditions.
However, the problem still happens. We see many instances of the kernel
reporting the wrong user id. What is even more interesting is that we added
a retry loop, and many times the problem goes away after re-trying. Sometimes
the first retry gets the correct username, and sometimes it takes 4 or 5
retries. So there is definitely some sort of race condition going on here.
We have verified that when this problem occurs the process holding the
socket endpoint in question is still running, so it isn't some problem caused
by doing an identd lookup after the other end has gone away.
Does anybody have any idea why the userid associated with the socket's inode
might be changing mid-stream? What are the chances of a defect where two
sockets are using the same inode memory or something like that?