LTTng » LTTng-tools

$ sudo -H lttng create session2
Session session2 created.
Traces will be written in /root/lttng-traces/session2-20130219-163611
$ sudo -H lttng enable-event sched_switch -k
kernel event sched_switch created in channel channel0
$ sudo -H lttng enable-consumer -D=tcp://131.132.32.77:5343
Data URL tcp://131.132.32.77:5343 set for kernel session session2.
Data URL tcp://131.132.32.77:5343 set for UST session session2.
$ sudo -H lttng enable-consumer -C=tcp://131.132.32.66:5342
Control URL tcp://131.132.32.66:5342 set for kernel session session2.
Control URL tcp://131.132.32.66:5342 set for UST session session2.
$ sudo -H lttng enable-consumer
Consumer enabled successfully
Consumer enabled successfully
$ sudo -H lttng start
Tracing started for session session2
$ sudo -H lttng stop
Waiting for data availability
Tracing stopped for session session2
$ sudo -H lttng list session2
Tracing session session2: [inactive]
    Trace path: net://131.132.32.66:5342/ [data: 5343]

=== Domain: Kernel ===

Error: No kernel consumer detected
$ sudo -H lttng destroy
Session session2 destroyed
$ 
$ 
$ sudo -H lttng create session3
Session session3 created.
Traces will be written in /root/lttng-traces/session3-20130219-164136
$ sudo -H lttng enable-event sched_switch -k
Error: Event sched_switch: No kernel consumer detected (channel channel0, session session3)
Warning: Some command(s) went wrong

The trace files were created on 131.132.32.66, but they were empty. The two lttng-consumerd daemons seem no longer responsive, hence the failure to create session3. The tracing machine has to be rebooted.

A similar set of commands, but this time using the same IP for -C and -D, works just fine. The sequence -C -D fails just like -D -C:

$ sudo -H lttng create session4
Session session4 created.
Traces will be written in /root/lttng-traces/session4-20130219-170423
$ sudo -H lttng enable-event -k sched_switch
kernel event sched_switch created in channel channel0
$ sudo -H lttng enable-consumer -C tcp://131.132.32.66:5342
Control URL tcp://131.132.32.66:5342 set for kernel session session4.
Control URL tcp://131.132.32.66:5342 set for UST session session4.
$ sudo -H lttng enable-consumer -D tcp://131.132.32.77:5343
Data URL tcp://131.132.32.77:5343 set for kernel session session4.
Data URL tcp://131.132.32.77:5343 set for UST session session4.
$ sudo -H lttng enable-consumer
Consumer enabled successfully
Consumer enabled successfully
$ sudo -H lttng list session4
Tracing session session4: [inactive]
    Trace path: net://131.132.32.66:5342/ [data: 5343]

=== Domain: Kernel ===

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

    Attributes:
      overwrite mode: 0
      subbufers size: 262144
      number of subbufers: 4
      switch timer interval: 0
      read timer interval: 200
      output: splice()

    Events:
      sched_switch (loglevel: TRACE_EMERG (0)) (type: tracepoint) [enabled]

=== Domain: UST global ===

Error: UST channel not found
$ sudo -H lttng start
Tracing started for session session4
$ sudo -H lttng list session4
Tracing session session4: [active]
    Trace path: net://131.132.32.66:5342/ [data: 5343]

=== Domain: Kernel ===

Error: No kernel consumer detected

You get the same result if you collapse the enable-consumer lines into one:

$ sudo -H lttng enable-consumer -C tcp://131.132.32.66:5342 -D tcp://131.132.32.77:5343 -e

The "Error: UST channel not found" is a distinct problem, which I may report separately (probably due to the fact that the command was sudoed and the userspace daemon is running as root).

Both target IPs have running lttng-relayd daemons, so I suspect the consumer daemon is simply waiting on an acknowledgement of its data from a relayd which is not getting a control stream (or something like that).

The problem is that although enable-consumer.c correctly has a net: -C override -D, it doesn't do the same with tcp:. What would be the point of control and data streams going to different IPs?