dtrace(8)

πŸ“¦ version 2.0.7, in ubuntu resolute, ubuntu stonking

πŸ’– dtrace(8) β€” Linux Programmer's Manual πŸ’–


NAME

dtrace β€” DTrace dynamic tracing compiler and tracing utility. No cap, that's the whole name.


SYNOPSIS

dtrace [-CeFGHhlqSvVwZ] [-b bufsz] [-c cmd]
       [-D name [=value]] [-I path] [-L path] [-o output]
       [-s script] [-U name] [-x arg [=val]]
       [-X a | c | s | t] [-p pid]
       [-P provider [[predicate] action]]
       [-m [provider:] module [[predicate] action]]
       [-f [[provider:] module:] function [[predicate] action]]
       [-n [[[provider:] module:] function:]name [[predicate] action]]
       [-i probe-id [[predicate] action]]

DESCRIPTION

DTrace is a comprehensive dynamic tracing framework for the Linux operating system. It's giving powerful infrastructure, fr fr. DTrace provides a powerful infrastructure that permits administrators, developers, and service personnel to concisely answer arbitrary questions about the behavior of the operating system and user programs.

The Oracle Linux DTrace Guide describes how to use DTrace to observe, debug, and tune system behavior. Refer to this book for a detailed description of DTrace features, including the bundled DTrace observability tools, instrumentation providers, and the D programming language.

The dtrace command provides a generic interface to the essential services provided by the DTrace facility, including:

  • Options that list the set of probes and providers currently published by DTrace
  • Options that enable probes directly using any of the probe description specifiers (provider, module, function, name)
  • Options that run the D compiler and compile one or more D program files or programs written directly on the command line
  • Options that generate anonymous tracing programs
  • Options that generate program stability reports
  • Options that modify DTrace tracing and buffering behavior and enable additional D compiler features

You can use dtrace to create D scripts by using it in a #! declaration to create an interpreter file. You can also use dtrace to attempt to compile D programs and determine their properties without actually enabling tracing using the -e option. See OPTIONS. See the Oracle Linux DTrace Guide for detailed examples of how to use the dtrace utility to perform these tasks.


OPTIONS

Okay so bestie, the arguments accepted by the -P, -m, -f, -n, and -i options can include an optional D language predicate enclosed in slashes // and optional D language action statement list enclosed in braces {}. D program code specified on the command line must be appropriately quoted to avoid interpretation of meta-characters by the shell. Periodt.

