Project

General

Profile

Actions

Feature #445

open

lttng enable-event and event redefinition: user feedback can be misleading

Added by Daniel U. Thibault almost 12 years ago. Updated about 9 years ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Target version:
Start date:
02/14/2013
Due date:
% Done:

0%

Estimated time:

Description

Here is an abridged log that outlines the problem:

$ sudo -H lttng create asession
Session asession created.
Traces will be written in /root/lttng-traces/asession-20130214-134634
$ sudo -H lttng list asession
Tracing session asession: [inactive]
    Trace path: /root/lttng-traces/asession-20130214-134634

$ sudo -H lttng enable-event sched_switch -k --tracepoint
kernel event sched_switch created in channel channel0
$ sudo -H lttng list asession
Tracing session asession: [inactive]
      [...]
    Events:
      sched_switch (loglevel: TRACE_EMERG (0)) (type: tracepoint) [enabled]

$ sudo -H lttng disable-event sched_switch -k
kernel event sched_switch disabled in channel channel0 for session asession
$ sudo -H lttng list asession
Tracing session asession: [inactive]
      [...]
    Events:
      sched_switch (loglevel: TRACE_EMERG (0)) (type: tracepoint) [disabled]

$ sudo -H lttng enable-event sched_switch -k --function lttng_calibrate_kretprobe
kernel event sched_switch created in channel channel0
$ sudo -H lttng list asession
Tracing session asession: [inactive]
      [...]
    Events:
      sched_switch (loglevel: TRACE_EMERG (0)) (type: tracepoint) [enabled]

The problem is that when the user tries to redefine an event by issuing enable-event again, if the event is enabled he gets LTTNG_ERR_KERN_EVENT_EXIST "Kernel event already exists", but if it is disabled, he gets no error and apparent confirmation ("kernel event sched_switch created in channel channel0"). This can be misleading.

It seems the intent is that an event, once defined, is immutable. In that case, any redefinition attempt should yield LTTNG_ERR_KERN_EVENT_EXIST, whether the event is currently enabled or not. Having a dual-use command "enable-event" that acts upon a number of its options only when the event is first defined, while ignoring them when the event is merely re-enabled, is confusing for the user (it also makes the code unwieldy).

My suggestion is that event definition be split off into its own command, "define-event", while restricting "enable-event" to enabling already-defined events only. The corresponding --help could be something like this (abridged):

usage: lttng define-event [NAME (-k|-u)] [OPTIONS]

Options:
  -h, --help               Show this help and exit
      --list-options       List the options and exit
  -s, --session NAME       Apply to session NAME
  -k, --kernel             Apply to the kernel tracer
  -u, --userspace          Apply to the userspace tracer
  -c, --channel NAME       Apply to channel NAME

Event options:
    --tracepoint           Tracepoint event (default)
    --probe [addr | symbol | symbol+offset]
                           Dynamic probe. Kernel only.
                           Addr and offset can be octal (0NNN...),
                           decimal (NNN...) or hexadecimal (0xNNN...)
    --function [addr | symbol | symbol+offset]
                           Dynamic function entry/return probe. Kernel only.
    --syscall              System call event. Kernel only.
    --loglevel NAME        Tracepoint loglevel range from 0 to NAME.
                           Userspace only.
    --loglevel-only NAME   Tracepoint loglevel (only NAME)
                           Userspace only.
    --filter 'expression'  Filter expression on event fields,
                           event recording depends on evaluation.
                           Userspace only.

usage: lttng enable-event [[NAME[,NAME2,...]] (-k|-u)] [OPTIONS]

NAME can be omitted when using -a, --all.
The userspace tracer supports wildcards at the end of the NAME strings for
tracepoints. Don't forget to quote to deal with bash expansion. e.g.: "*",
"app_component:na*" 

Options:
  -h, --help               Show this help and exit
      --list-options       List the options and exit
  -s, --session NAME       Apply to session NAME
  -k, --kernel             Apply to the kernel tracer
  -u, --userspace          Apply to the user-space tracer
  -c, --channel NAME       Apply to channel NAME
  -a, --all [TYPE]         Enable all events
                           If TYPE is specified, enable all events of the TYPE;
                           TYPE can be tracepoint, syscall, probe, or function

Some features of the current enable-event could be kept in the new enable-event: for instance, an event could have its loglevel or filter settings adjusted (assuming this is possible now or in the future). Note how event definition now accepts a single event name to avoid bug #444.

Actions #1

Updated by David Goulet over 11 years ago

  • Status changed from New to Confirmed

Indeed there can be a confusion here but we can't change the behavior of "enable-event" during the 2.x cycle since it will simply break the API.

However, to keep in mind for the 3.x release cycle because this is relevant to the user experience. An other idea would be to use "object" as the second level of lttng and not "action" such as:

$ lttng event --create ...
$ lttng event --disable ...
$ lttng event --enable

I can't do nothing for sure until we are out of 2.x

Thanks!

Actions #2

Updated by Christian Babeux over 11 years ago

  • Tracker changed from Bug to Feature
Actions #3

Updated by Jérémie Galarneau about 9 years ago

  • Target version set to Wishlist
Actions

Also available in: Atom PDF