LTTng » LTTng-tools

indepotent -> idempotent

Thanks for the update. However, this bug also occurs when enabling only system calls:

$ lttng destroy -a
$ lttng create
$ lttng enable-event -k --syscall -a
Warning: Kernel events already enabled (channel channel0, session auto-20141029-103047)
$ echo $?
35

Enabling only syscalls should return 0 instead of 35. As a workarround, I disabled the trap arround that command in my scripts.

I'm not sure whether it should return an error or not. Technically, it did not succeed in enabling the syscalls since all events were already enabled.

To me, this seems not unlike calling mkdir on a directory which already exists; the user-visible end result is the same as that directory can now be assumed to exist. However, the tool reports an error as it could not perform the user's command...

Thoughts?

The following single command returns 35 and should not:

$ lttng enable-event -k --syscall -a

This command does not enable all events, but instead enables all syscalls. Enabling all syscalls and only them should return 0 and not the error 35.

I can't reproduce this behavior with the current stable-2.7 branch, running the single command with a clean session succeeds :

$ lttng destroy -a
Session toto destroyed
$ lttng create toto
Session toto created.
Traces will be written in /home/mjeanson/lttng-traces/toto-20150902-101526
$ lttng enable-event -k --syscall -a
All Kernel system calls are enabled in channel channel0
$ echo $?
0
$ lttng list toto
Tracing session toto: [inactive]
    Trace path: /home/mjeanson/lttng-traces/toto-20150902-101526

=== Domain: Kernel ===

Channels:
-------------
- channel0: [enabled]

    Attributes:
      overwrite mode: 0
      subbufers size: 262144
      number of subbufers: 4
      switch timer interval: 0
      read timer interval: 200000
      trace file count: 0
      trace file size (bytes): 0
      output: splice()

    Events:
      * (type:syscall) [enabled]

However, running the command twice will fail the second time with a warning and an exit code of "4" which translate to "CMD_WARNING". This behavior is common to multiple other lttng commands and doesn't make a lot of sense in a shell where there is no concept of a warning error code.