-.TH "LTTNG" "1" "February 05th, 2014" "" ""
+.TH "LTTNG" "1" "May 13th, 2014" "" ""
.SH "NAME"
-lttng \(em LTTng 2.x tracer control command line tool
+lttng \- LTTng 2.x tracer control command line tool
.SH "SYNOPSIS"
those traces is done using the babeltrace(1) text viewer.
We introduce the notion of \fBtracing domains\fP which is essentially a type of
-tracer (kernel, user space or JUL for now). In the future, we could see more
-tracer like for instance an hypervisor. For some commands, you'll need to
-specify on which domain the command operates (\-u, \-k or \-j). For instance,
-the kernel domain must be specified when enabling a kernel event.
+tracer (kernel, user space, JUL, LOG4J or Python for now). In the future, we
+could see more tracer like for instance an hypervisor. For some commands,
+you'll need to specify on which domain the command operates (\-u, \-k, \-l, \-j
+or \-p). For instance, the kernel domain must be specified when enabling a
+kernel event.
In order to trace the kernel, the session daemon needs to be running as root.
LTTng provides the use of a \fBtracing group\fP (default: tracing). Whomever is
root daemon or even a Bob daemon. We highly recommend starting the session
daemon at boot time for stable and long term tracing.
-All user-space applications instrumented with lttng-ust(3) will
-automatically register to the session daemon. This feature gives you the
-ability to list available traceable applications and tracepoints on a per user
-basis. (See \fBlist\fP command).
+Each user-space application instrumented with lttng-ust(3) will automatically
+register with the root session daemon and its user session daemon. This allows
+each daemon to list the available traceable applications and tracepoints at any
+given moment (See the \fBlist\fP command).
.SH "OPTIONS"
.PP
-This program follow the usual GNU command line syntax with long options starting with
+This program follows the usual GNU command line syntax with long options starting with
two dashes. Below is a summary of the available options.
.PP
.BR "\-h, \-\-help"
Show summary of possible options and commands.
.TP
+.BR "\-V, \-\-version"
+Show version.
+.TP
.BR "\-v, \-\-verbose"
Increase verbosity.
Three levels of verbosity are available which are triggered by putting additional v to
.TP
.BR "\-\-list\-commands"
Simple listing of lttng commands.
+.TP
+.BR "\-m, \-\-mi TYPE
+Machine interface
+
+TYPE supported: XML
+
+Machine interface (MI) mode converts the traditional pretty printing to a
+machine output syntax. MI mode provides a format change-resistant way to access
+information generated via the lttng command line.
+
+When using MI mode, the data is printed on \fBstdout\fP. Error and warning are
+printed on \fBstderr\fP with the pretty print default format.
+
+If any errors occur during the execution of a command, the return value of the
+command will be different than zero. In this case, lttng does NOT guarantee the
+syntax and data validity of the generated MI output.
+
+For XML output type, a schema definition (XSD) file used for validation can be
+found under src/common/mi_lttng.xsd
+
.SH "COMMANDS"
.PP
A context is basically extra information appended to a channel. For instance,
you could ask the tracer to add the PID information for all events in a
channel. You can also add performance monitoring unit counters (perf PMU) using
-the perf kernel API).
+the perf kernel API.
-For example, this command will add the context information 'prio' and two perf
-counters (hardware branch misses and cache misses), to all events in the trace
+For example, this command will add the context information 'prio' and two per-CPU
+perf counters (hardware branch misses and cache misses), to all events in the trace
data output:
.nf
-# lttng add-context \-k \-t prio \-t perf:branch-misses \\
- \-t perf:cache-misses
+# lttng add-context \-k \-t prio \-t perf:cpu:branch-misses \\
+ \-t perf:cpu:cache-misses
.fi
Please take a look at the help (\-h/\-\-help) for a detailed list of available
contexts.
+Perf counters are available as per-CPU ("perf:cpu:...") and per-thread
+("perf:thread:...") counters. Currently, per-CPU counters can only be
+used with the kernel tracing domain, and per-thread counters can only be
+used with the UST tracing domain.
+
If no channel is given (\-c), the context is added to all channels that were
already enabled. If the session has no channel, a default channel is created.
Otherwise the context will be added only to the given channel (\-c).
# lttng create calibrate-function
# lttng enable-event calibrate \-\-kernel \\
\-\-function lttng_calibrate_kretprobe
-# lttng add-context \-\-kernel \-t perf:LLC-load-misses \\
- \-t perf:LLC-store-misses \\
- \-t perf:LLC-prefetch-misses
+# lttng add-context \-\-kernel \-t perf:cpu:LLC-load-misses \\
+ \-t perf:cpu:LLC-store-misses \\
+ \-t perf:cpu:LLC-prefetch-misses
# lttng start
# for a in $(seq 1 10); do \\
lttng calibrate \-\-kernel \-\-function;
variable LTTNG_HOME. This is useful when the user running the commands has
a non-writeable home directory.
+The session name MUST NOT contain the character '/'.
+
.B OPTIONS:
.TP
URL, if one is specified, as the default snapshot output. Every channel will be set
in overwrite mode and with mmap output (splice not supported).
.TP
-.BR "\-\-live USEC"
-Set the session exclusively in live mode. The paremeter is the delay in micro
+.BR "\-\-live [USEC]"
+Set the session exclusively in live mode. The parameter is the delay in micro
seconds before the data is flushed and streamed. The live mode allows you to
stream the trace and view it while it's being recorded by any tracer. For that,
you need a lttng-relayd and this session requires a network URL (\-U or
-\-C/\-D).
+\-C/\-D). If no USEC nor URL is provided, the default is to use a timer value
+set to 1000000 and the network URL set to net://127.0.0.1.
To read a live session, you can use babeltrace(1) or the live streaming
protocol in doc/live-reading-protocol.txt. Here is an example:
After the start, you'll be able to read the events while they are being
recorded in /tmp/lttng.
+.TP
+.BR "\-\-shm-path PATH"
+
+Path where shared memory holding buffers should be created. Useful
+when used with PRAMFS or other persistent memory filesystems to extract
+trace data in the event of a crash requiring a reboot.
+
+See the \fBlttng-crash(1)\fP utility for more information on crash recovery.
+
.TP
.BR "\-U, \-\-set-url=URL"
Set URL for the consumer output destination. It is persistent for the
Discard event when subbuffers are full (default)
.TP
.BR "\-\-overwrite"
-Flight recorder mode : overwrites events when subbuffers are full
+Flight recorder mode: overwrites events when subbuffers are full. The
+number of subbuffer must be 2 or more.
.TP
.BR "\-\-subbuf-size SIZE"
Subbuffer size in bytes {+k,+M,+G}.
.BR "\-C, \-\-tracefile-size SIZE"
Maximum size of each tracefile within a stream (in bytes).
0 means unlimited. (default: 0)
+Note: traces generated with this option may inaccurately report
+discarded events as of CTF 1.8.
.TP
.BR "\-W, \-\-tracefile-count COUNT"
Used in conjunction with \-C option, this will limit the number of files
.BR "\-j, \-\-jul"
Apply for Java application using Java Util Logging interface (JUL)
.TP
+.BR "\-l, \-\-log4j"
+Apply for Java application using LOG4J
+.TP
+.BR "\-p, \-\-python"
+Apply for Python application using the logging module.
+.TP
.BR "\-\-tracepoint"
Tracepoint event (default). Userspace tracer supports wildcards at the end
of string. Don't forget to quote to deal with bash expansion.
.TP
.BR "\-\-loglevel NAME"
Tracepoint loglevel range from 0 to loglevel. Listed in the help (\-h).
+For the JUL domain, the loglevel ranges are detailed with the \-\-help
+option thus starting from SEVERE to FINEST.
+For the LOG4J domain, loglevels range from FATAL to TRACE which are also
+detailed in the help.
+For the Python domain, loglevels range from CRITICAL to DEBUG which are
+detailed in the help as well.
.TP
.BR "\-\-loglevel-only NAME"
Tracepoint loglevel (only this loglevel).
.BR "\-\-syscall"
System call event. Enabling syscalls tracing (kernel tracer), you will
not be able to disable them with disable-event. This is a known
-limitation. You can disable the entire channel to do the trick.
+limitation. You can disable the entire channel to do the trick. Also note
+that per-syscall selection is not supported yet. Use with "-a" to enable
+all syscalls.
.TP
.BR "\-\-filter 'expression'"
Set a filter on a newly enabled event. Filter expression on event
'$ctx.vtid == 1234'
.fi
+Context information is available to all filters whether or not the add-context
+command has been used to add it to the event's channel, as long as the context
+field exists for that domain. For example, the filter examples given above will
+never fail to link: no add-context is required for the event's channel.
+
.TP
.BR "\-x, \-\-exclude LIST"
Add exclusions to UST tracepoints:
Disable tracing channel
Disabling a channel disables the tracing of all of the channel's events. A channel
-can be reenabled by calling \fBlttng enable-channel NAME\fP again.
+can be re-enabled by calling \fBlttng enable-channel NAME\fP again.
If \fB\-s, \-\-session\fP is omitted, the session name is taken from the .lttngrc
file.
.TP
.BR "\-j, \-\-jul"
Apply for Java application using Java Util Logging interface (JUL)
+.TP
+.BR "\-l, \-\-log4j"
+Apply for Java application using LOG4J
+.TP
+.BR "\-p, \-\-python"
+Apply for Python application using the logging module.
.RE
.PP
calls events).
With \-j alone, the available JUL event from registered application will be
list. The event corresponds to the Logger name in the Java JUL application.
+With \-l alone, the available LOG4J event from registered application will be
+list. The event corresponds to the Logger name in the Java LOG4J application.
+With \-p alone, the available Python event from registered application will be
+list. The event corresponds to the Logger name in the Python application.
With \-u alone, it will list all available user-space events from registered
applications. Here is an example of 'lttng list \-u':
.BR "\-j, \-\-jul"
Apply for Java application using JUL
.TP
+.BR "\-l, \-\-log4j"
+Apply for Java application using LOG4J
+.TP
+.BR "\-p, \-\-python"
+Apply for Python application using the logging module.
+.TP
.BR "\-f, \-\-fields"
List event fields
.RE
.PP
+.PP
+\fBload\fP [OPTIONS] [NAME]
+.RS
+Load tracing session configuration
+
+If NAME is omitted, all session configurations found in both the user's session
+configuration directory (default: ~/.lttng/sessions/) and the system session
+configuration directory (default: /etc/lttng/sessions/) will be loaded. Note
+that the sessions in the user directory are loaded first and then the system
+wide directory are loaded.
+
+.B OPTIONS:
+
+.TP
+.BR "\-h, \-\-help"
+Show summary of possible options and commands.
+.TP
+.BR "\-a, \-\-all"
+Load all session configurations (default).
+.TP
+.BR "\-i, \-\-input-path PATH"
+Specify the input path for session configurations. This overrides the default
+session configuration directory.
+.TP
+.BR "\-f, -\-force"
+Overwrite current session configuration(s) if a session of the same name
+already exists.
+.RE
+.PP
+
+.PP
+\fBsave\fP [OPTIONS] [SESSION]
+.RS
+Save tracing session configuration
+
+If SESSION is omitted, all session configurations will be saved to individual
+\fB.lttng\fP files under the user's session configuration directory (default:
+~/.lttng/sessions/). The default session configuration file naming scheme is
+\fBSESSION.lttng\fP.
+
+For instance, a user in the tracing group saving a session from a root session
+daemon will save it in her/his user directory.
+
+.B OPTIONS:
+
+.TP
+.BR "\-h, \-\-help"
+Show summary of possible options and commands.
+.TP
+.BR "\-a, \-\-all"
+Save all session configurations (default).
+.TP
+.BR "\-o, \-\-output-path PATH"
+Specify the output path for saved sessions. This overrides the default session
+configuration directory.
+.TP
+.BR "\-f, -\-force"
+Overwrite session configuration file if session name clashes.
+.RE
+.PP
+
.PP
\fBset-session\fP NAME [OPTIONS]
.RS
.TP
\fBadd-output\fP [-m <SIZE>] [-s <NAME>] [-n <NAME>] <URL> | -C <URL> -D <URL>
-Setup and add an snapshot output for a session. Output are the destination
+Setup and add a snapshot output for a session. Output is the destination
where the snapshot will be sent. Only one output is permitted. To change it,
you'll need to delete it and add back the new one.
.TP
\fBdel-output\fP ID | NAME [-s <NAME>]
-Delete an output for a session using the ID. You can either specify the
-output's ID that can be found with list-output or the name.
+Delete an output for a session using the output's ID. You can either specify the
+output by name or use its ID as returned by the list-output command.
.TP
\fBlist-output\fP [-s <NAME>]
Name of the snapshot's output.
.TP
.BR "\-m, \-\-max-size SIZE"
-Maximum size in bytes of the snapshot. The maxium size does not include the
+Maximum size in bytes of the snapshot. The maximum size does not include the
metadata file. Human readable format is accepted: {+k,+M,+G}. For instance,
\-\-max-size 5M
.TP
.TP
.BR "\-\-list-options"
Simple listing of options
-.TP "\-\-no-wait"
+.TP
+.BR "\-\-no-wait"
Don't wait for data availability.
.RE
.PP
.RE
.PP
-.SH "JUL DOMAIN"
-This section explains the JUL domain (\-j, \-\-jul) where JUL stands for Java
-Util Logging. You can use that feature by using the \fBliblttng-ust-jul.so\fP
-from the lttng-ust(3) project.
+.SH "JUL/LOG4J DOMAIN"
+
+This section explains the JUL and LOG4J domain where JUL stands for Java Util
+Logging. You can use these by using the \fBliblttng-ust-<domain>-jni.so\fP from
+the lttng-ust(3) project.
The LTTng Java Agent uses JNI to link the UST tracer to the Java application
that uses the agent. Thus, it behaves similarly to the UST domain (\-u). When
-enabling events with the JUL domain, you enable a Logger name that will then be
-mapped to a default UST tracepoint called \fBlttng_jul:jul_event\fP in the
-\fBlttng_jul_channel\fP. Using the lttng-ctl API, any JUL events must use the
-tracepoint event type (same as \-\-tracepoint).
+enabling events, you enable a Logger name that will then be mapped to a default
+UST tracepoint called \fBlttng_jul:<domain>_event\fP in the
+\fBlttng_<domain>_channel\fP. Using the lttng-ctl API, any JUL/LOG4J events
+must use the tracepoint event type (same as \-\-tracepoint).
-Because of the default immutable channel (\fBlttng_jul_channel\fP), the
-\fBenable-channel\fP command CAN NOT be used with the JUL domain thus not
-having any \-j option.
+Because of the default immutable channel, the \fBenable-channel\fP command CAN
+NOT be used with the JUL and LOG4J domain thus not having any options.
-For JUL event, loglevels are supported with the JUL ABI values. Use \fBlttng
-enable-event \-h\fP to list them. Wildcards are NOT supported except the "*"
-meaning all events (same as \-a).
+Also, loglevels are supported. Use \fBlttng enable-event \-h\fP to list them.
+Wildcards are NOT supported except the "*" meaning all events (same as \-a).
Exactly like the UST domain, if the Java application has the same UID as you,
you can trace it. Same goes for the tracing group accessing root applications.
-Finally, you can list every Logger name that are available from JUL registered
-applications to the session daemon by using \fBlttng list \-j\fP.
+Finally, you can list every Logger name that are available from registered
+applications to the session daemon by using \fBlttng list \-j\fP or \fB\-l\fP.
-Here is an example on how to use this domain.
+Here is an example on how to use the JUL domain.
.nf
$ lttng list -j
tool. You can also use \-\-sessiond-path option having the same effect.
.PP
+.PP
+.IP "LTTNG_SESSION_CONFIG_XSD_PATH"
+Set the path in which the \fBsession.xsd\fP session configuration schema may be
+found.
+.PP
+
.SH "SEE ALSO"
.BR babeltrace(1),
.BR lttng-ust(3),
.BR lttng-sessiond(8),
.BR lttng-relayd(8),
+.BR lttng-crash(1),
.SH "BUGS"
.PP
If you encounter any issues or usability problem, please report it on our
mailing list <lttng-dev@lists.lttng.org> to help improve this project or
-at https://bugs.lttng.org which is a bugtracker.
+at https://bugs.lttng.org which is a bug tracker.
.PP
.SH "CREDITS"
.PP
lttng-tools was originally written by Mathieu Desnoyers, Julien Desfossez and
David Goulet. More people have since contributed to it. It is currently
-maintained by David Goulet <dgoulet@efficios.com>.
+maintained by Jérémie Galarneau <jeremie.galarneau@efficios.com>.
.PP
projects / lttng-tools.git / blobdiff