[lttng-dev] lttng-ust works

[Thibault, Daniel]

> I tried different possibility to generate the userspace trace and kernel trace and observed that I'm not able to generate the user space tracing If the lttng-sessiond is started

> using root user.

>

> I'm using busybox in my custom Linux platform and no sudo support. It's a 64 bit machine.

> Trail 2:

> ========

>

> 1. Start the lttng-session from root user

> 2. Run the following command from "tracing" group user

>

> lttng@/ # lttng -g lttng create ks

> Session ks created.

> Traces will be written in /home/lttng/lttng-traces/ks-20131224-123537

> lttng@/ # lttng -g lttng enable-event -k -a

> All kernel events are enabled in channel channel0

> lttng@/ # lttng -g lttng start

> Tracing started for session ks

> lttng@/ # lttng -g lttng stop

> Waiting for data availability.

> Tracing stopped for session ks

> [...]

> The kernel traces are generated fine



   I can't follow you on this one since my Ubuntu system doesn't allow su (not easily, anyway).  However, I'll just point out that the lttng group option should not be used since it does not seem to work at all (a problem I reported on the lttng-dev mailing list back on 9 July 2013, and which has remained unanswered so far).



   According to the code, the lttng client checks if it belongs to the 'group_name' (default 'tracing') to decide which socket to ask for; in practice, whether a root lttng-sessiond is running or not, if I'm not a member of 'tracing' it spawns a local lttng-sessiond whatever the specified group_name; conversely, if the root lttng-sessiond is running alone, I get to interrogate it regardless of the specified group_name if I'm a member of its 'tracing' group.  What matters here is which group option value was used to launch lttng-sessiond.  *That* works, forcing the root lttng-sessiond to accept unprivileged lttng client commands as privileged if the client is running in that group.



   Note that if you run a kernel and user-space trace as su, you will get two lttng-consumerd daemons, both running as root: one daemon handles the kernel events, the other the user-space events.  It's easier to tell what is going on with the system monitor if you do not issue your commands from su.  Stay in a normal user shell, and use sudo as required.  (But you have no sudo support, you say...This'll be tricky because I don't have any su support!)



   In the trails you explored, it would have been useful to know which groups your shell is a member of, and how the lttng-sessiond daemon was launched (i.e., which group it treats as the 'tracing' group).



> Trail 2:

> [...]

> lttng@/ # lttng -g lttng create as

> Session as created.

> Traces will be written in /home/lttng/lttng-traces/as-20131224-123811

> lttng@/ # lttng -g lttng enable-event -k -u -a

> All kernel events are enabled in channel channel0

> lttng@/ # lttng -g lttng start

> Tracing started for session as

> lttng@/ # cd /tmp/

> lttng@/tmp # ./sample

> lttng@/tmp # lttng -g lttng stop

> Waiting for data availability.

> Tracing stopped for session as

> lttng@/tmp # lttng -g lttng destroy

> Session as destroyed

> remove config file: Permission denied

> lttng@/tmp # cd /home/lttng/lttng-traces/

> No userspace traces are generated



   The "remove config file: Permission denied" you get is intriguing but a separate problem.  What you did wrong here is to write:



lttng@/ # lttng -g lttng enable-event -k -u -a



   thinking that this would enable both kernel and user-space events.  It does not.  The lttng client handles only one domain at a time.  In this case, the -k option shadowed the -u option, which was ignored.  If you try it again with this:



lttng@/ # lttng -g lttng enable-event -k -a

lttng@/ # lttng -g lttng enable-event -u -a



   This time you should get both kernel and user-space events in the trace.



   As for trail 3, it does not capture any kernel events because it did not ask to capture any.  You only enabled user-space events.



   Hope this helps.



Daniel U. Thibault

Protection des systèmes et contremesures (PSC) | Systems Protection & Countermeasures (SPC)

Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber Security (MCCS)

R & D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence R&D Canada - Valcartier (DRDC Valcartier)

2459 route de la Bravoure

Québec QC  G3J 1X5

CANADA

Vox : (418) 844-4000 x4245

Fax : (418) 844-4538

NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ<--ESFSECEV-TY3011-------------------------------->>

Gouvernement du Canada | Government of Canada

<http://www.valcartier.drdc-rddc.gc.ca/<--ESFSECEV-TY3011--------------------->>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20140106/c0bb9a59/attachment.html>