[ltt-dev] [RFC UST and LTTng] Daemon model proposal

[David Goulet]

On 11-01-20 09:36 AM, Michel Dagenais wrote:
>
>> This time, the proposal is for both LTTng and UST which get integrated
>
> It looks good, the structure is relatively simple. The documentation would benefit from some motivation for the choices taken IMHO.
>
> Some questions and remarks follow. Most of these questions dont necessarily imply that the proposal is not the good solution but rather that explanations and motivations would be useful to convey to the reader why the proposed architecture was designed in this way.
>
> ----------------
>
> This RFC propose brand new UST and LTTng daemon model. This re-engineering was
> mostly driven by the need of better security in terms of access rights, tracing
> session, LTTng and UST integration and networking such as streaming and remote
> control over different traces and
>
> -->  scaling may be another consideration to mention
>

Will be in the next version of the document.

> The ltt-sessiond daemon acts as a trace registry i.e. by keeping reference to
> all active session and, by active, it means a session in any state other than
> destroyed.  Each entity we are keeping track of, here session, will have a
> unique identifier or pidunique (ID) assign to it.
>
> -->  why do we need/want a unique sessiond? To maintain with a single daemon the list of available applications to trace? In flight recorder mode, tracing is active and shared memory regions should be held but no other tracing application may need to run (drtrace, consumer...); it then looks plausible to have a single process capable of holding to these shared memory regions (in case the traced application finishes or crashes) and this process can be used to let a user decide at a later time to discover and connect to these traced applications.
>

Will be in the next version of the document.

>      Buffers creation - creates shared memory for the tracing buffers.
>
> -->  Why is buffer creation the responsability of the sessiond? Ressource accounting, preventing abuses, is easier if the traced application via libust does the buffer creation!
>

The main reason was because the application cannot set the shared memory 
with the read access to the tracing group. (unless the apps uid is in 
the tracing group).

Actually, the resources accounting, abuses and so on are now sessiond 
jobs. It will make sure it can allocate the buffers, it will keeps 
reference to these buffers for possible multiple consumers, in case the 
apps crashes, we still have the control over the buffers for drtrace to 
access them.

A clear description will be added to the document.

> The purpose of this daemon is to consume the UST trace buffers for only a
> specific session. The session MAY have several traces for example two different
> applications.
>
> -->  why can't drtrace do it? We seem to have a one to one mapping between drtrace and consumerd? The user starts and sees drtrace but the spawned consumerd would be less visible and thus less intuitive. If we kill drtrace, does consumerd survive? can it be reconnected to?
>

No actually, 1 consumerd = 1 session. Again, a more detail description 
will be added.

> This daemon basically empty the tracing buffers when asked for and write that
> data to disk for future analysis using LTTv or/and TMF (Tracing Monitoring
> Frameworks). Upon creation, that daemon UID/GID is set to the user credentials
> and so are the data files on disk.
>
> -->  please be very specific, which process spawns (fork/exec) which other, what do you mean by "that daemon UID/GID is set ti the user credentials" is it as such by default upon forking or is some combination of setuid... calls required for that?
>

Will be in the next version of the document.

Thanks!
David

-- 
David Goulet
LTTng project, DORSAL Lab.

PGP/GPG : 1024D/16BD8563
BE3C 672B 9331 9796 291A  14C6 4AF7 C14B 16BD 8563