/proc/net/tcp not updated fast enough?

/proc/net/tcp not updated fast enough?

[Henrik Christian Grove]

Hi

I'm writing a SMTP proxy that needs to know the uid of the user
connecting (only connections from the same machine is supposed to work).

I find the uid by searching /proc/net/tcp, for a line having a
0100007F:<port I get from accept on the socket I listen on> as
local_address and <any-ip>:<the port I listen on> as rem_address, and
that works perfectly -- most of the time.

I have it running on 11[1] machines and since midnight (it's 11:47 here
now) I have 2397 succesfull connections, but in 31 cases (that's 1,29%
of the connections - and thus not totally ignorable) I had to read
through /proc/net/tcp twice to find the uid. Does that sound plausible,
or more like I'm doing something wrong?

If it's plausible, how long can it take for /proc/net/tcp to get the
info? I'm asking because I see one connection (again since midnight)
where I don't find any uid in the 5 attempts I do as a max.

If it's plausible could it explain why I have 9 connections apparently
coming from root, although they seem to come from a program _not_
running as root? Here "seem" means that I have tried logging the
(relevant parts of the) output from `netstat -tnp` when I got these
connections and the pid was the pid of a program I've written myself,
that would complain in the log if it were running as root.
(There's also a single connection from uid 33 (that's a uid apache runs
as) and one from uid 99 (unused), but they are so rare I haven't tried
tracing them yet).

It wasn't until yesterday that I started suspecting /proc/net/tcp from
"lagging", so I don't have reliable numbers from yesterday.

The machines run a 2.4.25 kernel with vserver-patches (the proxy
actually runs in a vserver).

.Henrik

[1] Actually one of them has only been running since around 4:45 this
morning, but that shouldn't matter.

-- 
"Det er fundamentalt noget humanistisk vås, at der er noget, 
 der hedder blød matematik."
   --- citat Henrik Jeppesen, dekan for det naturvidenskabelige fakultet

Re: /proc/net/tcp not updated fast enough?

[Herbert Xu]

Henrik Christian Grove <grove@fsr.ku.dk> wrote:
 
> I have it running on 11[1] machines and since midnight (it's 11:47 here
> now) I have 2397 succesfull connections, but in 31 cases (that's 1,29%
> of the connections - and thus not totally ignorable) I had to read
> through /proc/net/tcp twice to find the uid. Does that sound plausible,
> or more like I'm doing something wrong?

/proc/net/tcp in 2.4 is inherently unreliable since it doesn't use
the seqfile interface.  Your best bet is to use the tcp_diag interface
instead.  You can either do that by using the ss command from the
iproute2 suite, or you can query tcp_diag directly from C through
netlink.

The latter should be 100% reliable if you do a get instead of a dump.

> If it's plausible, how long can it take for /proc/net/tcp to get the
> info? I'm asking because I see one connection (again since midnight)
> where I don't find any uid in the 5 attempts I do as a max.

It's not that it takes a long time to update /proc/net/tcp, it's
the fact that you have to read /proc/net/tcp in pieces, and when
the underlying data is changing, the 2.4 code is much more prone to
returning things twice or missing entries altogether.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: /proc/net/tcp not updated fast enough?

[Henrik Christian Grove]

Herbert Xu <herbert@gondor.apana.org.au> writes:

> Henrik Christian Grove <grove@fsr.ku.dk> wrote:
>  
> > I have it running on 11[1] machines and since midnight (it's 11:47 here
> > now) I have 2397 succesfull connections, but in 31 cases (that's 1,29%
> > of the connections - and thus not totally ignorable) I had to read
> > through /proc/net/tcp twice to find the uid. Does that sound plausible,
> > or more like I'm doing something wrong?
> 
> /proc/net/tcp in 2.4 is inherently unreliable since it doesn't use
> the seqfile interface.  Your best bet is to use the tcp_diag interface
> instead.  You can either do that by using the ss command from the
> iproute2 suite, or you can query tcp_diag directly from C through
> netlink.

Thank you for the quick reply. Would you (or anyone else reading this)
happen to have any hints on what to do in Perl? (I know I can call ss,
but maybe there's a module with a nice interface?)

.Henrik

-- 
"Det er fundamentalt noget humanistisk vås, at der er noget, 
 der hedder blød matematik."
   --- citat Henrik Jeppesen, dekan for det naturvidenskabelige fakultet