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
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
