From: jonathan.rajotte-julien@efficios.com (Jonathan Rajotte-Julien)
Subject: [lttng-dev] LTTng streams not Hung up even session is destroyed
Date: Wed, 1 Aug 2018 13:13:07 -0400 [thread overview]
Message-ID: <20180801171307.GA23912@joraj-alpa> (raw)
In-Reply-To: <CAPB=nBs84oqYvPECThCoheHQZr6QGONBhSR1o61iB1bS7vbXdg@mail.gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2565 bytes --]
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 127.0.0.1)?
Are you doing live analysis or performing analysis after the
fact?
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://127.0.0.1:5344--output=/tmp/lttnglogs/
> Session commds:
> 1) lttng create my-session --live --set-url=net://127.0.0.1
> 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
stopped/destroyed.
> > 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?
Cheers
--
Jonathan Rajotte-Julien
EfficiOS
next prev parent reply other threads:[~2018-08-01 17:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAPB=nBs16oE95zHyX3xF6F895g1Phe=8AKFmsX185M8rZvyhEw@mail.gmail.com>
[not found] ` <1098573093.6842.1532966434523.JavaMail.zimbra@efficios.com>
[not found] ` <2025170812.6867.1532966515434.JavaMail.zimbra@efficios.com>
2018-08-01 16:35 ` sai kiran
2018-08-01 17:13 ` Jonathan Rajotte-Julien [this message]
2018-08-01 17:41 ` sai kiran
2018-08-01 22:28 ` Jonathan Rajotte-Julien
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180801171307.GA23912@joraj-alpa \
--to=jonathan.rajotte-julien@efficios.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox