Fix: don't abort metadata push on closed metadata

The failure/exit of any of the consumerd, relayd or applications
(in per-PID buffer mode) will cause the metadata closed flag to
be set.

While pushing new metadata updates to the consumerd (and relayd
in streaming/live scenarios) will fail, those conditions should
be handled in-place.

Applications are _expected_ to exit during the course of a per-PID
session. However, they will typically have pushed their metadata
to the metadata cache before doing so. The session daemon must
flush the unconsumed metadata to the consumerd in this case.

Failure to answer to the metadata request originating from the
consumerd can cause it to keep the stream lock held and, thus,
prevent the channel poll thread from cleaning up on channel
close.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

diff --git a/src/bin/lttng-sessiond/ust-app.c b/src/bin/lttng-sessiond/ust-app.c
index f30df2097fd36aea2b03d2f30f96d791226dc1a9..7418a45fdf5c058b3c38729c6f76dfeaeee7731b 100644 (file)
--- a/src/bin/lttng-sessiond/ust-app.c
+++ b/src/bin/lttng-sessiond/ust-app.c
@@ -566,18 +566,6 @@ ssize_t ust_app_push_metadata(struct ust_registry_session *registry,
                return 0;
        }
 
-       /*
-        * On a push metadata error either the consumer is dead or the
-        * metadata channel has been destroyed because its endpoint
-        * might have died (e.g: relayd), or because the application has
-        * exited. If so, the metadata closed flag is set to 1 so we
-        * deny pushing metadata again which is not valid anymore on the
-        * consumer side.
-        */
-       if (registry->metadata_closed) {
-               return -EPIPE;
-       }
-
        offset = registry->metadata_len_sent;
        len = registry->metadata_len - registry->metadata_len_sent;
        new_metadata_len_sent = registry->metadata_len;