LTTng » LTTng-tools

I have also already seen this behavior sometimes when playing with instable viewers, but I can't find a reliable way to reproduce it.
I tried killing babeltrace at various stages of the process but still no luck.

Do you have a reliable way to reproduce the problem that I could try ?

In the mean time, I'm investigating the various teardown paths.

Julien Desfossez wrote:

I have also already seen this behavior sometimes when playing with instable viewers, but I can't find a reliable way to reproduce it.
I tried killing babeltrace at various stages of the process but still no luck.

I'm not sure you could reproduce this with babeltrace since it doesn't stay connected to relayd when the lttng session is destroyed.

Do you have a reliable way to reproduce the problem that I could try ?

Maybe I can try to modify live_test.c to demonstrate the problem. Of if you have the Eclipse setup, I can update my code a bit to make it shareable.

If you know at least at which stage the viewer is (getting indexes, metadata, streams, data, etc), that would help.

I'm not sure which state that would be... I guess "listing sessions"? Sorry, that I'm not very clear. It's the same viewer session all along. The first lttng session that was destroyed is still listed on a subsequent LTTNG_VIEWER_LIST_SESSIONS.

So basically:
1. create a live session (lttng create --live, etc)
2. Connect to relayd with a viewer, list the sessions, attach to the session...
3. Destroy the lttng session
4. Without the viewer disconnecting (so using the same viewer session), list the sessions again: the destroyed session is still listed, that would help.

Because from what I see in the log, the viewer is still there: no error or disconnect. Are you sure this log contains the problem ?

Yes the viewer should still be there, it's the same viewer session all along. The problem is that it's listing the destroyed lttng session again. I don't think there's much to see in the log about that unfortunately :(

Thanks Julien, that sounds great. I hadn't planned to work on live in the next few days but I'll try to squeeze this in and get back to you quickly.

Julien Desfossez wrote:

Attached to this message is a patch to implement a detach command and a quick test. The viewer can call it when it is attached to a session and it will release it from the relayd.
Can you test it and tell me if that would be an appropriate solution for your use-case ?

Hi Julien. I just tried the patch. This is very helpful! I can successfuly detach and attach again using the same view session, etc. So from my perspective, it is a good solution. Thanks again!

http://lists.lttng.org/pipermail/lttng-dev/2015-June/024577.html

Will you be submitting a v2?

Oups, I had completely forgotten about this one.
Is it too late for this cycle (since we are in RC) ?
If it's not, I can submit the v2 this week.

Julien

It's not too late!

I just want to let you know that it would still be a nice feature ;)

There were a lot of fixes to the relayd during the 2.7 RC cycle so we'll have to rework the patches for 2.8.

I can confirm that this works in LTTng Tools 2.8. With a viewer attached to a session, I can issue a VIEWER_DETACH_SESSION command, then VIEWER_LIST_SESSIONS does not contain the old session anymore. Thanks for this!