Hi Georg,

On 6/25/25 9:36 AM, Georg Muck wrote:
Hi Kienan,

I did exactly that, without success.

The log of the lttng-sessiond (lttng.log) did not change after starting the
ROS2 instances. I have also added the output of "lttng list
structuralSession"
I start my tracing instance as follows:

At first there is a bash-script that sets everything up, it does the
following:

lttng destroy -a # to destroy all existing sessions
lttng-sessiond --daemonize --verbose-consumer -vvv &> "/tmp/lttng.log" #

When started with '--daemonize', the file descriptors are closed[1] after forking which is why you don't see any further output to /tmp/lttng.log. Try with '--background' instead.

starting a new session Deamon
./exemplary_tracing_session # starting my exemplary tracing session

The exemplary tracing session is written by the help of the c Api
(appendix).


I modified your script to add 'tp:tptest' (a tracepoint from the lttng-tools test suite program gen-ust-events) and did the following:

```
$ lttng-sessiond --background --verbose-consumer -vvv &> sessiond.log
$ ./exemplary_tracing_session &
$ lttng-tools/./tests/utils/testapp/gen-ust-events/gen-ust-events
babeltrace2 /tmp/structural_traces | wc -l
100
```

It seems to be working fine for me. A couple of notes:

1. Before any traced application is run, babeltrace2 has the following error output: No trace was found based on input `/tmp/structural_traces` 2. After a traced application is run whether is produces enabled events or not, I see the events recorded.
3. When your session script stops, the output folder is deleted.

I started the the same procedure on another machine. The same fault

The fault is that the babeltrace2 has an error, right? Are you willing to share your trace that has the problem and/or show the output of babeltrace2's error?

occurred. I think I need to configure more within the `lttngDomain`. But I
don't know how, would you have an idea/hint?

Thanks for your help.

Best regards,
Georg

Ps.: I also added the log of my tracing tool (structural.log)

Never burn the bridges before you
If you've burned the bridges behind
Never burn the one that you're walking upon
Or you're sure to hit the water in time. *(Savatage, Streets, 1991)*


Am Mo., 23. Juni 2025 um 16:26 Uhr schrieb Kienan Stewart <
kstew...@efficios.com>:

Hi Georg,

a good first step is to run lttng-session with `-vvv --verbose-consumer`
and inspect the log file and `LTTNG_UST_DEBUG=1` in the environment.

It may also be useful to run your traced applications with
`LTTNG_UST_DEBUG=1` set in the environment.

Do you have steps that reproduce the issue? E.g., all the commands to
set up the tracing session and so forth.

thanks,
kienan

On 6/19/25 10:58 AM, Georg Muck via lttng-dev wrote:
Hey,

I am using the LTTng tracer (2.13.11, C-API, rotation=1s) to trace my
ROS2
system (userspace only). Everything works just fine within my Docker
Container (Ubuntu 24.04), but if I start the same procedure on the host
itself (also Ubuntu 24.04), it does not create a TraceFile if to many
tracepoints occur (speaking of roundabout 1500+ per second) (sometimes it
malformed the tracefile, but I was not able to recreate that. If I
remember
correctly, Babeltrace2 threw an error that said that there was no
metadata-file). I played around with some configurations (like increasing
the buffer size from ~16kB to ~512kB or a less aggressive rotation), but
the problem stayed.

Would be thankful for help. I guess I delivered to less information,
please
reach out what is interesting at this point, I am not sure about that :).

Best regards,
Georg



Never burn the bridges before you
If you've burned the bridges behind
Never burn the one that you're walking upon
Or you're sure to hit the water in time. *(Savatage, Streets, 1991)*





thanks,
kienan

[1]: https://lttng.org/man/8/lttng-sessiond/v2.13/#doc-opt--daemonize

Reply via email to