[ltt-dev] [RFC UST and LTTNG] Daemon model proposal v0.4

[David Goulet]

On 11-02-02 03:35 AM, Nils Carlson wrote:
> Hi David,
>
> I will try to comment as well as I can below...
>
> David Goulet wrote:
>> Model
>> -----------------
>>
>> A global and/or per-user registry keeps track of all tracing sessions.
>> Any user
>> that wants to manage either a kernel trace using LTTng or an
>> application trace
>> with UST must interact with that registry for any possible actions.
>>
>
> We can start here... :-)
>
> What do we need the session daemon for in the case where a single user
> has downloaded
> and compiled UST in his home directory? What is wrong with the socket
> per app
> and direct connection approach. Please clarify WHAT exactly we need a
> session daemon for.

I will.


>> This daemon is also responsible for tracing buffers creation. Two main
>> reasons
>> motivate this design:
>>
>> * The ltt-sessiond needs to keep track of all the shared memory
>> segments in
>> order to be able to give reference to any other possible consumer.
>>
>> * For the case of sharing tracing buffers between all userspace
>> applications, having the registry allocating them will allow that but, if
>> the inprocess library was allocating them, we will need to redesign the
>> whole model.
>>
> Ok, here I once again need a motivation in the text.
>
> App is user A
> Session daemon user root with gid trace
> consumer has gid trace.
>
>
> Here is another approach that I'd like you to consider.
> app creates buffer with mode 0700.
> the session daemon is connected so the app sends a reference to the
> session daemon containing the shmid.
> The trace daemon changes the mode to 0750 and the gid to the tracing group
> and then discards the reference. Hej presto, we don't need to keep a
> reference
> to the shared memory and the consumers can happily consume.

However, for another consumer that can jump in, who's gonna give him the 
shared memory reference? I can't be the inprocess lib because we need to 
manage access rights in order to NOT allow anyone reading these buffers.

This is why, the only way to get that reference is either be an 
application or being able to talk to sessiond via the socket 660 
(root:tracing).

I was mistaken last time when I told you that the apps CANNOT set the 
gid tracing. Actually, it's possible to set once credentials on a shm 
without having the rights.

>>
>> The trace roles of ltt-sessiond:
>>
>> Trace interaction - Create, Destroy, Pause, Stop, Start, Set options
>>
>> Registry - keep track of trace's information:
>> * shared memory location (only the keyid)
>> * application PID (UST)
>> * type (kernel or UST)
>> * session name
>> * UID
>>
> Can a non-priviled user trace the kernel?

Eventually, by some voodoo LTTng-Desnoyers tricks, we will be able to do 
that for the tracing group.

>
> Also, how aware are multiple session daemons of each other?

Per-user sessiond are not design to be aware of each others. I should 
mention that! thanks.

>> UST-CONSUMERD:
>
> Ok, we can start with a little note. ust-consumerd could just as well
> have been
> called ust-disk-consumer. It instantiates libustconsumer which does the
> work.
>
> I would want you to re-write this chapter taking into account multiple
> instances
> of libustconsumer.

I can put a use case where multiple ust-consumerd live together.

>>
>> 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. The client tool, drtrace has to create the ust-consumerd
>> if NONE
>> is available for that session. It is very important to understand that
>> for a
>> tracing session, there is only one ust-consumerd for all the traced
>> applications.
> So we are back at one libustconsumer instance per session? Why do we
> want so many
> processes hanging about?

Actually, you can argue that the number of process is less.

Ex: One session for one user (UST) means one ust-consumerd per CPU.

ust-consumerd could act as a thread pool for that.

>> Quick buffer snapshot:
>>
>> 1) Here, drtrace will request a buffer snapshot for an already running
>> session.
>>
>> +-----------+ +--------------+ | drtrace A |-------- ops ------->|
>> ltt-sessiond | +-----------+ +--------------+ | | command
>> | +-----------------+ +-------+<--+
>> | | ust-consumerd 1 |<----| app_1 |-+
>> | +-----------------+ +-------+ | write
>> | 1 | v | | +-------------+
>> | +--- read ----->| shared mem. |
>> | +-------------+ | ^ | +-----------------+ |
>> +->| ust-consumerd 2 |----------+
>> +-----------------+ snapshot
>> | write
>> |
>> +---> disk/network
>>
> Hm, here you have the session daemon acting as a command router. I
> really don't
> recommend that.

I do agree about that. Way more complex. But... the only way we could 
think of for security.

>
> I think I have to end here... But there is an old adage from somewhere
> that goes
> "show us the code". This form of programming on paper and design by
> committee
> is very painful, takes a lot of time and creates a lot of strife.
>

Oh yes...!

> I recommend you put down the pen and start coding away instead. Put some
> patches
> up and we can review them and try them out. I think that you will
> realize that
> you want to minimize the amount of state that you replicate as well as
> the total
> amount of information you keep track of. Once you've done that we can start
> discussing models again.
>
> Even if we were to rubber stamp a final Daemon model proposal you can
> very well
> run into design issues along the way that force you to completely change
> your
> approach.
>

Yep! Now is the time to get some codes out! :)

We will incrementally get better, found problems and so on.

Thanks for these precious feedbacks!

David

> /Nils
>

-- 
David Goulet
LTTng project, DORSAL Lab.

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