[ltt-dev] lttng-agent and ust issues

[pierre-marc.fournier@polymtl.ca (Pierre-Marc Fournier)]

On 08/20/2010 11:56 AM, Alexis Hall? wrote:
> Hello everyone,
>
> While writing a manual for lttng-agent, I noticed that a lot functionality is
> missing when controlling ust traces. The following is a list of known issues and
> hints on how to address them, for anyone interested. I will also put this info
> in the lttng-agent git repo, in the TODO file.
>
> As it is, lttng-agent can create, configure, start, stop and destroy kernel
> traces and can stream the data across the network. It can also do most of these
> things with ust traces, including streaming. There are however a lot of
> commands that are not supported by the ust provider.
>
> The following commands are accepted by the kernel provider but not the ust
> provider:
>
> allocTrace
> getActiveTraceInfo
> getActiveTraces
> getTraces
> setChannelEnable
> setChannelOverwrite
> setChannelSubbufNum
> setChannelSubbufSize
> setMarkerEnable
> setTraceTransport
> stopWriteTraceLocal
>
> The following commands are accepted but do not work exactly in the same way:
>
> setChannelTimer
> setupTrace
> writeTraceLocal
> writeTraceNetwork
>
> One of the main cause of these problems is missing functions in the ustcmd
> library used to communicate with the traced process. In particular, it lacks a
> simple setup function. It only supplies a setup_and_start function, which is
> essentially an aggregate of setup, alloc and start. This causes two problems.
> First, we can't create the trace, change subbuffer count/size and then allocate
> the trace, as it is done in a single operation. Second, as the trace is started
> right away, it needs to connect to a daemon to request collection. If we want
> to stream the data, we have to tell ust to connect to the agent before we
> create the trace, or it will default to the local global ustd daemon. This
> causes a weird requirement to call writeTraceNetwork, specifying a trace which
> does not exist yet, and then create the trace with setupTrace.
>
> In addition to being a counterintuitive way to do things, this is not the way it
> works for the kernel provider. This could cause problems for higher-level tools
> like the eclipse control plugin, which, I believe, makes no distinction between
> a ust trace and a kernel trace.
>
> There are already ustcmd functions to alloc and start the trace. Adding one to
> only do the setup would help fix the problems with allocTrace,
> setChannelSubbufNum, setChannelSubbufSize, setupTrace and writeTraceNetwork. I
> believe libust is already setup to do this, it just needs to be exposed
> throught ustcmd.
>
> getActiveTraceInfo, getActiveTraces, setChannelEnable, setChannelOverwrite and
> getTraces would also need added functionality in ustcmd.
>
> I'm not sure about the implications of implementing stopWriteTraceLocal, as the
> local tracing is currently done in another process (ustd).
>
> setChannelTimer does not set a per-channel timer, but instead uses a single
> timer for all channels and for all traces the agent monitors. This was done as
> a first step and will probably need to be elaborated a bit.
>
> As for the remaining commands, setTraceTransport is not needed, and I see no
> obstacle to the implemention of setMarkerEnable.
>
> Hopefully these issues can be addressed in the near future, but in the meantime
> they are documented in the manual.
>

Except for the per-channel timer, these are all trivial to add, as there 
already are libust commands for them.

Not sure about the intended semantics of stopWriteTraceLocal, but 
normally you need to call destroy to flush all the buffers to disk after 
a stop, otherwise it just "pauses" the trace. Once you destroyed the 
trace, the daemon keeps running for future traces, but the trace is 
finished.

These commands map to either existing ustctl commands or environment 
variables. The ustctl man page explains in detail the various stages 
(start, stop, destroy) and I just committed to HEAD some changes to add 
even more detail. The environment variables are well described in the 
ust manual.

pmf