Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Forgive me if this isn't the best forum for this question, but it seems more relevant to the kernel than to the programming itself.

I'm writing a script that queries the system for open ports so that we can graph and monitor the statistics. For this, I'm using the "ss" command from the iproute package. If you execute ss -s|grep estab you will receive output similar to this:

TCP:   296 (estab 6, closed 238, orphaned 0, synrecv 0, timewait 238/0), ports 0

My question has to do with the timewait variable, which shows the computed sockets in TIME_WAIT state. When I tried to figure out what number was referenced after the slash, it became a whirlwind adventure of searching for source code which ultimately led me to find the following snippet:

printf("TCP:   %d (estab %d, closed %d, orphaned %d, synrecv %d, timewait %d/%d), ports %d\n",
       s.tcp_total + slabstat.tcp_syns + s.tcp_tws,
       sn.tcp_estab,
       s.tcp_total - (s.tcp4_hashed+s.tcp6_hashed-s.tcp_tws),
       s.tcp_orphans,
       slabstat.tcp_syns,
       s.tcp_tws, slabstat.tcp_tws,
       slabstat.tcp_ports
       );

I must admit, my searching for what "slabstat" was supposed to mean ultimately led to my learning about the slab caches and their reporting interface at /proc/slabinfo.

The question: What does the slabtable have to do with TIME_WAIT socket calculations? I'm failing to figure out why this number is reported, as every time I've run the command across every server I've tried it on, the number has always been zero.

share|improve this question
    
In all honesty, you'd probably get the best answers by posting this to one of the relevant kernel mailing lists, see tux.org/lkml/#related-lists –  jeremiahd Mar 29 '12 at 3:28
    
The code just shows how many waiting sockets are allocated in the slab. IMO it just helps to determine memory usage –  Ulrich Dangel May 16 '12 at 0:49
add comment

1 Answer

up vote 0 down vote accepted

It looks like tcp_tw_buckets is what is ultimately polled, which is a struct removed as of Linux 2.6.12

So the last number would probably always be 0 unless it's on 7 year old kernels.

As for querying slab, as far as I can tell it's ridiculously faster than the other methods available.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.