The following options are supported:

  • -b bufsz β€” Sets the principal trace buffer size, aka bufsz. You can throw in any of the size suffixes k, m, g, or t β€” slay. If the buffer space can't be allocated, dtrace will try to shrink the buffer size or just exit, depending on how the bufresize property is set.
  • -c cmd β€” Runs the command you gave as cmd, then dips out when it's done. If you stack more than one -c on the command line, dtrace waits until all the commands have exited, and it reports the exit status for each child process as it terminates. The process-ID of the first command gets handed to any D programs you specified on the command line or with -s, through the $target macro variable. The Oracle Linux DTrace Guide has more on macro variables, iykyk.
  • -C β€” Runs the C preprocessor cpp(1) over your D programs before compiling them. You can pass options to cpp with -D, -U, -I, and -H. If you want to pick how hard it conforms to C standard, use -X. For the tea on the set of tokens the D compiler defines when it invokes the C preprocessor, go look at -X.
  • -D name [=value] β€” Defines name when invoking cpp(1) (this is enabled by -C). If you add the equals sign (=) plus a value, then name gets assigned that value. This option passes -D to every cpp invocation.
  • -e β€” Exits after compiling any requests, but before enabling any probes. You can pair it with D compiler options. This combo checks that the programs compile without actually running them or turning on the matching instrumentation.
  • -f[[provider:]module:]function[[predicate]action]] β€” Says which function to trace or list (listing needs -l). The argument can be any of these probe description forms: provider:module:function, module:function, or function. Fields you leave unspecified stay blank and match any probes no matter what's in those fields. If you only specify function and no other qualifiers, every probe with that function gets matched. You can tack an optional D probe clause onto the -f argument. And yes, you can use more than one -f on the command line at a time.
  • -F β€” Coalesces trace output by spotting function entry and return. Function entry probe reports get indented and their output starts with ->. Function return probe reports get unindented and their output starts with <-. System call entry probe reports get indented and their output starts with =>. System call return probe reports get unindented and their output starts with <=.
  • -G β€” Generates an ELF file with an embedded DTrace program. The DTrace probes you named in the program get saved inside a relocatable ELF object that can be linked into another program. If -o is present, the ELF file is saved using the pathname you gave as that operand. If -o is not present and the DTrace program lives in a file named filename.d, the ELF file is saved as filename.o. Otherwise the ELF file is saved as d.out.
  • -H β€” Prints the pathnames of included files when invoking cpp(1) (enabled by -C). This passes -H to each cpp invocation, so it shows the list of pathnames, one per line, to stderr.
  • -h β€” Generates a header file with macros that correspond to probes in the provider definitions you specified. Use this when you want a header file that other source files can include, for later use with -G. If -o is present, the header file is saved using the pathname you gave for that option. If -o is not present and the DTrace program lives in a file named filename.d, the header file is saved as filename.h.
  • -i probe-id[[predicate] action] β€” Says which probe identifier (probe-id) to trace or list (listing needs -l). You can write probe IDs as decimal integers, exactly like dtrace -l shows them. You can suffix the -i argument with an optional D probe clause. And you can use more than one -i at a time.
  • -I path β€” Adds the directory path to the search path for #include files when invoking cpp(1) (enabled by -C). This passes -I to every cpp invocation. The path you give gets inserted into the search path ahead of the default directory list.
  • -L path β€” Adds the directory path to the search path for DTrace libraries. DTrace libraries hold common definitions you can use when writing D programs. The path you give is added after the default library search path. If it exists, a subdirectory of path named after the minor version of the running kernel (e.g. 3.8) gets searched immediately before path. (But lowkey take note: dependency analysis happens only within each directory, not across directories.)
  • -l β€” Lists probes instead of enabling them. If you use -l, dtrace spits out a report of the probes that match the descriptions you gave with -P, -m, -f, -n, -i, and -s. If you gave none of those options, this lists all probes.
  • -m [[provider:] module: [[predicate] action]] β€” Says which module to trace or list (listing needs -l). The argument can be any of these probe description forms: provider:module or module. Fields you leave unspecified stay blank and match any probes no matter what's in those fields. If you only specify module and no other qualifiers, every probe with a matching module gets matched. You can tack an optional D probe clause onto the -m argument. More than one -m can go on the command line at a time.
  • -n [[[provider:] module:] function:] name [[predicate] action] β€” Says which probe name to trace or list (listing needs -l). The argument can be any of these probe description forms: provider:module:function:name, module:function:name, function:name, or name. Fields you leave unspecified stay blank and match any probes no matter what's in those fields. If you only specify name and no other qualifiers, every probe with a matching name gets matched. You can tack an optional D probe clause onto the -n argument. More than one -n can go on the command line at a time.
  • -o output β€” Sets the output file for the -G, -h, and -l options, or for the traced data itself. If -G is present and the -s option's argument looks like filename.d and -o is not present, the default output file is filename.o. Otherwise the default output file is d.out.
  • -p pid β€” Grabs the process-ID pid, caches its symbol tables, and exits when it's done. If you put more than one -p on the command line, dtrace exits when all commands have exited, and it reports the exit status for each process as it terminates. The first process-ID gets handed to any D programs you specified on the command line or with -s, through the $target macro variable. The Oracle Linux DTrace Guide has more on macro variables.
  • -P provider [[predicate] action] β€” okay so this one says "trace or list (with -l) this provider." The leftover probe description fields β€” module, function, and name β€” are left blank and match any probes no matter what those fields say. The -P argument can be suffixed with an optional D probe clause. And yes, you can specify more than one -P option on the command line at a time. πŸ’–
  • -q β€” quiet mode, bestie. dtrace suppresses messages like the number of probes matched by the specified options and D programs. It also 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 trace() and printf() is displayed to stdout. 🀫
  • -s β€” compile the specified D program source file. If the -e option is present, the program is compiled but instrumentation is not enabled. If the -l option is present, the program is compiled and the set of probes matched by it is listed, but instrumentation is not enabled. If none of -e, -l, or -G are present, the instrumentation specified by the D program is enabled and tracing begins. ✨
  • -S β€” show D compiler intermediate code. The D compiler produces a report of the intermediate code generated for each D program to stderr. πŸ‘€
  • -U name β€” undefine the specified name when invoking cpp(1) (enabled using the -C option). This option passes the -U option to each cpp invocation. 🫢
  • -v β€” set verbose mode. If the -v option is specified, dtrace produces a program stability report showing the minimum interface stability and dependency level for the specified D programs. DTrace stability levels are explained in further detail in the Oracle Linux DTrace Guide. πŸ“š
  • -V β€” report the highest D programming interface version supported by dtrace. The version information is printed to stdout and the dtrace command exits. Refer to the Oracle Linux DTrace Guide for more information about DTrace versioning features. In conjunction with -v, also reports information on the version of the dtrace(1) tool and associated library. 🌟
  • -w β€” permit destructive actions in D programs specified using the -s, -P, -m, -f, -n, or -i options. If the -w option is not specified, dtrace does not permit the compilation or enabling of a D program that contains destructive actions. ⚠️
  • -x arg [=val] β€” enable or modify a DTrace runtime option or D compiler option. The list of options is found in the Oracle Linux DTrace Guide. Boolean options are enabled by specifying their name. Options with values are set by separating the option name and value with an equals sign (=). πŸ”§
  • -Z β€” permit probe descriptions that match zero probes. If the -Z option is not specified, dtrace reports an error and exits if any probe descriptions specified in D program files (-s option) or on the command line (-P, -m, -f, -n, or -i options) contain descriptions that do not match any known probes. πŸ›‘

