Fix: don't spawn relayd if URL is provided

In the lttng command line tool, relayd should only be spawned for the
default use case which is no URL provided.

Signed-off-by: David Goulet <dgoulet@efficios.com>
Fix: add consumer wake up pipe to avoid race

UST application will notify the wait_fd pipe for every subbuffer that it
writes and ready to be consumed. However, on *high* load systems, this
1:1 property can fail if the pipe gets filled up. For performance
reason, UST will ignore this error and continue since it can't wait for
the pipe to clear up.

This triggers a race condition where we have *one* wake up on the UST
pipe for potentially multiple subbuffers. A data pending command will
wait forever on streams that still has data but the data thread could'nt
consumed them because of this 1:n possible race. Using the stop command
without waiting would mean a memory/fd leak of the stream.

Thus, we add a consumer wake up pipe here that notifies the data thread
if there is still data to be read after a successful read subbuffer
call. With this, we end up handling the residual buffers if any since
the data thread is always notified when there is still data to be read.

Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: David Goulet <dgoulet@efficios.com>
Fix: take session list lock when listing tp

This is important since the list tracepoints command access the
application socket to ask the application for its TPs. The session list
lock protects the ordering of message for those sockets.

This was triggering out of order message between the session daemon and
an application thus triggering undefined behavior.

Fixes #774

Signed-off-by: David Goulet <dgoulet@efficios.com>
Fix: don't print stream name in error message

The stream received, in per UID, is actually a temporary stream object
that only contains the UST object data which is the relevant part for
UST to use.

Thus on error the name was random data thus print the valid handle
descriptor instead of invalid data.

Signed-off-by: David Goulet <dgoulet@efficios.com>