Project

General

Profile

Actions

Bug #847

closed

Enabling system calls returns code 35 instead of 0

Added by Francis Giraldeau almost 8 years ago. Updated almost 7 years ago.

Status:
Resolved
Priority:
Normal
Target version:
Start date:
10/22/2014
Due date:
% Done:

0%

Estimated time:

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 open0 closed)

Related to LTTng-tools - Feature #932: LTTng client error code semantics are ill-definedConfirmedJérémie Galarneau09/05/2015

Actions
Actions #1

Updated by Francis Giraldeau almost 8 years ago

Here is an updated version of the script to destroy the trace using a trap (to make the script indepotent).

Actions #2

Updated by Francis Giraldeau almost 8 years ago

indepotent -> idempotent

Actions #3

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

Thanks,

Mathieu

Actions #4

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.

Actions #5

Updated by Christian Babeux almost 8 years ago

  • Assignee changed from David Goulet to Jérémie Galarneau
Actions #6

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

Thoughts?

Actions #7

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.

Actions #8

Updated by Jérémie Galarneau almost 7 years ago

  • Status changed from Feedback to In Progress
  • Target version changed from 2.5 to 2.7
Actions #9

Updated by Jérémie Galarneau almost 7 years ago

  • Assignee changed from Jérémie Galarneau to Michael Jeanson
Actions #10

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.

Actions #11

Updated by Jérémie Galarneau almost 7 years ago

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

Actions #12

Updated by Jérémie Galarneau almost 7 years ago

  • Related to Feature #932: LTTng client error code semantics are ill-defined added
Actions

Also available in: Atom PDF