Project

General

Profile

Actions
Copy link

Bug #644

closed

Error messages are issued when enabling all events in a new channel

Added by Daniel U. Thibault over 11 years ago. Updated almost 11 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Target version:
LTTng - 2.3
Start date:
09/25/2013
Due date:
% Done:

0%

Estimated time:

Description

The lttng enable-event --all -k command assigns the as-yet-unassigned kernel tracepoints and syscalls. This is a quiet process within any given channel. For example, if you enable a handful of sched_* tracepoints to a channel, and then issue lttng enable-event --all -k for that same channel, it will receive the syscalls and all the remaining kernel events, with no error messages.

However, if you switch channels:

# lttng enable-events -k --tracepoint --all -c channel_one
# lttng enable-events -k --all -c channel_two

You will get a long series of identical errors, one for each current kernel tracepoint. The session correctly ends up enabling just the syscalls in channel_two, so the error messages are not pertinent.

PERROR [19839/19940]: create event ioctl: Invalid argument (in kernel_create_event() at kernel.c:205)

The converse also occurs:

# lttng enable-events -k --syscall --all -c channel_one
# lttng enable-events -k --all -c channel_two

You will get one escaping error message (the same one), when lttng tries to assign the syscalls to the other channel. Also happens if the second command adds --syscall, which is expected. The error message could be improved, though ("The syscall events are already assigned to another channel" instead of "Enable kernel event failed (channel x, session y)").

# lttng enable-events -k sched_switch -c channel_one
# lttng enable-events -k --all -c channel_two

You will get one escaping error message (the same one), when lttng tries to assign sched_switch to the other channel. Also happens if the second command adds --tracepoint.

Using LTTng 2.3.0.

Actions
Copy link
 #1

Updated by Daniel U. Thibault about 11 years ago

The following is most likely just another symptom of the same underlying problem, so I won't open a distinct bug report.

If, in a given channel, you enable syscalls and then enable all kernel tracepoints, you get no error or warning messages. But if you enable the tracepoints first, then the syscalls, you get a warning even though everything is OK:

$ lttng create syscalls_then_tracepoints
Session syscalls_then_tracepoints created.
Traces will be written in /home/daniel/lttng-traces/syscalls_then_tracepoints-20131028-151011
$ lttng enable-event -k -a --syscall
All kernel system calls are enabled in channel channel0
$ lttng enable-event -k -a
All kernel events are enabled in channel channel0

$ lttng create tracepoints_then_syscalls
Session tracepoints_then_syscalls created.
Traces will be written in /home/daniel/lttng-traces/tracepoints_then_syscalls-20131028-151937
$ lttng enable-event -k -a
All kernel events are enabled in channel channel0
$ lttng enable-event -k -a --syscall
Warning: Kernel events already enabled (channel channel0, session tracepoints_then_syscalls)
Actions
Copy link
 #2

Updated by David Goulet about 11 years ago

  • Status changed from New to Confirmed
Actions
Copy link
 #3

Updated by David Goulet almost 11 years ago

  • Status changed from Confirmed to Feedback

This is a recurrent issue we've been having with already existing event where the lttng modules returns EINVAL but should return EEXIST instead. If I remember correctly, there is unfortunately no way to have the kernel return EEXIST in the current implementation.

Mathieu can you confirm that? If yes, we'll have to live with that annoying UI/UX issue. :S

Actions
Copy link
 #4

Updated by David Goulet almost 11 years ago

  • Status changed from Feedback to Resolved

Since January 15th, fixed in lttng-modules

Actions
Copy link

Also available in: Atom PDF