From mboxrd@z Thu Jan 1 00:00:00 1970 From: jonathan.rajotte-julien@efficios.com (Jonathan Rajotte-Julien) Date: Wed, 1 Aug 2018 18:28:12 -0400 Subject: [lttng-dev] LTTng streams not Hung up even session is destroyed In-Reply-To: References: <1098573093.6842.1532966434523.JavaMail.zimbra@efficios.com> <2025170812.6867.1532966515434.JavaMail.zimbra@efficios.com> <20180801171307.GA23912@joraj-alpa> Message-ID: <20180801222812.GA18033@joraj-alpa> Hi Sai, You did not answer the other questions I asked. Those answers are necessary for us to understand what is going on. On Wed, Aug 01, 2018 at 11:11:39PM +0530, sai kiran wrote: > Hi, > The reason for reader timer option is, UST event throughput is very low so > if I don't use this option I'm not at all getting UST trace data. Even > though the difference between "reader-timer" and "switch-timer" is not > clear for me. Correct me if I wrong, Please read the doc/man page for more information regarding those timer [1]. [1] https://lttng.org/man/1/lttng-enable-channel/v2.10/#doc-_switch_timer "When a channel’s switch timer fires, a sub-buffer switch happens. This timer may be used to ensure that event data is consumed and committed to trace files periodically in case of a low event throughput." This seems to fit your use case. You might be better off using the switch timer. Cheers > > "Switch-Timer": After switch timer expires, Consumer daemon will take the > current sub-buffer data and new trace data will be written to next > sub-buffer (if available). So switch between sub-buffer will happen. > "Reader-Timer": After Reader-Timer expires, Consumer daemon will check > sub-buffer is full or not. If Full then consumer daemon will take the data > or else consumer daemon won't take trace data. > > I'm using my own application. > > Thanks, > T SAI KIRAN. > > On Wed, Aug 1, 2018 at 10:43 PM, Jonathan Rajotte-Julien < > jonathan.rajotte-julien at efficios.com> wrote: > > > 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 > > -- Jonathan Rajotte-Julien EfficiOS