lttng-snapshot — Take LTTng snapshots and configure snapshot outputs
Add a snapshot output:
lttng [GENERAL OPTIONS] snapshot add-output [
Remove a snapshot output:
lttng [GENERAL OPTIONS] snapshot del-output [
List current snapshot outputs:
lttng [GENERAL OPTIONS] snapshot list-output [
Take a snapshot:
lttng [GENERAL OPTIONS] snapshot record [
lttng snapshot command manages the snapshot outputs and takes
A snapshot is a dump of the current sub-buffers of all the channels of a given tracing session. When a snapshot is taken, the memory dump is sent to the registered snapshot outputs.
The tracing session should be created in snapshot mode to make sure taking snapshots is allowed. This is done at tracing session creation time using the lttng-create(1) command.
Note that, when a snapshot is taken, the sub-buffers are not cleared. This means that different recorded snapshots may contain the same events.
Snapshot outputs are the destinations of snapshot files when a
snapshot is taken using the
As of this version, only one snapshot output is allowed.
A snapshot output can be added using the
add-output action. The
output destination URL is set using either the
argument, or both the
See lttng-create(1) to learn more about the URL format.
A name can be assigned to an output when adding it using the
--name option. This name is part of the names of the
snapshot files written to this output.
By default, the snapshot files can be as big as the sum of the
sizes of all the sub-buffers or all the channels of the selected
tracing session. The maximum total size of all the snapshot files can
be configured using the
Snapshot outputs can be listed using the
Snapshot outputs can be removed using the
del-output action. The
configured name can be used when removing an output, or an ID as
listed by the
Taking a snapshot of the current tracing session is as easy as:
lttng snapshot record
This writes the snapshot files to the configured output. It is possible
to use a custom, unregistered output at record time using the same
options supported by the
Note:Before taking a snapshot on a system with a high event throughput,
it is recommended to first run
lttng stop (see
lttng-stop(1)). Otherwise, the snapshot could contain "holes",
the result of the tracers overwriting unconsumed trace packets during
the record operation. After the snapshot is recorded, the tracers can be
started again with
lttng start (see lttng-start(1)).
Set control path URL to
URL (must use
Set data path URL to
URL (must use
Limit the total size of all the snapshot files written when
recording a snapshot to
SIZE bytes. The
G (GiB) suffixes are supported.
Assign the name
NAME to the snapshot output.
Set to 1 to abort the process after the first error is encountered.
$HOME environment variable. Useful when the user
running the commands has a non-writable home directory.
Absolute path to the man pager to use for viewing help information
about LTTng commands (using lttng-help(1) or
lttng COMMAND --help).
Path in which the
session.xsd session configuration XML
schema may be found.
Full session daemon binary path.
--sessiond-path option has precedence over this
Note that the lttng-create(1) command can spawn an LTTng session daemon automatically if none is running. See lttng-sessiond(8) for the environment variables influencing the execution of the session daemon.
User LTTng runtime configuration.
This is where the per-user current tracing session is stored between executions of lttng(1). The current tracing session can be set with lttng-set-session(1). See lttng-create(1) for more information about tracing sessions.
Default output directory of LTTng traces. This can be overridden
--output option of the lttng-create(1)
User LTTng runtime and configuration directory.
$LTTNG_HOME defaults to
$HOME when not explicitly set.
Command warning (something went wrong during the command)
If you encounter any issue or usability problem, please report it on the LTTng bug tracker.
Special thanks to Michel Dagenais and the DORSAL laboratory at École Polytechnique de Montréal for the LTTng journey.
Also thanks to the Ericsson teams working on tracing which helped us greatly with detailed bug reports and unusual test cases.