Re: [lttng-dev] [EXTERNAL] Re: Problem with application changing UID
Thanks for the tips. The stopping/starting issue (resulting in no more events) still exists with a live session, but it is related to Trace Compass reading the logs, not LTTng writing them. The logs are still written to and Babeltrace can view them fine, but Trace Compass cannot view past the point where the session was stopped. Thus, this is now outside the realm of this mailing list. Best, Zach -Original Message- From: Mathieu Desnoyers Sent: Monday, September 30, 2019 9:56 PM To: Kramer, Zach Cc: Jonathan Rajotte ; lttng-dev Subject: Re: [lttng-dev] [EXTERNAL] Re: Problem with application changing UID - On Sep 27, 2019, at 10:07 AM, Kramer, Zach zach.kra...@cognex.com wrote: > Hi, > > Following up on this. > > Unfortunately I was not able to test the patch because our build > system relies on using the lttng version provided by poky -- updating > is not something we can easily do. > > I seemingly solved this problem in another manner, though. I built the > tracepoint provider package into a shared object and dlopen() it after > the root privileges have been dropped. This seems to have solved the > UID problem, because the app only registers itself under the UID that it will > trace under. > > This resulted in another problem, which is that the metadata does not > exist until the session is stopped, This is expected. > and once the session is started again it is no longer tracing. Well that means your solution does not completely work. > In the lttng documentation I found: > > "Important: You need to stop tracing to make LTTng flush the remaining > trace data and make the trace readable." > > I interpreted this as "the metadata will not exist until the session > is stopped." Is this correct? > > Regardless, I enabled the channel 'metadata' and configured it to > flush via the switch timer, which then gives my traces metadata. > > My problem thus is seemingly solved. Do you see any flaws on the lttng > side of this approach? If you want to consume your traces without stopping tracing, you need to use the lttng "live" mode or the new "session rotation" feature introduced in lttng 2.11. Without those features, reading a trace while it's being produced is racy and may yield to corrupted traces. Thanks, Mathieu > > Best, > Zach > > -Original Message- > From: lttng-dev On Behalf Of > Kramer, Zach > Sent: Tuesday, September 24, 2019 6:01 PM > To: Jonathan Rajotte-Julien > Cc: lttng-dev@lists.lttng.org > Subject: Re: [lttng-dev] [EXTERNAL] Re: Problem with application > changing UID > > Hi, > > Thanks for the quick response! This looks interesting -- I will > experiment with it and come back with any results. > > Cheers, > Zach > > > -Original Message- > From: Jonathan Rajotte-Julien > Sent: Tuesday, September 24, 2019 5:08 PM > To: Kramer, Zach > Cc: lttng-dev@lists.lttng.org > Subject: [EXTERNAL] Re: [lttng-dev] Problem with application changing > UID > > Hi Zach, > > Thanks for reaching out. > > lttng-ust does not support the change of uid once the application is > registered to the lttng-sessiond daemon. I think that we use the uid > received on registration for all subsequent operations. > > Gabriel Pollo-Guilbert actually worked on this this summer. You can > check out the proposed wrapper for setuid here [1]. You will need to > LD_PRELOAD it on the start of you application. It basically unregister > the application and re-register it. > > [1] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.lttng.org%2Fpipermail%2Flttng-dev%2F2019-June%2F029035.html&data > =02%7C01%7CZach.Kramer%40cognex.com%7C0a0ab1502ae24e4a4a9708d745e03d3a > %7Cc12007a4882b4381b05ab783431570c7%7C1%7C0%7C637054701722761406&s > data=%2FQCW1bbnLXEPcs1PQKKoa1v9D5ZSQSiGBwbO6khwhYI%3D&reserved=0 > This should be applied on master of lttng-ust. > Make sure to use lttng-tools master also. Same for lttng-modules if necessary. > > Would you be interested in giving it a try? > > Cheers > > On Tue, Sep 24, 2019 at 02:32:41PM +, Kramer, Zach wrote: >> Hi, >> >> Is LTTng intended to support userspace applications that change their >> UID at run-time? As in, is there an expected behavior for when this happens? >> >> For example: >> >> 1. Embedded device boots >> 2. My daemon is launched as root via systemd >> 3. Runs privileged code >> 4. Changes UID to a less privileged user (500) >> 5. Creates LTTng session >> * If session already exists, destroy it first >> 6. : Destroy session >> * Otherwise it will be destroyed next daemon launch in step 5 >> >> This causes many conflicts with the trace folders that are created. >> Most of the time, LTTng creates a folder + metadata for both root and >> the user, then puts traces in the user folder. Other times, it may >> create a folder just for the user. This is seemingly random, since >> it’s a fresh device boot each time. If the daemon is launched >> directly (i.
[lttng-dev] two tracepoints header files of one provider
For lttng-ust, can I put the tracepoint definition in two files, but they use the same provider. Thank you. Yonghong ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] use of extern before tracepoint definition
I am not sure whether this is a bug or the wrong I am using it. When I use extern declaration as follows, I always have compilation error. I used the easy-ust to demonstrate: *diff --git a/doc/examples/easy-ust/sample_component_provider.h b/doc/examples/easy-ust/sample_component_provider.h* *index dd3c5f0..e70d650 100644* *--- a/doc/examples/easy-ust/sample_component_provider.h* *+++ b/doc/examples/easy-ust/sample_component_provider.h* @@ -61,6 +61,8 @@ */ #include +extern int testint(int i); + /* * The following tracepoint event writes a message (c string) into the * field message of the trace event message in the provider *yanyh@vm*:*~/tools/lttng/lttng-ust/doc/examples/easy-ust*$ make cc -I. \ -save-temps -c -o sample.o sample.c cc -I. \ -save-temps -c -o tp.o tp.c In file included from */usr/include/lttng/ust-tracepoint-event.h:974:0*, from */usr/include/lttng/tracepoint-event.h:58*, from *sample_component_provider.h:137*, from *tp.c:33*: *././sample_component_provider.h:64:1:* *error: *expected expression before ‘*extern*’ extern int testint(int i); * ^* Makefile:34: recipe for target 'tp.o' failed make: *** [tp.o] Error 1 Thank you Yonghong ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] use of extern before tracepoint definition
- On Oct 7, 2019, at 12:06 PM, Yonghong Yan yany...@gmail.com wrote: > I am not sure whether this is a bug or the wrong I am using it. When I use > extern declaration as follows, I always have compilation error. I used the > easy-ust to demonstrate: > diff --git a/doc/examples/easy-ust/sample_component_provider.h > b/doc/examples/easy-ust/sample_component_provider.h > index dd3c5f0..e70d650 100644 > --- a/doc/examples/easy-ust/sample_component_provider.h > +++ b/doc/examples/easy-ust/sample_component_provider.h > @@ -61,6 +61,8 @@ > */ > #include > +extern int testint(int i); The tracepoint provider header is included within the lttng-ust tracepoint header generation in multiple passes. Therefore, you should not add "any" code in this header. Else you need to guard it with precompiler conditionals to ensure it is only emitted the first time the header is included, and not the following times. e.g. #ifndef SAMPLE_COMPONENT_PROVIDER_ONCE #define SAMPLE_COMPONENT_PROVIDER_ONCE extern int testint(int i); #endif Thanks, Mathieu > + > /* > * The following tracepoint event writes a message (c string) into the > * field message of the trace event message in the provider > yanyh@vm : ~/tools/lttng/lttng-ust/doc/examples/easy-ust $ make > cc -I. \ > -save-temps -c -o sample.o sample.c > cc -I. \ > -save-temps -c -o tp.o tp.c > In file included from /usr/include/lttng/ust-tracepoint-event.h:974:0 , > from /usr/include/lttng/tracepoint-event.h:58 , > from sample_component_provider.h:137 , > from tp.c:33 : > ././sample_component_provider.h:64:1: error: expected expression before ‘ > extern > ’ > extern int testint(int i); > ^ > Makefile:34: recipe for target 'tp.o' failed > make: *** [tp.o] Error 1 > Thank you > Yonghong > ___ > lttng-dev mailing list > lttng-dev@lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] two tracepoints header files of one provider
- On Oct 7, 2019, at 9:59 AM, Yonghong Yan yany...@gmail.com wrote: > For lttng-ust, can I put the tracepoint definition in two files, but they use > the same provider. Based on the terminology here: https://lttng.org/docs/v2.10/#doc-tracing-your-own-user-application You need to have at most one instance of your tracepoint provider where the header is included with TRACEPOINT_CREATE_PROBES, and exactly one instance where TRACEPOINT_DEFINE is defined. (both can end up being within the same object if you wish). Then you can include your tracepoint provider header file at will across other compile units in your program. Just make sure none of TRACEPOINT_CREATE_PROBES nor TRACEPOINT_DEFINE are defined in those other compile units. You can therefore call tracepoints from a given probe from various compile units in your program. Hoping this helps clarifying things, Mathieu > Thank you. > Yonghong > ___ > lttng-dev mailing list > lttng-dev@lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] two tracepoints header files of one provider
Thank you. I got most. To confirm, I have two header files, each defines its own tracepoint, they are from the same provider. The source files that use the header files have its own #define TRACEPOINT_CREATE_PROBES and #define TRACEPOINT_DEFINE. This won't work since two files have those defines. But if I remove #define TRACEPOINT_CREATE_PROBES#define TRACEPOINT_DEFINE from one of the two .c file, it should work. tp_one.h file: #undef TRACEPOINT_PROVIDER#define TRACEPOINT_PROVIDER hello_world #undef TRACEPOINT_INCLUDE#define TRACEPOINT_INCLUDE "./tp_one.h" #if !defined(_TP_ONE_H) || defined(TRACEPOINT_HEADER_MULTI_READ)#define _TP_ONE_H #include TRACEPOINT_EVENT( hello_world, my_first_tracepoint, TP_ARGS( int, my_integer_arg, char*, my_string_arg ), TP_FIELDS( ctf_string(my_string_field, my_string_arg) ctf_integer(int, my_integer_field, my_integer_arg) )) #endif /* _TP_ONE_H */ #include tp_one.c #define TRACEPOINT_CREATE_PROBES#define TRACEPOINT_DEFINE #include "tp_one.h" tp_two.h file: #undef TRACEPOINT_PROVIDER#define TRACEPOINT_PROVIDER hello_world #undef TRACEPOINT_INCLUDE#define TRACEPOINT_INCLUDE "./tp_two.h" #if !defined(_TP_TWO_H) || defined(TRACEPOINT_HEADER_MULTI_READ)#define _TP_TWO_H #include TRACEPOINT_EVENT( hello_world, my_second_tracepoint, TP_ARGS( int, my_integer_arg, char*, my_string_arg ), TP_FIELDS( ctf_string(my_string_field, my_string_arg) ctf_integer(int, my_integer_field, my_integer_arg) )) #endif /* _TP_TWO_H */ #include tp_two.c #define TRACEPOINT_CREATE_PROBES#define TRACEPOINT_DEFINE #include "tp_two.h" hello.c use the two tracepoints defined in the two files. To compile (compile file one by one). gcc -o hello tp-one.c tp-two.c hello.c -llttng-ust -ldl On Mon, Oct 7, 2019 at 12:22 PM Mathieu Desnoyers < mathieu.desnoy...@efficios.com> wrote: > > > - On Oct 7, 2019, at 9:59 AM, Yonghong Yan yany...@gmail.com wrote: > > > For lttng-ust, can I put the tracepoint definition in two files, but > they use > > the same provider. > > Based on the terminology here: > https://lttng.org/docs/v2.10/#doc-tracing-your-own-user-application > > You need to have at most one instance of your tracepoint provider where > the header is included with TRACEPOINT_CREATE_PROBES, and exactly one > instance where TRACEPOINT_DEFINE is defined. (both can end up being within > the same object if you wish). > > Then you can include your tracepoint provider header file at will across > other compile units in your program. Just make sure none of > TRACEPOINT_CREATE_PROBES nor TRACEPOINT_DEFINE are defined in those other > compile units. You can therefore call tracepoints from a given probe from > various compile units in your program. > > Hoping this helps clarifying things, > > Mathieu > > > Thank you. > > Yonghong > > > ___ > > lttng-dev mailing list > > lttng-dev@lists.lttng.org > > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > -- > Mathieu Desnoyers > EfficiOS Inc. > http://www.efficios.com > ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] two tracepoints header files of one provider
- On Oct 7, 2019, at 12:42 PM, Yonghong Yan wrote: > Thank you. > I got most. To confirm, I have two header files, each defines its own > tracepoint, they are from the same provider. The source files that use the > header files have its own #define TRACEPOINT_CREATE_PROBES and #define > TRACEPOINT_DEFINE. This won't work since two files have those defines. But if > I > remove #define TRACEPOINT_CREATE_PROBES#define TRACEPOINT_DEFINE from one of > the two .c file, it should work. The example below is bogus. Each of your tp_one.h and tp_two.h should have its own provider name, not "hello_world" for both. You should _only_ have a single header implementation file per provider name within an application. In my previous email, I was only refering to a case where you would want to define+create probes within a compile unit, and use the tracepoints (call them) from various other compile units in the program. Thanks, Mathieu > tp_one.h file: > #undef TRACEPOINT_PROVIDER #define TRACEPOINT_PROVIDER hello_world #undef > TRACEPOINT_INCLUDE #define TRACEPOINT_INCLUDE "./tp_one.h" #if > !defined(_TP_ONE_H) || defined(TRACEPOINT_HEADER_MULTI_READ) #define _TP_ONE_H > #include TRACEPOINT_EVENT ( hello_world , > my_first_tracepoint , TP_ARGS ( int , my_integer_arg , char * , my_string_arg > ), TP_FIELDS ( ctf_string ( my_string_field , my_string_arg ) ctf_integer ( > int > , my_integer_field , my_integer_arg ) ) ) #endif /* _TP_ONE_H */ #include > > tp_one.c > #define TRACEPOINT_CREATE_PROBES #define TRACEPOINT_DEFINE #include "tp_one.h" > tp_two.h file: > #undef TRACEPOINT_PROVIDER #define TRACEPOINT_PROVIDER hello_world #undef > TRACEPOINT_INCLUDE #define TRACEPOINT_INCLUDE "./tp_two.h" #if > !defined(_TP_TWO_H) || defined(TRACEPOINT_HEADER_MULTI_READ) #define _TP_TWO_H > #include TRACEPOINT_EVENT ( hello_world , > my_second_tracepoint , TP_ARGS ( int , my_integer_arg , char * , my_string_arg > ), TP_FIELDS ( ctf_string ( my_string_field , my_string_arg ) ctf_integer ( > int > , my_integer_field , my_integer_arg ) ) ) #endif /* _TP_TWO_H */ #include > > tp_two.c > #define TRACEPOINT_CREATE_PROBES #define TRACEPOINT_DEFINE #include "tp_two.h" > hello.c > use the two tracepoints defined in the two files. > To compile (compile file one by one). > gcc -o hello tp-one.c tp-two.c hello.c -llttng-ust -ldl > On Mon, Oct 7, 2019 at 12:22 PM Mathieu Desnoyers < [ > mailto:mathieu.desnoy...@efficios.com | mathieu.desnoy...@efficios.com ] > > wrote: >> - On Oct 7, 2019, at 9:59 AM, Yonghong Yan [ mailto:yany...@gmail.com | >> yany...@gmail.com ] wrote: >> > For lttng-ust, can I put the tracepoint definition in two files, but they >> > use >> > the same provider. >> Based on the terminology here: [ >> https://lttng.org/docs/v2.10/#doc-tracing-your-own-user-application | >> https://lttng.org/docs/v2.10/#doc-tracing-your-own-user-application ] >> You need to have at most one instance of your tracepoint provider where >> the header is included with TRACEPOINT_CREATE_PROBES, and exactly one >> instance where TRACEPOINT_DEFINE is defined. (both can end up being within >> the same object if you wish). >> Then you can include your tracepoint provider header file at will across >> other compile units in your program. Just make sure none of >> TRACEPOINT_CREATE_PROBES nor TRACEPOINT_DEFINE are defined in those other >> compile units. You can therefore call tracepoints from a given probe from >> various compile units in your program. >> Hoping this helps clarifying things, >> Mathieu >> > Thank you. >> > Yonghong >> > ___ >> > lttng-dev mailing list >> > [ mailto:lttng-dev@lists.lttng.org | lttng-dev@lists.lttng.org ] >>> [ https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev | >> > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ] >> -- >> Mathieu Desnoyers >> EfficiOS Inc. >> [ http://www.efficios.com/ | http://www.efficios.com ] > ___ > lttng-dev mailing list > lttng-dev@lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
