Sockets tapset and script

Sockets tapset and script

[Mike Mason]

[-- Attachment #1: Type: text/plain, Size: 4731 bytes --]

Attached is a sockets tapset and a script that uses the tapset.  I thought I'd post them for review even though they're not done.  The tapset just contains what I needed to write the script.  More comments, probes and helper functions are needed.  I also need to write some tests.

The tapset contains functions to map numbers to strings and strings to numbers for:

- protocols
- protocol families
- socket types
- socket states
- socket flags
- message flags

Mapping functions are something I think script writers need, not just for sockets, but in a lot of other areas. Some of these functions using mapping arrays.  What do people think of this approach?

The script (socktop) prints socket traffic for the top n processes and, optionally, network device traffic. Besides being a useful script (I hope), it demonstrates a few methods that should be applicable to many scripts:

- using a shell script to process command line options
- filtering on multiple categories (in this case, process ID and name, user name, protocol, protocol family and socket type)
- passing array-like data from a shell script to a systemtap script and tokenizing that data in systemtap
- passing in a timezone adjustment

Also, note the sign bit hack in the return probes. This is something I'd like to remove before posting the script on the wiki (hint, hint :-).

Here's some example output from socktop:

[root@localhost probes]# ./socktop -P TCP -P UDP -d
======================= Fri Nov 17 14:10:57 2006 ========================
------------------------------- PROCESSES -------------------------------
PID   UID     #SEND   #RECV SEND_KB RECV_KB PROT FAMILY   COMMAND
14668 0           0    2546       0    3635 TCP  INET     firefox-bin
6765  0          10      10      31       0 TCP  INET     Xvnc
-------------------------------- DEVICES --------------------------------
DEV             #XMIT         #RECV         XMIT_KB         RECV_KB
eth0             1396          2643             121            3769
=========================================================================

======================= Fri Nov 17 14:11:02 2006 ========================
------------------------------- PROCESSES -------------------------------
PID   UID     #SEND   #RECV SEND_KB RECV_KB PROT FAMILY   COMMAND
14668 0           0    2457       0    3487 TCP  INET     firefox-bin
6765  0          11      11      14       0 TCP  INET     Xvnc
29852 0           2       0       0       0 TCP  INET6    sshd
-------------------------------- DEVICES --------------------------------
DEV             #XMIT         #RECV         XMIT_KB         RECV_KB
eth0             1309          2533              98            3620
=========================================================================

======================= Fri Nov 17 14:11:07 2006 ========================
------------------------------- PROCESSES -------------------------------
PID   UID     #SEND   #RECV SEND_KB RECV_KB PROT FAMILY   COMMAND
14668 0           0    1886       0    2676 TCP  INET     firefox-bin
6765  0          83     292     532       2 TCP  INET     Xvnc
29852 0           1       0       0       0 TCP  INET6    sshd
-------------------------------- DEVICES --------------------------------
DEV             #XMIT         #RECV         XMIT_KB         RECV_KB
eth0             1501          2478             624            2797
=========================================================================


[root@localhost probes]# ./socktop -d
======================= Fri Nov 17 14:09:45 2006 ========================
------------------------------- PROCESSES -------------------------------
PID   UID     #SEND   #RECV SEND_KB RECV_KB PROT FAMILY   COMMAND
14668 0           0    2796       0    3969 TCP  INET     firefox-bin
6765  0         221     284     535     429 IP   LOCAL    Xvnc
6909  0          77     139     277     276 IP   LOCAL    wnck-applet
14668 0          53      79     103     220 IP   LOCAL    firefox-bin
6840  0          61     125      26      17 IP   LOCAL    metacity
6902  0          21      27      21      21 IP   LOCAL    nautilus
6765  0          11      11      32       0 TCP  INET     Xvnc
6900  0           3       7       0       0 IP   LOCAL    gnome-panel
6820  0           0       8       0       0 IP   LOCAL    gnome-settings-
1610  0           1       3       0       0 IP   NETLINK  ifconfig
-------------------------------- DEVICES --------------------------------
DEV             #XMIT         #RECV         XMIT_KB         RECV_KB
eth0             1516          2888             129            4115
=========================================================================


All comments are welcome.

Mike Mason


 





[-- Attachment #2: sockets.tgz --]
[-- Type: application/x-compressed, Size: 7633 bytes --]

Re: Sockets tapset and script

[Martin Hunt]

On Fri, 2006-11-17 at 14:26 -0800, Mike Mason wrote:
> Attached is a sockets tapset and a script that uses the tapset.  

Very nice!  

It seems like tokenize() and str2long() (perhaps renamed simply strtol)
would be good candidates to put in the string tapset so others could use
them.

Since yesterday, we can now access parameters in return probes (BZ
1382). This could simplify some of your script because yo no longer need
to cache parameters on entry probes and then lookup their values in the
return probe.

In print_activity, you can simply do this:
	foreach ([pid, prot, fam] in sk_pid- limit max) { ... }
Then you don't need "if (!--max) break"
This is a bit cleaer and generates faster code.

> Mapping functions are something I think script writers need, not just for sockets, 
> but in a lot of other areas. Some of these functions using mapping arrays. 
> What do people think of this approach?

It is simple and elegant. However, in time-critical code (which your
example is probably not) it may be better to write them in C. A
complicated example would be what I did in errno.stp. Of course that
example doesn't include the reverse map.

I see you worked around the issue with nonexistent map entries are
returned as 0. Also, since setting a map entry to 0 deletes it, there is
no reason to do
	fam_str2num["UNSPEC"] = 0
What you could have done is add 1 to all of the entries, which
simplifies your code considerably:
function sock_fam_str2num:long (family:string)
{
	if (!fam_s2s_init) _fam_str2num_init()
	return fam_str2num[family] - 1
}
function sock_fam_num2str:string (family:long)
{
	if (!fam_n2s_init) _fam_num2str_init()
	str = fam_num2str[family+1]
	if (str == "") str = sprintf ("%d", family)
	return str
}


One possible issue is if we accumulate too many of these arrays in
tapsets, they could take significant space. The language currently has
no way to declare an array static and therefore all arrays have
MAXMAPENTRIES preallocated for their use.

Martin

Re: Sockets tapset and script

[David Smith]

Martin Hunt wrote:
> On Fri, 2006-11-17 at 14:26 -0800, Mike Mason wrote:
>> Attached is a sockets tapset and a script that uses the tapset.  
> 
> Very nice!  
> 
> It seems like tokenize() and str2long() (perhaps renamed simply strtol)
> would be good candidates to put in the string tapset so others could use
> them.
> 
> Since yesterday, we can now access parameters in return probes (BZ
> 1382). This could simplify some of your script because yo no longer need
> to cache parameters on entry probes and then lookup their values in the
> return probe.
> 
> In print_activity, you can simply do this:
> 	foreach ([pid, prot, fam] in sk_pid- limit max) { ... }
> Then you don't need "if (!--max) break"
> This is a bit cleaer and generates faster code.
> 
>> Mapping functions are something I think script writers need, not just for sockets, 
>> but in a lot of other areas. Some of these functions using mapping arrays. 
>> What do people think of this approach?
> 
> It is simple and elegant. However, in time-critical code (which your
> example is probably not) it may be better to write them in C. A
> complicated example would be what I did in errno.stp. Of course that
> example doesn't include the reverse map.

Mike,

One thing you might want to think about is instead of initializing your 
mapping arrays on first use would be to put their initialization in a 
begin probe.  You'd pay more up front cost but if your probe code was 
time-critical (which your use might not be) you wouldn't be slowed down 
by mapping array initialization in the probe itself.  The optimizer will 
optimize out the array and array initialization if the array isn't 
actually used anywhere.

This would be similar to what happens when you do "global xyz = 1" - a 
begin probe is generated that sets up the initial value of xyz.  Hmm, 
perhaps we need a bugzilla asking to support array initialization, 
perhaps like this:
     global xyz = { 1, 5, 10, 15 }
     global abc = { "zero", "one", "two", "three", "four" }

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Sockets tapset and script

[Mike Mason]

Martin Hunt wrote:
> On Fri, 2006-11-17 at 14:26 -0800, Mike Mason wrote:
>> Attached is a sockets tapset and a script that uses the tapset.
> 
> Very nice!
> 
> It seems like tokenize() and str2long() (perhaps renamed simply strtol)
> would be good candidates to put in the string tapset so others could use
> them.
> 
> Since yesterday, we can now access parameters in return probes (BZ
> 1382). This could simplify some of your script because yo no longer need
> to cache parameters on entry probes and then lookup their values in the
> return probe.

Based on later posts, I assume this still doesn't work and I 
shouldn't remove the parameter caching in my script just yet.
Please confirm if this is true.

Thanks,
Mike

Re: Sockets tapset and script

[David Smith]

Mike Mason wrote:
> Martin Hunt wrote:
>> On Fri, 2006-11-17 at 14:26 -0800, Mike Mason wrote:
>> Since yesterday, we can now access parameters in return probes (BZ
>> 1382). This could simplify some of your script because yo no longer need
>> to cache parameters on entry probes and then lookup their values in the
>> return probe.
> 
> Based on later posts, I assume this still doesn't work and I shouldn't 
> remove the parameter caching in my script just yet.
> Please confirm if this is true.

Accessing target variables in return probes currently works, for some 
applications.

There are two major outstanding bugs:

(1) The current code can get confused and fail to find the cached 
parameters if two different threads intersperse function entries/exits. 
  I should have this one fixed late today or early tomorrow.

(2) Accessing the target variables in a loop is broken.  A workaround is 
to assign the target variable to a temp variable before the loop and 
then use the temp variable in the loop.  This one is going to require 
some re-architecture work, so I'm unsure when it will get fixed.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Sockets tapset and script - UPDATE

[Mike Mason]

[-- Attachment #1: Type: text/plain, Size: 5322 bytes --]

Here's an update to the sockets tapset and script I sent out in November.  Given that I made some significant changes, and this is my first major checkin, I'd like it sanity checked before committing it.  Note that I added a test and moved tokenize() and strtol() to the string.stp tapset file.  I still need to write the man page.

Thanks for your help!

Mike

Mike Mason wrote:
> Attached is a sockets tapset and a script that uses the tapset.  I 
> thought I'd post them for review even though they're not done.  The 
> tapset just contains what I needed to write the script.  More comments, 
> probes and helper functions are needed.  I also need to write some tests.
> 
> The tapset contains functions to map numbers to strings and strings to 
> numbers for:
> 
> - protocols
> - protocol families
> - socket types
> - socket states
> - socket flags
> - message flags
> 
> Mapping functions are something I think script writers need, not just 
> for sockets, but in a lot of other areas. Some of these functions using 
> mapping arrays.  What do people think of this approach?
> 
> The script (socktop) prints socket traffic for the top n processes and, 
> optionally, network device traffic. Besides being a useful script (I 
> hope), it demonstrates a few methods that should be applicable to many 
> scripts:
> 
> - using a shell script to process command line options
> - filtering on multiple categories (in this case, process ID and name, 
> user name, protocol, protocol family and socket type)
> - passing array-like data from a shell script to a systemtap script and 
> tokenizing that data in systemtap
> - passing in a timezone adjustment
> 
> Also, note the sign bit hack in the return probes. This is something I'd 
> like to remove before posting the script on the wiki (hint, hint :-).
> 
> Here's some example output from socktop:
> 
> [root@localhost probes]# ./socktop -P TCP -P UDP -d
> ======================= Fri Nov 17 14:10:57 2006 ========================
> ------------------------------- PROCESSES -------------------------------
> PID   UID     #SEND   #RECV SEND_KB RECV_KB PROT FAMILY   COMMAND
> 14668 0           0    2546       0    3635 TCP  INET     firefox-bin
> 6765  0          10      10      31       0 TCP  INET     Xvnc
> -------------------------------- DEVICES --------------------------------
> DEV             #XMIT         #RECV         XMIT_KB         RECV_KB
> eth0             1396          2643             121            3769
> =========================================================================
> 
> ======================= Fri Nov 17 14:11:02 2006 ========================
> ------------------------------- PROCESSES -------------------------------
> PID   UID     #SEND   #RECV SEND_KB RECV_KB PROT FAMILY   COMMAND
> 14668 0           0    2457       0    3487 TCP  INET     firefox-bin
> 6765  0          11      11      14       0 TCP  INET     Xvnc
> 29852 0           2       0       0       0 TCP  INET6    sshd
> -------------------------------- DEVICES --------------------------------
> DEV             #XMIT         #RECV         XMIT_KB         RECV_KB
> eth0             1309          2533              98            3620
> =========================================================================
> 
> ======================= Fri Nov 17 14:11:07 2006 ========================
> ------------------------------- PROCESSES -------------------------------
> PID   UID     #SEND   #RECV SEND_KB RECV_KB PROT FAMILY   COMMAND
> 14668 0           0    1886       0    2676 TCP  INET     firefox-bin
> 6765  0          83     292     532       2 TCP  INET     Xvnc
> 29852 0           1       0       0       0 TCP  INET6    sshd
> -------------------------------- DEVICES --------------------------------
> DEV             #XMIT         #RECV         XMIT_KB         RECV_KB
> eth0             1501          2478             624            2797
> =========================================================================
> 
> 
> [root@localhost probes]# ./socktop -d
> ======================= Fri Nov 17 14:09:45 2006 ========================
> ------------------------------- PROCESSES -------------------------------
> PID   UID     #SEND   #RECV SEND_KB RECV_KB PROT FAMILY   COMMAND
> 14668 0           0    2796       0    3969 TCP  INET     firefox-bin
> 6765  0         221     284     535     429 IP   LOCAL    Xvnc
> 6909  0          77     139     277     276 IP   LOCAL    wnck-applet
> 14668 0          53      79     103     220 IP   LOCAL    firefox-bin
> 6840  0          61     125      26      17 IP   LOCAL    metacity
> 6902  0          21      27      21      21 IP   LOCAL    nautilus
> 6765  0          11      11      32       0 TCP  INET     Xvnc
> 6900  0           3       7       0       0 IP   LOCAL    gnome-panel
> 6820  0           0       8       0       0 IP   LOCAL    gnome-settings-
> 1610  0           1       3       0       0 IP   NETLINK  ifconfig
> -------------------------------- DEVICES --------------------------------
> DEV             #XMIT         #RECV         XMIT_KB         RECV_KB
> eth0             1516          2888             129            4115
> =========================================================================
> 
> 
> All comments are welcome.
> 
> Mike Mason
> 
> 
> 
> 
> 
> 
> 

[-- Attachment #2: socket-01-19-07.tgz --]
[-- Type: application/x-compressed, Size: 8901 bytes --]