[lttng-dev] LTTng streams not Hung up even session is destroyed

Jonathan Rajotte-Julien jonathan.rajotte-julien at efficios.com
Wed Aug 1 13:13:07 EDT 2018

Hi Sai,

On Wed, Aug 01, 2018 at 10:05:30PM +0530, sai kiran wrote:
> Hi,
>  I'm using LTTng 2.9.4  version of lttng-tools, lttng-modules, and
> lttng-ust. I'm doing tracing in Xilinx Zynq ZC706 evaluation kit.
> the sequence of commands used for tracing:
> Mode:
> live mode.

What is the reason behind using the live feature here since you are running
things locally (lttng-relayd/--set-url

Are you doing live analysis or performing analysis after the

In other word, what are you trying to achieve with tracing?

I just want to make sure that you are using the most appropriate way of tracing
to achieve your goal.

> For relay daemon:
> lttng-relayd -L tcp://
> Session commds:
> 1) lttng create my-session --live --set-url=net://
> 2) lttng enable-channel --kernel --subbuf-size=131072 --num-subbuf=8
> channel0
> 3) lttng enable-channel -u --read-timer=2000000 channel0

Are you sure you want to use the read-timer option?

Using 2000000 as its value mean that userspace subbuffers status will only be checked
upon each 2 seconds.

> 4) lttng enable-event --kernel
> sched_process_fork,sched_process_exit,irq_handler_entry,irq_handler_exit,sched_switch,sched_waking
> -c channel0 --session=my-session
> 5) lttng enable-event -u kernelprofiler:kernelprofiler_task_drop -c
> channel0 --session=mysession
> 6) lttng start
> 7) lttng stop
> 8) lttng destroy
> Here my application has a tracepoint of
> "kernelprofiler:kernelprofiler_task_drop"
> event.

> > Hi,
> >
> > After LTTng session is destroyed, no stream is “*Hung up*”. Continuously

What do you mean by "Hung up"? Are you using babeltrace and connecting to the
lttng-relayd daemon on localhost?

What is your expectation?

Do you mean that you are still receiving data on babeltrace side even when
performing a lttng stop/destroy command?

> > I’m getting data from “*relay daemon*”. I’ve killed consumer daemon, even
> > though tracing data coming from relay daemon.

This can happen if babeltrace is "catching-up" on the data, keep in mind that
lttng-relayd have the trace data and can continue to send information to a
babeltrace client even if the consumerd/sessiond is killed or the session

> > Please help me. One more
> > thing application is running infinitely.

Which application? Your application? Babeltrace? lttng-sessiond?

If you are talking about your application, could you provide a backtrace
indicating that ust is the culprit here?


Jonathan Rajotte-Julien

More information about the lttng-dev mailing list