🌈 OPERANDS 🌈

You can specify zero or more additional arguments on the dtrace command line to define a set of macro variables ($1, $2, and so forth). The additional arguments can be used in D programs specified using the -s option or on the command line. The use of macro variables is described further in the Oracle Linux DTrace Guide. 🧚


πŸ’œ EXIT STATUS πŸ’œ

The following exit values are returned:

  • 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. πŸ’€

πŸ¦‹ ENVIRONMENT VARIABLES πŸ¦‹

The following environment variables are consulted:

  • DTRACE_DEBUG β€” Print libdtrace debugging output on standard error. πŸ›
  • LIBCTF_DEBUG β€” Print CTF type library debugging output on standard error. πŸ›
  • DTRACE_OPT_* β€” Set a given DTrace option. Options set this way are overridden both by options specified via -x on the command line, and by setopt statements. πŸ‘‘

πŸŽ€ SEE ALSO πŸŽ€


🌸 USAGE 🌸

When using the -p flag, dtrace stops the target processes while it is inspecting them and reporting results. A process can do nothing while it is stopped. This means that, if, for example, the X server is inspected by dtrace running in a window under the X server's control, the whole window system can become deadlocked, because the dtrace tool would be attempting to display its results to a window that cannot be refreshed. In such a case, logging in from another system using ssh(1) and killing the offending dtrace tool clears the deadlock. 🚨


This whole masterpiece is from Oracle Linux, dated 22 Oct 2014, and it's the dtrace(8) page. Periodt. πŸ’…

πŸ“¦ where this page comes from