Bug #639
closedRe-enabling an event is treated inconsistently
0%
Description
In the kernel domain:
Once a kernel event has been created (enabled a first time) and later disabled, some of the enable-event event type options (--tracepoint, --probe, --function, --syscall) are ignored, others not. For instance, using a --probe, we have:
--tracepoint : ignored--probe : complains if an argument is not supplied, otherwise ignored--function : complains if an argument is not supplied, otherwise ignored--syscall : complains that "per-syscall selection [is] not supported yet"
In user-space:
Using a --tracepoint (the only type possible):
--tracepoint : ignored--probe : complains if an argument is not supplied, otherwise complains that the "event type [is] not available" --function : (same as --probe)--syscall : complains that the "event type [is] not available"
Clearly, in both domains the availability of the specified event type should be checked before checking for an event type option argument (this holds for --probe and --function). If the event type is available, then since the kernel does not support multiple events of the same name, unlike user-space, it should complain with an appropriate error message instead of ignoring the option (something like "Error: Multiple events of the same name are not supported").
I'm presuming that, in user-space, once new types become available (such as --probe) it will be possible to have multiple event entries of the same name distinguished by type, since we already have multiple event entries of the same name distinguished by attribute (loglevel, loglevel-only, filter).
Updated by David Goulet over 10 years ago
- Status changed from New to Won't fix
(Hopefully I understand correctly the issue here).
The enable-event command does not query the session daemon to find out if an event is already enabled or not and it SHOULD NOT do that since the validation must be done on the server side (lttng-sessiond). It's not the client job to do that.
The command parses the option(s) and if no error(s) is/are detected, a query is sent to the session daemon and we wait for a response (lttng error code).
Nevertheless, in order to achieve what you are asking, the command would have to list all events from the session/domain, check if the given name matches one that already exists and if so, ignore completely the command line and enable that event... To be honest, I see that as a kind of a burden and an heavy operation just to print a different error for the case that options are given for an event that you want to re-enable... Also, all this will have to be modified/removed the day the kernel can accept multiple events with the same name but different attributes. Checks on the client side are an unnecessary burden in my opinion.
Updated by Daniel U. Thibault over 10 years ago
Good point about the client being stateless. We nevertheless have bugs in the current concept of operations. Consider this example:
$ lttng create test
Session test created.
Traces will be written in /home/daniel/lttng-traces/test-20131105-091609
$ lttng enable-event -k --probe sys_open+0x0 k_sys_open
kernel event k_sys_open created in channel channel0
$ lttng disable-event -k k_sys_openkernel event k_sys_open disabled in channel channel0 for session test
$ lttng enable-event -k --probe sys_close+0x0 k_sys_open
kernel event k_sys_open created in channel channel0
$ lttng list test
Tracing session test: [inactive]
Trace path: /home/daniel/lttng-traces/test-20131105-091609
=== Domain: Kernel ===
Channels:
-------------
- channel0: [enabled]
Attributes:
[...]
Events:
k_sys_open (type: probe) [enabled]
offset: 0x0
symbol: sys_open
Intending to type 'lttng enable-event -k --probe sys_close+0x0 k_sys_close' and define a new k_sys_close event, the user used the command recall feature of the shell to bring up the previous kernel probe definition command issued, but forgot to change the event name (an easy mistake to make). His session is now configured very differently than he's expecting in his mental model.
The client checked the command for applicability (is the event type available on this domain?) and syntactical validity (is the --probe address specified?) before sending it to the session daemon. Fine. The problem is that the session daemon accepted the command without sending an error back to the client.
If it is acceptable from the session daemon's point of view to 'enable_event event_name --domain --type' without specifying the event definition when the event already exists, then that command form should appear syntactically correct to the client (it does not: you'll get an 'Undefined command' error).
If, on the other hand, the session daemon accepts only a fully-formed 'enable-event' command, then when the event already exists it should check the newly-supplied definition against the existing one and complain if they don't match. (I can't help but note that this problem would not arise if event creation and event enabling were split into two separate lttng commands as I've observed before)
So, what we have is this current enable-event behaviour concerning the --type option:
--tracepoint : ignored
--probe, --function : complains if an argument is not supplied, complains that the "event type [is] not available" (if in user-space), otherwise ignored
--syscall : complains that "per-syscall selection [is] not supported yet" (kernel) or that "event type [is] not available" (user-space)
What is missing is the session daemon checking a definition against a previoulsy-issued one, and complaining if there is a mismatch:
- client checks for type availability against the domain (surely this is local to the client?)
- client checks the command for syntactical correctness and completeness
- client sends the command to the session daemon
- if the event did not exist, the session daemon creates it and reports any error or warning
- if the event did already exist, the session daemon checks the definition against the extant one, and complains of any mismatch (also complains if the event was already enabled)
Finally, you state "all this will have to be modified/removed the day the kernel can accept multiple events with the same name but different attributes". If that day comes, the session daemon will still need to recover the previously-defined events of that name in order to know whether to re-enable an extant one or create a new one. There would be change in only one branch of the 'if'.