Bug #993

Re-enabling disabled events create new tracepoint events

Added by Bernd Hufmann about 5 years ago. Updated about 5 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


LTTng version 2.7:

I'm executing the following commands:

lttng create mysession
lttng enable-event myevent -k --probe hrtimer_init
lttng disable-event myevent
lttng enable-event myevent -k

When listing the session it shows 2 events with name "myevent" and the probe event is still disabled. I think the probe event "myevent" should be enabled and the tracepoint event "myevent" shouldn't be created.

Here is relevant part of the output of the list command:
myevent (loglevel: TRACE_EMERG (0)) (type: tracepoint) [enabled]
myevent (type: probe) [disabled]
offset: 0x0
symbol: hrtimer_init

Note 1: LTTng 2.6, it worked (probe event is enabled and no tracepoint event is created)
Note 2: The same behaviour exists when using UST and loglevel/loglevel-only events (LTTng 2.6 and 2.7)


Updated by Jonathan Rajotte Julien about 5 years ago

  • Status changed from New to Feedback


An event is not defined simply by it's name but by a tuple of descriptor mostly name, type, etc. Since 2.7 on the enable side we respect this tuple before it was simply name based.
The event myevent of type probe is not the same as myevent of type tracepoint.

There is current limitations on the disable side regarding the tuple passed to the sessiond. Only the name and the event-type (for kernel) is considered for now. We default on disabling all types if no type argument is passed simply based on the event name.

From the disable-event help page:
For kernel events there is multiple type available:
--all All event types (default)
--tracepoint Tracepoint event
--syscall System call event
--probe Probe event
--function Function event

We are fully aware of the symmetry problem of the enable/disable command and are slowly working on fixing it.


Also available in: Atom PDF