LTTng » LTTng-tools

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'.