lttng / lttng-docs Goto Github PK

The "Trace the Linux Kernel" section needs to specify sudo for the commands

lttng list --kernel
lttng list --kernel --syscall

(Lines 644-645 in the doc source at the moment)

hello-tp.o:(__tracepoints+0x18): undefined reference to `__tracepoint_provider_hello_world'
collect2: error: ld returned 1 exit status

I just follow the doc to produce a userspace program, hello.c. But this error arise when I try to build it.
Is there any wrong with the example?

The python logging example do not work in python2.7.

https://lttng.org/docs/#doc-python-application

One way to make it work is to use:

logging.basicConfig()

Not sure if it's the solution ...

Cheers!

It was brought to my attention that the following might confuse certain user as to if multiple channels with their own set of buffers can be created on a system for the kernel domain.

The Linux kernel tracing domain has only one available buffering scheme which is
to allocate a single set of ring buffers for the whole system. This scheme is similar
to the per-user option, but with a single, global user “running” the kernel.

Seems like the following might be the confusing part a single set of ring buffers for the whole system.

Users could be tempted to conclude that a single kernel domain can be created.

I do not have a change proposition to be honest. Might be a good idea to put an emphasis such as "for a given channel".

In Add an LTTng layer to an existing ftrace tracepoint, change probes/Makefile to probes/KBuild.

Reported by @aleixrocks.

This section has a few issues: https://lttng.org/docs/v2.13/#doc-persistent-memory-file-systems

First, it states that LTTng supports NVRAM, which is inaccurate. First, a bit of context:

The integration of LTTng-UST with DAX/PMEM has never targeted PMEM based on NVRAM, but rather uses a less known capability of PMEM which is to map an area of Volatile memory (RAM). So as long as the user can guarantee that this area of memory is not cleared on warm-reboot (either through BIOS guarantee, or by using kexec() to boot into another kernel from a watchdog), we get access to the DAX filesystem content after reboot.

Saying that this feature targets NVRAM misleads end users, because they would believe that they need niche NVRAM hardware such as Intel Optane (now discontinued) to use the feature when in fact they can use it on pretty much any commodity hardware over normal RAM.

We should also document how to configure pmem/dax in that section, so people can specifically see how we configure things so it works over normal RAM. Pointing to the pmem/dax documentation does not do us service here because that documentation is mainly targeting NVRAM use-cases, which is not ours.

If we ever intend to improve LTTng to make it really support NVRAM, then we would need integration with things like libpmem (https://pmem.io/pmdk/libpmem/) and add pmem_persist() calls after recording each event. This issues additional instructions on the CPU which guarantee that the content of the cache has been flushed to NVRAM, thus making sure the trace data would be available after pulling the power from the computer. This is NOT something we currently guarantee, and it would not be entirely free performance-wise, so I would not invest effort in this unless we have real-life end users showing interest for this.

Some features are reserved to specific tracing domains. Dynamic function
entry and return instrumentation points, for example, are currently only
supported in the Linux kernel tracing domain, but support for other
tracing domains could be added in the future.

This block should be updated since a new feature in 2.11 is "You can now dynamically instrument any application’s or library’s function entry by symbol name".

Installation instructions from ppa/source for python and java agent are not included and confuse users.

LTTng supports userspace SDT probes, but:

• only SDT probes that are not guarded by semaphores (although one can work around this/disable the semaphores)
• does not support probe parameters

While these limitations are mentioned in this blog post, they are not mentioned in the docs and could cause some suprises.

I think it would be good to mention these limitations. If you agree, where in the docs would be the best place for it? Maybe under "Create and enable an event rule"?

Apologies for the spam, but couldn't find another way to ask (email/social networks/etc).

What software is used to create the figures in the LTTng docs? They look great!

Thanks!

http://lttng.org/docs/v2.10/#doc-ubuntu-ppa

The section should include the instrcution for installing the python 2.7 agent.

Which is liblttng-ust-python-agent0 for stable 2.9 and 2.10 ppa.

Cheers

Greetings,

I was accessing https://lttng.org/docs/, which appears to be an alias for the current latest version of the docs (currently https://lttng.org/docs/v2.12/), but I realized that the images won't load when accessing the docs from that URL, while they work just fine in the fully expanded URL. It looks like it's trying to resolve images under /docs/images/, when in fact they're only found under /docs/v2.12/images/.

It might be worth noting that https://docs.lttng.org/ redirects to https://lttng.org/docs/ as well. I had the first URL in my bookmarks, which redirected to the second, neither of which seem to appear on the site itself (the navbar links to the URL with the version in it, for instance).

I ran into this problem when I tried the tutorial.
the comment is :
lttng list --kernel
then wil get :
Error: Unable to list kernel events: Kernel tracer not available
My linux kernel is :
Ubuntu 18.04 Bionic Beaver
What' wrong with that? Can you help me? Thank you very much!

In handle_evaluation()

we have: assert(event_field_value_status == LTTNG_EVENT_FIELD_VALUE_STATUS_OK);

with recent changes in lttng-modules, when a page fault occurs, the resulting field is a event_field_value_status == LTTNG_EVENT_FIELD_VALUE_STATUS_UNAVAILABLE. If would be good if the example handles this case by skipping the capture rather than asserting.

The -x or --exclude lttng command line flag is not present in the doc, but it is found in the manpage:

-x, --exclude LIST

Add exclusions to UST tracepoints: Events that match any of the
items in the comma separated LIST are not enabled, even if they
match a wildcard definition of the event.

This option is also applicable with the -a, --all option, in which
case all UST tracepoints are enabled except the ones whose names
match any of the items in LIST.