[ltt-dev] [RFC UST] Processes model

[David Goulet]

On 11-01-17 10:00 PM, Michel Dagenais wrote:
>
>>>      Consumer creation - spawns ust-consumerd.
>>
>> No ? Isn't ust-consumerd spawned separately, and then connects to ustd
>
> In which case it could be a consumer, not a daemon. In a sense strace is similar as it receives the tracing information from the kernel through ptrace and writes it to disk; yet even if it can be backgrounded, it is not called a daemon.
>

We will have to see about that since Nils is proposing something 
different about ust-consumerd that makes it "more" daemon.

>> I don't think it is needed. ustd runs as root, and if we have a bug in
>> the tracer, well, we have a bug in the tracer, that's it.
>>
>> The in-kernel LTTng does not save state to disk. If the tracer crashes
>> in the kernel, we try not to kill the whole box, but the user cannot expect
>> to be able to trace until the box reboots.
>
> Yes, I would avoid that complexity initially, and bring back the idea if there is a compelling reason.
>

For now, we will put aside this idea.

>> lttngtrace is a bit verbose. Maybe "ostrace" (as in OS Trace) ? Other
>> suggestions ?
>
> Should the same command be used kernel and ust:
>
> trace -p process_1    ->  ust tracing of process 1
> trace -k -p process_1 ->  ust + kernel tracing of process 1
> trace -k              ->  whole system tracing
>

Yes. It is the main goal. Integrate these tracer control in one tool. We 
should soon release a small roadmap explaining the goal of that tool 
(why redo ustctl and lttctl...) and also the upcoming features (Ex: 
kernel and ust trace merge, quick text dump, ...)

> Possible names? Quite a few are taken!
>   Command 'btrace' from package 'blktrace' (universe)
>   Command 'itrace' from package 'irpas' (multiverse)
>   Command 'ltrace' from package 'ltrace' (main)
>   Command 'etrace' from package 'etrace' (universe)
>   Command 'mtrace' from package 'libc-dev-bin' (main)
>   Command 'tracer' from package 'pvm-dev' (universe)
>   Command 'grace' from package 'grace' (universe)
>   Command 'xtrace' from package 'xtrace' (universe)
>   Command 'tracd' from package 'trac' (universe)
>   Command 'strace' from package 'strace' (main)
>   Command 'dtrace' from package 'systemtap-sdt-dev' (universe)
>   Command 'rtrace' from package 'radiance-sse3' (universe)
>   Command 'rtrace' from package 'radiance' (universe)
>   trace: command not found
>
> Is trace actually available?!

trace was "reserved" by Ingo for is strace alike tool.

A name has been found yesterday. I will let Mathieu make the 
announcement for that since ... it should be him :)

>
>
>> Why should ustd fork the ust-consumerd ?
>>
>> Also, we will need to represent the pipe communication between
>> ust-consumerd and
>> ustd. It is needed to control the buffer access (get/put subbuffer
>> operations).
>> If we use a named pipe for this, the access rights will probably need
>> to be
>> u+rw and g+rw (write access for group tracing too, to send commands).
>
> More details are required to understand what happens before/after setuid, when subsequent modifications are required to the tracing session (tracepoint activation).
>

Noted! A "Security" section with more details will be in the next version.

Thanks
David

-- 
David Goulet
LTTng project, DORSAL Lab.

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