Bug #726

consumerd stops receiving events after interrupting relayd and starting a new session

Added by Marc-Andre Laperle over 6 years ago. Updated over 5 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Using lttng-tools 2.4.0-rc3

lttng create --live 1000000 -U net://localhost
lttng enable-event -a -k
lttng start
Ctrl+C on the lttng-relayd terminal
lttng stop
lttng destroy
lttng create
lttng enable-event -a -k
lttng start

Go in the trace folder: the channels are 0 byte.
lttng stop also fails, it waits for data indefinitely.


lttng-relayd-output.txt (272 KB) lttng-relayd-output.txt Marc-Andre Laperle, 04/01/2014 04:49 PM
lttng-sessiond-output.txt (1010 KB) lttng-sessiond-output.txt Marc-Andre Laperle, 04/01/2014 04:49 PM

Updated by David Goulet over 6 years ago

  • Status changed from New to Feedback

With the latest head of stable-2.4 branch of tools you should not be able to reproduce that. If yes, please set the session daemon and relayd in debug mode and provide the output.

current commit: 183f6fa263143a38ec8709047e848477b0be9ecb

lttng-sessiond -vvv --verbose-consumer
lttng-relayd -vvv


Updated by Marc-Andre Laperle about 6 years ago

Hi David. Sorry for the delay, I haven't really played with relayd since then. It's still happening with the final 2.4.0 release. I attached both outputs. Thank you!


Updated by Marc-Andre Laperle over 5 years ago

I can still reproduce this with lttng-tools 2.5.1.


Updated by Christian Babeux over 5 years ago

  • Assignee set to Julien Desfossez

Updated by Julien Desfossez over 5 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 0 to 100

Applied in changeset tools|commit:a2361a610dc8201cc8e165a70682b2f6dc3e0aee.


Updated by Jérémie Galarneau over 5 years ago

  • % Done changed from 100 to 0

Hi Marc-Andre,

I have merged a fix which should address the problem as:

commit a2361a610dc8201cc8e165a70682b2f6dc3e0aee
Author: Julien Desfossez <>
Date:   Wed Nov 12 18:36:17 2014 -0500

    Fix: create/destroy a splice_pipe per stream

    We had a per-thread splice_pipe (one for data and one for metadata), but
    in case of error, we would end up filling the write side of the pipe and
    never emptying it. This could lead to leaking data from one session to
    the other, but also to stall the consumer trying to splice into a full

    Now we create a splice_pipe per-stream, so it is destroyed when the
    session is destroyed.

    Fixes: #726

    Signed-off-by: Julien Desfossez <>
    Signed-off-by: Jérémie Galarneau <>

Would you mind testing and confirming whether or not it fixes the problem?


Also available in: Atom PDF