LTTng bugs repository: Issueshttps://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912017-11-15T23:37:32ZLTTng bugs repository
Redmine LTTng-tools - Feature #1137 (Confirmed): Version handshake for lttng-consumerd and lttng-sessiondhttps://bugs.lttng.org/issues/11372017-11-15T23:37:32ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
Scenario:
<ul>
<li>User installed both a 32bit and 64 bit version of lttng-tools 2.X.</li>
<li>User uses in script lttng-session --consumerd32-path= --consumerd64-path=</li>
<li>User update the 64bit version to lttng-tools 2.(X+1) without upgrading</li>
<li>User still uses it's script but with the lttng-sessiond bin from lttng-tools 2.(X+1)</li>
</ul>
<p>Currently the consumerd and sessiond do not exchange version information hence we end up with undefined behaviour.</p>
<p>The version numbering might be coupled with the version of lttng but it is most probably wiser to use a separate versioning.</p> LTTng-tools - Feature #1127 (Confirmed): regression/tool/filtering use local gen-ust-event instea...https://bugs.lttng.org/issues/11272017-07-28T23:28:35ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>It should be possible to use the one from tests/utils.</p> LTTng - Feature #990 (Confirmed): Additional make check targetshttps://bugs.lttng.org/issues/9902016-01-19T20:23:31ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>We might want to add more make check targets to ease testing both manually and via ci.</p>
<p>E.g.<br />make check_verbose<br />make check_archive<br />make check_root<br />etc.</p> LTTng-tools - Feature #985 (Confirmed): Print *real* total size of buffers on channel listinghttps://bugs.lttng.org/issues/9852015-12-10T21:25:52ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>The sub-buffers size currently reported is nice but we miss to inform the user the actual total size on disk/memory.</p>
<p>Ex: num_subbuffer * num_cpu * subbefers_size</p>
<p>We might want to add the current number of (max possible) cpu to listing.<br />b</p> LTTng-tools - Feature #932 (Confirmed): LTTng client error code semantics are ill-definedhttps://bugs.lttng.org/issues/9322015-09-05T16:34:01ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>The LTTNG (1) man page mentions that</p>
<pre>
On success 0 is returned and a positive value on error. Value of 1 means a command error, 2 an undefined command, 3 a fatal error and 4 a command warning meaning that something went wrong during the command.
Any other value above 10, please refer to <lttng/lttng-error.h> for a detailed list or use lttng_strerror() to get a human readable string of the error code.
</pre>
<p>There are a number of things wrong with this. First of all, asking script authors to check some obscure error header deep in the bowels of their system is questionable, at best.</p>
<p>Second, as remarked by Michael Jeanson, Philippe Proulx, most command-line utilities don't return an error code to indicate a warning. A non-zero error code means an error as occurred.</p>
<p>We will have to go through commands and determine which errors are in fact harmless warnings (e.g. enabling the same event twice), and which ones shall signal an error (e.g. invalid channel configuration).</p> LTTng-tools - Feature #894 (Confirmed): Cannot enable channel for JUL (-j) or Log4j (-l) domainshttps://bugs.lttng.org/issues/8942015-07-21T21:23:00ZAnonymous
<p>The <code>lttng enable-event</code> command allows <code>-j</code> or <code>-l</code> flags, to enable events for the JUL and Log4j domains respectively. However, the <code>lttng enable-channel</code> command does not allow these flags. Interestingly, the "missing domain" error message mentions the <code>-j</code> flag, but it does not actually work:</p>
<pre><code>$ lttng enable-channel MyChannel<br /> Error: Please specify a domain (-k/-u/-j).<br /> Error: Command error</code></pre>
<pre><code>$ lttng enable-channel MyChannel -j<br /> usage: lttng enable-channel NAME[,NAME2,...] (-u | -k) [OPTIONS]<br /> ...</code></pre> LTTng-tools - Feature #750 (Confirmed): lttng add-context --channel should accept a list of channelshttps://bugs.lttng.org/issues/7502014-03-07T17:14:31ZDaniel U. Thibaultdaniel.thibault@drdc-rddc.gc.ca
<p>It would be nice if the <code>--channel</code> option of the <code>lttng add-context</code> command accepted a list of channel names (e.g. comma-separated with no intervening spaces).</p> LTTng-tools - Feature #749 (Confirmed): lttng list <session> should list the contexts added to ea...https://bugs.lttng.org/issues/7492014-03-07T16:36:19ZDaniel U. Thibaultdaniel.thibault@drdc-rddc.gc.ca
<p>It would be nice if the <code>lttng list <session></code> command listed the context currently added to each channel. Currently, it does not mention context at all.</p> LTTng-tools - Feature #632 (Confirmed): Several commands could benefit from an "all" optionhttps://bugs.lttng.org/issues/6322013-09-17T15:17:18ZDaniel U. Thibaultdaniel.thibault@drdc-rddc.gc.ca
<p>Several commands (<code>destroy</code>, <code>list</code>, <code>snapshot</code>, <code>start</code>, <code>stop</code>, <code>view</code>) could use an <code>-A, --all-sessions</code> option. The option would obviate the need for a <code>session_name</code> argument or <code>-s, --session</code> option (and ignore the default supplied by <code>.lttngrc</code>) and apply to all sessions known by the session daemon.</p>
<p>This could be used, for example, when several sessions are created and configured, and the user wishes to start/stop them all at once.</p>
<p>The name <code>-A, --all-sessions</code> preserves the possibility of extending the option to commands that already have an <code>-a, --all</code> or <code>-a, --all-events</code> option, such as <code>enable-event</code> and <code>disable-event</code>. This would be useful if an event has been defined in several sessions which are already being started/stopped as a group using <code>-A, --all-sessions</code>.</p>
<p>The <code>-A, --all-sessions</code> option could even be eventually extended to <code>add-context</code>, <code>enable-channel</code>, and <code>disable-channel</code>.</p>
<p>To give an advanced example, <code>enable-event -A</code> would enable the event(s) in all sessions where it exists (if started) or can be created (if not started yet); each session where the command causes an error would have the error reported but processing would continue to the next session. The output would be something like:</p>
<pre>
$ lttng start -A
Session sessionnameone:
Tracing started for session sessionnameone
Session sessionnametwo:
Warning: Tracing already started for session sessionnametwo
Session sessionnamethree:
Tracing started for session sessionnamethree
</pre>
<p>Besides the usual "unrecognized command or option" errors, return codes would need to be created for the overall outcomes: all session commands succeeded (CMD_SUCCESS), some or all session commands resulted in a warning (CMD_WARNING), etc. This would reflect an ordering of the CMD_* constants in command.h (maybe CMD_SUCCESS < CMD_UNDEFINED < CMD_UNSUPPORTED < CMD_WARNING < CMD_ERROR < CMD_FATAL).</p> LTTng-tools - Feature #599 (Confirmed): second snapshot not to gather data from the previous snap...https://bugs.lttng.org/issues/5992013-07-21T22:41:43Zyin sunsunyin51@gmail.com
<p>be able to specify portion of buffer in snapshot mode.<br />the purpose is to let the second snapshot only take "new" data comparing to the previous snapshot. <br />This is useful to "tail -f" like function.</p> LTTng-tools - Feature #573 (Confirmed): Destroy an internal domain session on command error if cr...https://bugs.lttng.org/issues/5732013-06-25T16:02:19ZDavid Goulet
<p>For instance, if enable-channel -k command fails and a kernel session was created prior to the command failing, it should be cleaned up. This goes for every possible command that can fail on a specific domain and the internal session was created.</p> LTTng-tools - Feature #566 (Confirmed): User-space data buffering schemes and the lttng user inte...https://bugs.lttng.org/issues/5662013-06-20T20:40:18ZDaniel U. Thibaultdaniel.thibault@drdc-rddc.gc.ca
<p>Here is a typical log with the current almost-2.2.0-rc3 version of lttng:<br /><pre>
$ sudo -H lttng create uid -U net://131.132.32.77
Spawning a session daemon
Session uid created.
Traces will be written in net://131.132.32.77
$ sudo -H lttng enable-channel --buffers-uid -u canaluid
UST channel canaluid enabled for session uid
$ sudo -H lttng enable-event -u -a
Error: Events: Buffer type mismatch for session (channel channel0, session uid)
$ sudo -H lttng enable-event -u -a -c canaluid
All UST events are enabled in channel canaluid
$ sudo -H lttng start
Tracing started for session uid
$ sudo -H lttng destroy
</pre></p>
<p>Once <code>enable-channel --buffers-uid</code> is issued, it is understood the entire user-space domain will be using per-uid buffers. (This may change with later incarnations of lttng, I presume? Are there plans to allow per-channel control of the buffering schemes?)</p>
<p>The following <code>enable-event -u</code> command tries to create the default channel (<code>channel0</code>) because the user did not specify <code>-c</code>...But why does it try to create that channel using <code>--buffers-pid</code>? The session daemon <em>knows</em> that the user-space channels are now per-uid.</p>
<p>Resolution: The session daemon should switch the channel buffering scheme default of each session to per-uid whenever this is established by the user's first <code>enable-channel</code> or <code>enable-event</code> command. In other words, <code>--buffers-pid</code> should be the default only when the first <code>enable-channel</code> is issued (implicitly or explicitly).</p>
<p>It would also be appreciated if a user message were issued when that decision (per-pid vs. per-uid) is taken. Thus our previous session would become:</p>
<pre>
$ sudo -H lttng create uid -U net://131.132.32.77
Spawning a session daemon
Session uid created.
Traces will be written in net://131.132.32.77
$ sudo -H lttng enable-channel --buffers-uid -u canaluid
UST channel canaluid enabled for session uid
UST buffering is per UID
$ sudo -H lttng enable-event -u -a
All UST events are enabled in channel channel0
$ sudo -H lttng start
Tracing started for session uid
$ sudo -H lttng destroy
</pre> LTTng-tools - Feature #558 (Confirmed): Apply fd accounting technique from sessiond to consumerdhttps://bugs.lttng.org/issues/5582013-06-04T22:09:02ZDavid GouletLTTng-tools - Feature #555 (Confirmed): add-context --help lists perf fields even when the machin...https://bugs.lttng.org/issues/5552013-05-31T18:13:39ZDaniel U. Thibaultdaniel.thibault@drdc-rddc.gc.ca
<p>This was taken from a machine running 3.2.0-40-virtual:</p>
<pre>
$ lttng add-context --help
usage: lttng add-context -t TYPE [-k|-u] [OPTIONS]
[...]
Context:
-t, --type TYPE Context type. You can repeat that option on
the command line to specify multiple contexts at once.
(--kernel preempts --userspace)
TYPE can be one of the strings below:
pid, procname, prio, nice, vpid, tid, pthread_id,
vtid, ppid, vppid, hostname, perf:cpu-cycles,
perf:cycles, perf:stalled-cycles-frontend,
perf:idle-cycles-frontend,
perf:stalled-cycles-backend,
perf:idle-cycles-backend, perf:instructions,
perf:cache-references, perf:cache-misses,
perf:branch-instructions, perf:branches,
perf:branch-misses, perf:bus-cycles,
perf:L1-dcache-loads, perf:L1-dcache-load-misses,
perf:L1-dcache-stores,
perf:L1-dcache-store-misses,
perf:L1-dcache-prefetches,
perf:L1-dcache-prefetch-misses,
perf:L1-icache-loads, perf:L1-icache-load-misses,
perf:L1-icache-stores,
perf:L1-icache-store-misses,
perf:L1-icache-prefetches,
perf:L1-icache-prefetch-misses, perf:LLC-loads,
perf:LLC-load-misses, perf:LLC-stores,
perf:LLC-store-misses, perf:LLC-prefetches,
perf:LLC-prefetch-misses, perf:dTLB-loads,
perf:dTLB-load-misses, perf:dTLB-stores,
perf:dTLB-store-misses, perf:dTLB-prefetches,
perf:dTLB-prefetch-misses, perf:iTLB-loads,
perf:iTLB-load-misses, perf:branch-loads,
perf:branch-load-misses, perf:cpu-clock,
perf:task-clock, perf:page-fault, perf:faults,
perf:major-faults, perf:minor-faults,
perf:context-switches, perf:cs,
perf:cpu-migrations, perf:migrations,
perf:alignment-faults, perf:emulation-faults
Example:
[...]
$ dmesg | grep "generic register"
$
</pre>
<p>Trying to <code>add-context -t perf:*</code> on such a machine fails, of course.</p>
<p>It would be a simple yet useful enhancement to forgo listing perf context types when none are actually possible.</p> LTTng-UST - Feature #327 (On pause): Implement missing hostname contexthttps://bugs.lttng.org/issues/3272012-08-26T23:22:47ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>To match features of lttng-modules.</p>