Bug #847
closed
Enabling system calls returns code 35 instead of 0
Added by Francis Giraldeau about 10 years ago.
Updated about 9 years ago.
Description
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
Files
|
bug.sh (142 Bytes)
bug.sh |
script to trigger the bug |
Francis Giraldeau, 10/22/2014 03:50 PM
|
|
|
bug.sh (152 Bytes)
bug.sh |
|
Francis Giraldeau, 10/22/2014 04:09 PM
|
|
Related issues
1 (1 open — 0 closed)
Here is an updated version of the script to destroy the trace using a trap (to make the script indepotent).
- 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".
Thanks,
Mathieu
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.
- Assignee changed from David Goulet to Jérémie Galarneau
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.
- Status changed from Feedback to In Progress
- Target version changed from 2.5 to 2.7
- Assignee changed from Jérémie Galarneau to Michael Jeanson
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.
- Status changed from In Progress to Resolved
Marking as resolved, although I agree the semantics of the shell error codes have to be simplified/reworked. I have opened bug #932 to track progress on this front.
- Related to Feature #932: LTTng client error code semantics are ill-defined added
Also available in: Atom
PDF