For the most part, SystemTap scripts are the foundation of each SystemTap
session. SystemTap scripts instruct SystemTap on what type of information to
collect, and what to do once that information is collected.
As stated in
Chapter 3, Understanding How SystemTap Works, SystemTap
scripts are made up of two components:
events and
handlers. Once a SystemTap session is underway,
SystemTap monitors the operating system for the specified events and
executes the handlers as they occur.
An event and its corresponding handler is collectively called a
probe. A SystemTap script can have multiple probes.
A probe's handler is commonly referred to as a probe
body.
In terms of application development, using events and handlers is similar to
instrumenting the code by inserting diagnostic print statements in a
program's sequence of commands. These diagnostic print statements allow you
to view a history of commands executed once the program is run.
SystemTap scripts allow insertion of the instrumentation code without
recompilation of the code and allows more flexibility with regard to
handlers. Events serve as the triggers for handlers to run; handlers can be
specified to record specified data and print it in a certain manner.
Format
SystemTap scripts use the file extension
.stp
, and
contains probes written in the following format:
probe event {statements}
SystemTap supports multiple events per probe; multiple events are delimited
by a comma (,
). If multiple events are specified in a
single probe, SystemTap will execute the handler when any of the specified
events occur.
Each probe has a corresponding statement block. This statement block is
enclosed in braces ({ }
) and contains the statements to be executed per event.
SystemTap executes these statements in sequence; special separators or
terminators are generally not necessary between multiple statements.
Statement blocks in SystemTap scripts follow the same syntax and semantics as the C
programming language. A statement block can be nested within another statement block.
SystemTap allows you to write functions to factor out code to be used by a
number of probes. Thus, rather than repeatedly writing the same
series of statements in multiple probes, you can just place the instructions
in a function, as in:
function function_name(arguments) {statements}
probe event {function_name(arguments)}
The statements
in
function_name are executed when the probe for
event executes. The
arguments are optional values passed into the
function.
SystemTap events can be broadly classified into two types:
synchronous and
asynchronous.
Synchronous Events
A
synchronous event occurs when any process
executes an instruction at a particular location in kernel
code. This gives other events a reference point from which more
contextual data may be available.
Examples of synchronous events include:
- syscall.system_call
The entry to the system call
system_call. If the exit from a syscall
is desired, appending a .return
to the event
monitor the exit of the system call instead. For example, to specify
the entry and exit of the system call close
, use
syscall.close
and
syscall.close.return
respectively.
- vfs.file_operation
The entry to the file_operation event for
Virtual File System (VFS). Similar to syscall
event, appending a .return
to the event monitors
the exit of the file_operation operation.
- kernel.function("function")
The entry to the kernel function
function. For example,
kernel.function("sys_open")
refers to the "event"
that occurs when the kernel function sys_open
is
called by any thread in the system. To specify the
return of the kernel function
sys_open
, append the return
string to the event statement;
that is, kernel.function("sys_open").return
.
When defining probe events, you can use asterisk (*
)
for wildcards. You can also trace the entry or exit of a function in
a kernel source file. Consider the following example:
Example 3.1. wildcards.stp
probe kernel.function("*@net/socket.c") { }
probe kernel.function("*@net/socket.c").return { }
In the previous example, the first probe's event specifies the entry
of ALL functions in the kernel source file
net/socket.c
. The second probe specifies the
exit of all those functions. Note that in this example,
there are no statements in the handler;
as such, no information will be collected or displayed.
- kernel.trace("tracepoint")
The static probe for tracepoint.
Recent kernels (2.6.30 and newer)
include instrumentation for specific events in the kernel. These
events are statically marked with tracepoints. One example of a
tracepoint available in systemtap is
kernel.trace("kfree_skb")
which indicates each
time a network buffer is freed in the kernel.
- module("module").function("function")
Allows you to probe functions within modules. For example:
Example 3.2. moduleprobe.stp
probe module("ext3").function("*") { }
probe module("ext3").function("*").return { }
A system's kernel modules are typically located in /lib/modules/kernel_version
, where kernel_version refers to the currently loaded kernel version. Modules use the file name extension .ko
.
Asynchronous Events
Asynchronous events are not tied to a particular
instruction or location in code. This family of probe points consists
mainly of counters, timers, and similar constructs.
Examples of asynchronous events include:
- begin
The startup of a SystemTap session; that is, as soon as the SystemTap
script is run.
- end
The end of a SystemTap session.
- timer events
An event that specifies a handler to be executed periodically.
For example:
Example 3.3. timer-s.stp
probe timer.s(4)
{
printf("hello world\n")
}
Example 3.3, “timer-s.stp” is an example of a probe that prints
hello world
every 4 seconds. It is also possible
to use the following timer events:
timer.ms(milliseconds)
timer.us(microseconds)
timer.ns(nanoseconds)
timer.hz(hertz)
timer.jiffies(jiffies)
When used in conjunction with other probes that collect information,
timer events allows you to print out get periodic updates and see
how that information changes over time.
SystemTap supports the use of a large collection of probe events. For
more information about supported events, refer to man
stapprobes
. The SEE ALSO section of
man stapprobes
also contains links to other
man
pages that discuss supported events for specific
subsystems and components.