“ss” command in iproute package; why query slab table for timewait sockets

networkingprocsocket

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.

Best Answer

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.

Related Question