Bug #726
closed
consumerd stops receiving events after interrupting relayd and starting a new session
Added by Marc-Andre Laperle about 10 years ago.
Updated over 9 years ago.
Assignee:
Julien Desfossez
Description
Using lttng-tools 2.4.0-rc3
lttng-relayd
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.
Files
- 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
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!
I can still reproduce this with lttng-tools 2.5.1.
- Assignee set to Julien Desfossez
- Status changed from Feedback to Resolved
- % Done changed from 0 to 100
Applied in changeset tools|commit:a2361a610dc8201cc8e165a70682b2f6dc3e0aee.
- % 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 <jdesfossez@efficios.com>
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
pipe.
Now we create a splice_pipe per-stream, so it is destroyed when the
session is destroyed.
Fixes: #726
Signed-off-by: Julien Desfossez <jdesfossez@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Would you mind testing and confirming whether or not it fixes the problem?
Thanks!
Also available in: Atom
PDF