Enabling system calls returns code 35 instead of 0
In previous lttng-tools, enabling system calls would return the code 0, and in version 2.5.0 it returns 35. It means that in a script with "#!/bin/sh -e", this command terminates the script. However, there is no errors, system calls are correctly enabled, and if we proceed to start the trace, it works correctly. Therefore, the command should return 0 instead.
$ lttng create Session auto-20141022-154556 created. Traces will be written in /home/francis/lttng-traces/auto-20141022-154556 $ lttng enable-event -a -k All Kernel events are enabled in channel channel0 $ lttng enable-event -k --syscall -a Warning: Kernel events already enabled (channel channel0, session auto-20141022-154556) $ echo $? 35
Updated by Mathieu Desnoyers almost 8 years ago
- Status changed from New to Feedback
In the use-case you describe, you first enable all tracepoints and system calls (-a -k), and then try to enable all system calls.
As the first command already enabled all system calls, the second command tells you that they are already enabled, which returns an error code.
This behavior is expected.
Try your use-case without "enable-event -a -k", it should not return any error when you then enable "-k --syscall -a".
Updated by Francis Giraldeau almost 8 years ago
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.
Updated by Jérémie Galarneau over 7 years ago
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...
Updated by Francis Giraldeau over 7 years ago
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.
Updated by Michael Jeanson almost 7 years ago
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.