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 e496a5f5548f78975fba58d773da3c8aa45d8d58..5a41c3800709ff3c2a628758ed89f01636be04f7 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;