| Main index | Section 1 | Options |
The dtrace command provides a generic interface to the essential services provided by the DTrace facility, including:
You can use
dtrace
to create D scripts by using it in a shebang declaration to create an
interpreter file.
You can also use
dtrace
to attempt to compile D programs and determine their properties without
actually enabling traces using the
The following options are supported:
| | |
|
The D compiler produces programs using the native data model of the operating
system kernel.
If the
| |
| | |
|
Claim anonymous tracing state and display the traced data.
You can combine the
| |
| | |
|
Generate directives for anonymous tracing and write them to
/boot/dtrace.dof.
This option constructs a set of dtrace configuration file directives to enable
the specified probes for anonymous tracing and then exits.
By default,
dtrace
attempts to store the directives to the file
/boot/dtrace.dof.
This behavior can be modified using the
| |
| | |
| Set the principal trace buffer size to bufsz. The trace buffer size can include any of the size suffixes k, m, g, or t. If the buffer space cannot be allocated, dtrace attempts to reduce the buffer size or exit depending on the setting of the bufresize property. | |
| | |
|
Run the specified command
cmd
and exit upon its completion.
If more than one
| |
| | |
|
Run the C preprocessor
cpp(1)
over D programs before compiling them.
You can pass options to the C preprocessor using the
| |
| | |
| Dump the D script to standard output, after syntactic transformations have been applied. For example, if-statements in D are implemented using such transformations: a conditional clause in a probe body is replaced at compile-time by a separate probe predicated on the original condition. | |
| | |
|
Define
name
when invoking
cpp(1)
(enabled using the
| |
| | |
|
Exit after compiling any requests and consuming anonymous tracing state
| |
| | |
|
Oc Ar action Oc
Specify function name to trace or list
| |
| | |
| Coalesce trace output by identifying function entry and return. Function entry probe reports are indented and their output is prefixed with ‘->’. Function return probe reports are unindented and their output is prefixed with ‘<-’. System call entry probe reports are indented and their output is prefixed with ‘=>’. System call return probe reports are unindented and their output is prefixed with ‘<=’. | |
| | |
|
Generate an ELF file containing an embedded DTrace program.
The DTrace probes specified in the program are saved inside of a relocatable ELF
object which can be linked into another program.
If the
| |
| | |
|
Generate a header file containing macros that correspond to probes in the
specified provider definitions.
This option should be used to generate a header file that is included by other
source files for later use with the
| |
| | |
|
Print the pathnames of included files when invoking
cpp(1)
(enabled using the
| |
| | |
|
Specify probe identifier
( probe-id)
to trace or list
( l
option).
You can specify probe IDs using decimal integers as shown by `dtrace -l`.
The
| |
| | |
|
Add the specified directory
path
to the search path for #include files when invoking
cpp(1)
(enabled using the
| |
| | |
|
List probes instead of enabling them.
If the
| |
| | |
| Add the specified directory path to the search path for DTrace libraries. DTrace libraries are used to contain common definitions that can be used when writing D programs. The specified path is added after the default library search path. | |
| | |
| Generate output via libxo(3). This option is the same as specifying oformat. | |
| | |
|
Specify module name to trace or list
| |
| | |
|
Oo Oo Ar predicate Oc Ar action Oc
Specify probe name to trace or list
| |
| | |
|
This option causes
dtrace
to print all the aggregations upon exiting if
oformat
or
| |
| | |
|
Specify the
output
file for the
| |
| | |
|
Grab the specified process-ID
pid,
cache its symbol tables, and exit upon its completion.
If more than one
| |
| | |
|
Specify provider name to trace or list
| |
| | |
| Set quiet mode. dtrace suppresses messages such as the number of probes matched by the specified options and D programs and does not print column headers, the CPU ID, the probe ID, or insert newlines into the output. Only data traced and formatted by D program statements such as ‘dtrace()’ and ‘printf()’ is displayed to standard output. | |
| | |
|
Compile the specified D program source file.
If the
| |
| | |
| Show D compiler intermediate code. The D compiler produces a report of the intermediate code generated for each D program to standard error. | |
| | |
|
Undefine the specified
name
when invoking
cpp(1)
(enabled using the
| |
| | |
|
Set verbose mode.
If the
| |
| | |
| Report the highest D programming interface version supported by dtrace. The version information is printed to standard output and the dtrace command exits. | |
| | |
|
Permit destructive actions in D programs specified using the
| |
| | |
|
Enable or modify a DTrace runtime option or D compiler option.
Boolean options are enabled by specifying their name.
Options with values are set by separating the option name and value with an
equals sign (=).
A size argument may be suffixed with one of K, M, G or T (either upper or lower case) to indicate a multiple of Kilobytes, Megabytes, Gigabytes or Terabytes respectively. A time argument may be suffixed with one of ns, nsec, us, usec, ms, msec, s, sec, m, min, h, hour, d, day, hz. If no suffix is specified hz will be used as the unit. | |
| aggrate=time | |
| Rate of aggregation reading. | |
| aggsize=size | |
| Size of the aggregation buffer. | |
| bufpolicy= fill| switch| ring | |
| Specifies the buffer policy for the principal buffer. | |
| bufresize= auto| manual | |
| Buffer resizing policy. | |
| bufsize=size | |
|
Size of the per-CPU principal buffer.
Same as the
| |
| cleanrate=time | |
| Cleaning rate. Must be specified in number-per-second with the "hz" suffix. | |
| cpu=scalar | |
| Specifies the CPU on which to enable tracing. | |
| cpp |
Run a C preprocessor over input files.
Same as the
|
| cpppath=path | |
| Use the specified path for the C preprocessor rather than searching for "cpp" in PATH. | |
| defaultargs | |
| Allow references to unspecified macro arguments. | |
| destructive | |
|
Allow destructive actions.
Same as the
| |
| dynvarsize=size | |
| Size of the dynamic variable space. | |
| flowindent | |
|
Turn on flow indentation.
Same as the
| |
| grabanon | |
|
Claim anonymous state.
Same as the
| |
| jstackframes=scalar | |
| Number of default stack frames for jstack(). | |
| jstackstrsize=scalar | |
| Default string space size for jstack(). | |
| ldpath=path | |
|
When
| |
| libdir=path | |
| Add a directory to the system library path. | |
| nspec=scalar | |
| Number of speculations. | |
| nolibs | |
| Do not load D system libraries. | |
| quiet |
Set quiet mode.
Same as the
|
| specsize=size | |
| Size of the speculation buffer. | |
| strsize=size | |
| Maximum size of strings. | |
| stackframes=scalar | |
| Maximum number of kernelspace stack frames to unwind when executing the stack() action. | |
| stackindent=scalar | |
| Number of whitespace characters to use when indenting stack() and ustack() output. | |
| oformat=format | |
|
Specify the format to use for output.
Setting
oformat
to
‘text’
makes
dtrace
use regular human-readable output which is its default behavior.
The options passed to
oformat
are directly forwarded to
libxo(3).
Some of the supported formatters include
‘json’,
‘xml’
and
‘html’.
Note that this option will cause
dtrace
to not produce any output unless printing functions are explicitly called,
or the
| |
| statusrate=time | |
| Rate of status checking. | |
| switchrate=time | |
| Rate of buffer switching. | |
| syslibdir=path | |
| Path to system libraries. Defaults to /usr/lib/dtrace. | |
| ustackframes=scalar | |
| Maximum number of userspace stack frames to unwind when executing the ustack() action. | |
| | |
|
Specify the degree of conformance to the ISO C standard that should be selected
when invoking
cpp(1)
(enabled using the
The
| |
| a |
Default.
ISO C plus K&R compatibility extensions, with semantic changes required by ISO
C.
This is the default mode if
|
| c |
Conformance.
Strictly conformant ISO C, without K&R C compatibility extensions.
The predefined macro __STDC__ has a value of 1 when
cpp(1)
is invoked in conjunction with the
|
| s |
K&R C only.
The macro __STDC__ is not defined when
cpp(1)
is invoked in conjunction with the
|
| t |
Transition.
ISO C plus K&R C compatibility extensions, without semantic changes required by
ISO C.
The predefined macro __STDC__ has a value of 0 when
cpp(1)
is invoked in conjunction with the
|
As the
Regardless of the
Where MM is the major release value in hexadecimal, mmm is the minor release value in hexadecimal, and uuu is the micro release value in hexadecimal.
| | |
|
Permit probe descriptions that match zero probes.
If the
| |
{
"dtrace": {
"probes": [
{
"timestamp": ...,
"cpu": ...,
"id": ...,
"provider": ...,
"module": ...,
"function": ...,
"name": ...,
"output": [
... (script-specific output)
]
}
]
}
}
<?xml version="1.0"?>
<dtrace>
<probes>
<timestamp>...</timestamp>
<cpu>...</cpu>
<id>...</id>
<provider>...</provider>
<module>...</module>
<function>...</function>
<name>...</name>
<output>
... (script-specific output)
</output>
</probes>
</dtrace>
It is also possible for XML output to take the following form if some of the fields are empty (in this example, module and function values are absent):
<?xml version="1.0"?>
<dtrace>
<probes>
...
<module/>
<function/>
...
<output>
... (script-specific output)
</output>
</probes>
</dtrace>
Similarly, oformat can be used to generate HTML:
<div class="line"> <div class="data" data-tag="timestamp">...</div> <div class="text"></div> <div class="data" data-tag="cpu">...</div> <div class="text"></div> <div class="data" data-tag="id">...</div> <div class="text"></div> <div class="data" data-tag="provider">...</div> <div class="text"></div> <div class="data" data-tag="module">...</div> <div class="text"></div> <div class="data" data-tag="function">...</div> <div class="text"></div> <div class="data" data-tag="name">...</div> <div class="data" data-tag="... (script-specific output)">...</div> </div>
Unlike JSON and XML, the "output" array is not present. Instead, data is simply formatted into a div of class "data" and a data-tag is associated with each of the keys.
The "output" array's contents depend on the probes' actions and is explained below. The examples here are presented in JSON form as opposed to XML or HTML, however the conversion explained above applies for all output formats.
Any scalar output, such as output produced by the trace() action is of form:
{
"value": ...
}
The printf() action begins with an object containing the formatted output of the printf() action. Subsequent objects contains the value of each of the arguments to printf() in its raw form as if the trace() action was used instead. A printf() statement which contains no arguments other than the message will only have one object following the message object and its value will always be 0. This is an artefact of the implementation and can safely be ignored.
# dtrace --libxo json,pretty -n 'BEGIN { printf("... %Y, ..", walltimestamp); }'
{
"message": "... 2023 Sep 7 16:49:02, .."
},
{
"value": 1694105342633402400
},
{
...
}
Scalar aggregations are aggregations which produce a single value for a given key. These aggregations include count(), min(), max(), stddev() and sum(). Each one of them is represented by the key containing their name. For example, the output of a stddev() aggregation will contain a key "stddev" inside an "aggregation-data" object:
{
"aggregation-data": [
{
"keys": [
...
],
"stddev": ...
}
],
"aggregation-name": ...
}
The "keys" field remains consistent across all aggregations, however quantize(), lquantize() and llquantize() need to be treated differently. oformat will create a new array of objects called "buckets". Each of the objects contains a "value" and a "count" field which are the left-hand side and the right-hand side of human-readable dtrace output respectively. The full object has the following format:
{
"aggregation-data": [
...
{
"keys": [
...
],
"buckets": [
{
"value": 32,
"count": 0
},
{
"value": 64,
"count": 17
},
...
],
},
...
]
"aggregation-name": ...
}
Similar to scalar aggregations, named scalar actions such as mod(), umod(), usym(), tracemem() and printm() will output an object with the key being equal to the name of the action. For example, printm() output would produce the following object:
{
"printm": "0x4054171100"
}
sym() is slightly different. While it will create a "sym" field which contains its value, in some cases it will also create additional fields "object", "name" and "offset":
# dtrace -x oformat=json,pretty -On 'BEGIN { sym((uintptr_t)&`prison0); }'
{
"sym": "kernel`prison0",
"object": "kernel",
"name": "prison0"
}
# dtrace --libxo json,pretty -On 'BEGIN { sym((uintptr_t)curthread); }'
{
"sym": "0xfffffe00c18d2000",
"offset": "0xfffffe00c18d2000"
}
stack() and ustack() actions unroll each of the stack frames into its own object in an array. The only real difference between them is that the stack() action will produce a list called "stack-frames" while ustack() will produce one called "ustack-frames". The following is an example of their oformat output:
{
"stack-frames": [
{
"symbol": "dtrace.ko`dtrace_dof_create+0x35",
"module": "dtrace.ko",
"name": "dtrace_dof_create",
"offset": "0x35"
},
{
"symbol": "dtrace.ko`dtrace_ioctl+0x81c",
"module": "dtrace.ko",
"name": "dtrace_ioctl",
"offset": "0x81c"
},
...
]
}
{
"ustack-frames": [
{
"symbol": "libc.so.7`ioctl+0xa",
"module": "libc.so.7",
"name": "ioctl",
"offset": "0xa"
},
{
"symbol": "libdtrace.so.2`dtrace_go+0xf3",
"module": "libdtrace.so.2",
"name": "dtrace_go",
"offset": "0xf3"
},
...
]
}
The print() action produces a "type" list in the following form:
{
"type": [
{
"object-name": "kernel",
"name": "struct thread",
"ctfid": 2372
},
{
"member-name": "td_lock",
"name": "struct mtx *volatile",
"ctfid": 2035,
"value": "0xffffffff82158440"
},
...
}
If the type is invalid, a "warning" object will be produced containing the diagnostic message as well as two possible optional fields: "type-identifier" which contains the CTF identifier of the type and "size containing the size of an integer, enum or float." The fields generated will depend on the kind of error that was encountered while processing the trace data.
Finally, oformat provides a special pseudo-probe to represent drops. As dtrace polls for various kinds of drops oformat will produce output similar to the following in order to represent drops:
{
"cpu": -1,
"id": -1,
"provider": "dtrace",
"module": "INTERNAL",
"function": "INTERNAL",
"name": "DROP",
"timestamp": ...,
"count": ...,
"total": ...,
"kind": 2,
"msg": "... dynamic variable drops0
}
| /boot/dtrace.dof | |
| File for anonymous tracing directives. | |
| 0 |
Successful completion.
For D program requests, an exit status of 0 indicates that programs were successfully compiled, probes were successfully enabled, or anonymous state was successfully retrieved. dtrace returns 0 even if the specified tracing requests encountered errors or drops. |
| 1 |
An error occurred.
For D program requests, an exit status of 1 indicates that program compilation failed or that the specified request could not be satisfied. |
| 2 | Invalid command line options or arguments were specified. |
| DTRACE (1) | September 8, 2023 |
| Main index | Section 1 | Options |
Please direct any comments about this manual page service to Ben Bullock. Privacy policy.
