Rename C++ header files to .hpp Rename all C++ header files (include/**/*-internal.h, src/**/*.h except argpar and msgpack, some headers in tests) to have the .hpp extension. Doing so highlights that we include some C++ header files in some test files still compiled as C. This is ok for now, as the files they include don't actually contain C++ code incompatible with C yet, but they could eventually. This is something we can fix later. Change-Id: I8bf326b6b2946a3e26704f3ef3ac5831bbe9bc26 Signed-off-by: Simon Marchi <simon.marchi@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Copyright ownership transfer Apply copyright ownership transfer from David Goulet, Julien Desfossez, and Simon Marchi to EfficiOS Inc. Link: https://lists.lttng.org/pipermail/lttng-dev/2022-January/030087.html Link: https://lists.lttng.org/pipermail/lttng-dev/2022-January/030092.html Link: https://lists.lttng.org/pipermail/lttng-dev/2022-January/030091.html Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Signed-off-by: David Goulet <dgoulet@ev0ke.net> Signed-off-by: Julien Desfossez <ju@klipix.org> Signed-off-by: Simon Marchi <simon.marchi@efficios.com> Change-Id: Id13575afd4a2a09bb91a8d2b7a12dc3db8dc329f
Fix: action executor: deadlock on session_list_lock Observed issue ============== A dead lock is observed during the start-stop test suite for triggers. Cause ===== A start session action is executed by the action executor, the `cmd_start_trace` function is called and effectively holds the `session_list_lock.`. During `cmd_start_trace` a call to `notification_thread_command_add_channel` is performed to inform the notification thread of the new channel presence. At the same time, a tracer event notification is received by the notification thread. The actions are queued up and the sample of the session id take place and a call to `session_lock_list` is performed and blocks on the lock operation. The notification thread wait on the `session_list_lock` and the `session_list_lock` holder, the action executor, waits on the completion of a command the be run by the notification thread: deadlock. The backtrace: Thread 6 (Thread 0x7f831c8a6700 (LWP 3046458)): #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x000000000053b852 in futex (uaddr=0x7f831c8a45e0, op=0, val=0, timeout=0x0, uaddr2=0x0, val3=0) at /home/joraj/lttng/master/install/include/urcu/futex.h:72 #2 0x000000000053b4f9 in futex_noasync (uaddr=0x7f831c8a45e0, op=0, val=0, timeout=0x0, uaddr2=0x0, val3=0) at /home/joraj/lttng/master/install/include/urcu/futex.h:81 #3 0x000000000053af10 in lttng_waiter_wait (waiter=0x7f831c8a45d8) at waiter.c:55 #4 0x000000000046b0f2 in run_command_wait (handle=0xe60520, cmd=0x7f831c8a4588) at notification-thread-commands.c:49 #5 0x000000000046b270 in notification_thread_command_add_channel (handle=0xe60520, session_name=0x7f8300006c30 "my_triggered_session", uid=1000, gid=1000, channel_name=0x7f82dc00be04 "channel0", key=1, domain=LTTNG_DOMAIN_UST, capacity=2097152) at notification-thread-commands.c:184 #6 0x00000000004c7f65 in create_channel_per_uid (app=0x7f82d8000bf0, usess=0x7f8300000bb0, ua_sess=0x7f82dc002600, ua_chan=0x7f82dc00bde0) at ust-app.c:3360 #7 0x00000000004c6f98 in ust_app_channel_send (app=0x7f82d8000bf0, usess=0x7f8300000bb0, ua_sess=0x7f82dc002600, ua_chan=0x7f82dc00bde0) at ust-app.c:3514 #8 0x00000000004c6bde in ust_app_channel_create (usess=0x7f8300000bb0, ua_sess=0x7f82dc002600, uchan=0x7f8300005a90, app=0x7f82d8000bf0, _ua_chan=0x7f831c8a48b0) at ust-app.c:4771 #9 0x00000000004c6968 in find_or_create_ust_app_channel (usess=0x7f8300000bb0, ua_sess=0x7f82dc002600, app=0x7f82d8000bf0, uchan=0x7f8300005a90, ua_chan=0x7f831c8a48b0) at ust-app.c:5610 #10 0x00000000004c4f09 in ust_app_synchronize_all_channels (usess=0x7f8300000bb0, ua_sess=0x7f82dc002600, app=0x7f82d8000bf0) at ust-app.c:5820 #11 0x00000000004b958c in ust_app_synchronize (usess=0x7f8300000bb0, app=0x7f82d8000bf0) at ust-app.c:5886 #12 0x00000000004b8500 in ust_app_global_update (usess=0x7f8300000bb0, app=0x7f82d8000bf0) at ust-app.c:5960 #13 0x00000000004b7ec2 in ust_app_start_trace_all (usess=0x7f8300000bb0) at ust-app.c:5520 #14 0x0000000000444e86 in cmd_start_trace (session=0x7f8300006c30) at cmd.c:2707 #15 0x00000000004a5af9 in action_executor_start_session_handler (executor=0x7f8314004410, work_item=0x7f8314005100, item=0x7f83140050b0) at action-executor.c:342 #16 0x00000000004a537f in action_executor_generic_handler (executor=0x7f8314004410, work_item=0x7f8314005100, item=0x7f83140050b0) at action-executor.c:696 #17 0x00000000004a4dbc in action_work_item_execute (executor=0x7f8314004410, work_item=0x7f8314005100) at action-executor.c:715 #18 0x00000000004a37e6 in action_executor_thread (_data=0x7f8314004410) at action-executor.c:797 #19 0x0000000000486193 in launch_thread (data=0x7f83140044b0) at thread.c:66 #20 0x00007f8320b60609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #21 0x00007f8320a87293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 5 (Thread 0x7f831d0a7700 (LWP 3046457)): #0 __lll_lock_wait (futex=futex@entry=0x5e1c10 <ltt_session_list>, private=0) at lowlevellock.c:52 #1 0x00007f8320b630a3 in __GI___pthread_mutex_lock (mutex=0x5e1c10 <ltt_session_list>) at ../nptl/pthread_mutex_lock.c:80 #2 0x00000000004378c3 in session_lock_list () at session.c:156 #3 0x00000000004a871c in add_action_to_subitem_array (action=0x7f830001a730, subitems=0x7f83140051d0) at action-executor.c:1081 #4 0x00000000004a8578 in add_action_to_subitem_array (action=0x7f830001a620, subitems=0x7f83140051d0) at action-executor.c:1025 #5 0x00000000004a4922 in populate_subitem_array_from_trigger (trigger=0x7f830001a950, subitems=0x7f83140051d0) at action-executor.c:1116 #6 0x00000000004a416e in action_executor_enqueue_trigger (executor=0x7f8314004410, trigger=0x7f830001a950, evaluation=0x7f8314005190, object_creds=0x0, client_list=0x7f8314004980) at action-executor.c:924 #7 0x0000000000479481 in dispatch_one_event_notifier_notification (state=0x7f831d0a63e8, notification=0x7f8314005160) at notification-thread-events.c:4613 #8 0x0000000000472324 in handle_one_event_notifier_notification (state=0x7f831d0a63e8, pipe=65, domain=LTTNG_DOMAIN_UST) at notification-thread-events.c:4702 #9 0x0000000000472271 in handle_notification_thread_event_notification (state=0x7f831d0a63e8, pipe=65, domain=LTTNG_DOMAIN_UST) at notification-thread-events.c:4717 #10 0x00000000004695a3 in handle_event_notification_pipe (event_source_fd=65, domain=LTTNG_DOMAIN_UST, revents=1, state=0x7f831d0a63e8) at notification-thread.c:591 #11 0x000000000046849b in thread_notification (data=0xe60520) at notification-thread.c:727 #12 0x0000000000486193 in launch_thread (data=0xe60610) at thread.c:66 #13 0x00007f8320b60609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #14 0x00007f8320a87293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Solution ======== Instead of using session_find_by_name() which requires the `session_list_lock`, we introduce `sample_session_id_by_name` that uses a urcu backed data structure. This allows the sampling of the session id without holding the session list lock. We accept the small window where a session object is still accessible but concretely not valid since the actual execution context will be validated at the moment of execution. The execution side already handles the possibility that the session is removed at that point or is not the same session. The execution side acquires the session_list_lock for validation. Known drawbacks ========= None Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: I5ad2c57acc0d03d2814dda59f8ecf2d831fd961e
Fix: sessiond: acquire session list lock when updating event notifiers Registering triggers with an on-event hit condition affects event notifiers, imposing a synchronization of enablers with the user space tracers. As noted in the comments of session.h, the session list lock protects those updates and is, ultimately, ill-named. The comment is adjusted to mention "tracer configurations" rather than "session configurations" since event notifiers are not part of a session, making the comment imprecise. Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: Id1bcbcccbdeeafa91176ed3413ddddbcbab10ad2
sessiond: enforce user-exclusive session access in session_access_ok The current session_access_ok logic disallows the access to a session when: uid != session->uid && gid != session->gid && uid != 0 This means that any user that is part of the same primary group as the session's owner can access the session. The primary group is not necessarily (and most likely) not the `tracing` group. Moreover, the `tracing` group is not meant to provide shared access to sessions, but to allow interactions with a root session daemon. For instance: - the session has uid = 1000, gid = 100 - the current user has uid = 1001, gid = 100 access to the session is granted. This is way too broad and unexpected from most users as the LTTng documentation never mentions this "primary group share tracing sessions" behaviour. The documentation only alludes to the fact that separate users have "their own set of sessions". On most distributions, this change will have no impact as `useradd` creates a new group for every user. Users will never share a primary group and thus can't control each others' sessions. However, it is not unusual to have users share a primary group (e.g. `users`) and set the default umask to `0700`. In that case, there is no expectation that every user will share files and there would be no reasonable expectation that they should share all sessions. For instance, it would be unexpected for one user to tear down the sessions of other users with a single `lttng destroy -a` command. If this type of session sharing is desirable to some users, then the default umask of users could be checked or sessions could be created as part of a group. However, in doubt, it is preferable to be strict. This is not marked as a fix since this was most likely deliberate and the change could, although unlikely, break existing deployment scenarios. Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: I98f7ffb29d5f6dcb9d660535c1d3f5a1d1a68293
Fix: stream intersection fails on snapshot of cleared session Observed issue ============== In the following scenario: lttng create --snapshot lttng enable-event -u -a lttng start taskset -c 0 <tracepoint producing app> lttng clear taskset -c 0 <tracepoint producing app> lttng snapshot record lttng destroy When using the stream-intersection mode, babetrace complains that the time range for the intersection is invalid since the begin timestamp is after the end timestamp. This is caused by the presence of "inactive" streams for which no events are recorded between the clear action and the recording of the snapshot. These streams have a begin timestamp roughly equal to the moment when the snapshot was taken (i.e. the end timestamp). Babeltrace, in stream-intersection mode, attempts to use the latest beginning timestamp of all streams as the start of the intersection and the earliest end timestamp as the end boundary. Path │File size │Packets │Timestamp: beginning │Timestamp: end │ snapshot-1-20200622-212617-1/ust/uid/1000/64-bit/channel0_0 │ 4.000 KiB│ 1│2020-06-22 21:26:01.903685878│2020-06-22 21:26:17.630456312│ snapshot-1-20200622-212617-1/ust/uid/1000/64-bit/channel0_1 │ 4.000 KiB│ 1│2020-06-22 21:26:17.630909310│2020-06-22 21:26:17.630909310│ snapshot-1-20200622-212617-1/ust/uid/1000/64-bit/channel0_2 │ 4.000 KiB│ 1│2020-06-22 21:26:17.631295033│2020-06-22 21:26:17.631295033│ snapshot-1-20200622-212617-1/ust/uid/1000/64-bit/channel0_3 │ 4.000 KiB│ 1│2020-06-22 21:26:17.631673614│2020-06-22 21:26:17.631673614│ Cause ===== The packet beginning timestamps of the buffers are initialized on creation (on the first "start" of a tracing session). When a "clear" is performed on a session, all open packets are closed and the existing contents are purged. If a stream is inactive, it is possible for no packet to be "opened" until a snapshot of the tracing session is recorded. Solution ======== A new consumer command, "open channel packets" is added. This command performs a "flush empty" operation on all streams of a channel. This command is invoked after a clear (after the tracing is re-started) and on start. This ensures that streams are opened as soon as possible after a clear, a rotation, or a session start. Known drawbacks =============== In the case of an inactive stream, this results an extra empty packet at the beginning of the inactive streams (typically 4kB) in the snapshots. In the case of an active stream, this change will cause the first packet to be empty or contain few events. If the stream is active enough to wrap-around, that empty packet will simply be overwritten. Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: I19b5c630fa8bddfb13c3c10f86c6cc9dc4990b08
Fix: sessiond: sessiond and agent deadlock on destroy Observed issue -------------- While running the out-of-tree java agent tests [1], the session daemon and agent often end up in a deadlock. Attaching gdb to the session daemon, we can see that two threads are blocked in an intriguing state. Thread 13 (Thread 0x7f89027fc700 (LWP 9636)): #0 0x00007f891e81a4cf in __lll_lock_wait () from /usr/lib/libpthread.so.0 #1 0x00007f891e812e03 in pthread_mutex_lock () from /usr/lib/libpthread.so.0 #2 0x000055637f1fbd92 in session_lock_list () at session.c:156 #3 0x000055637f25dc47 in update_agent_app (app=0x7f88ec003480) at agent-thread.c:56 #4 0x000055637f25ec0a in thread_agent_management (data=0x556380cd2400) at agent-thread.c:426 #5 0x000055637f22fb3a in launch_thread (data=0x556380cd24a0) at thread.c:65 #6 0x00007f891e81046f in start_thread () from /usr/lib/libpthread.so.0 #7 0x00007f891e7203d3 in clone () from /usr/lib/libc.so.6 Thread 8 (Thread 0x7f8919309700 (LWP 9631)): #0 0x00007f891e81b44d in recvmsg () from /usr/lib/libpthread.so.0 #1 0x000055637f267847 in lttcomm_recvmsg_inet_sock (sock=0x7f88ec0033c0, buf=0x7f89192f5d5c, len=4, flags=0) at inet.c:367 #2 0x000055637f2146c6 in recv_reply (sock=0x7f88ec0033c0, buf=0x7f89192f5d5c, size=4) at agent.c:275 #3 0x000055637f215202 in app_context_op (app=0x7f88ec003400, ctx=0x7f8908020900, cmd=AGENT_CMD_APP_CTX_DISABLE) at agent.c:552 #4 0x000055637f215c2d in disable_context (ctx=0x7f8908020900, domain=LTTNG_DOMAIN_JUL) at agent.c:841 #5 0x000055637f217480 in agent_destroy (agt=0x7f890801dc20) at agent.c:1326 #6 0x000055637f243448 in trace_ust_destroy_session (session=0x7f8908004010) at trace-ust.c:1408 #7 0x000055637f1fd775 in session_release (ref=0x7f8908001e70) at session.c:873 #8 0x000055637f1fb9ac in urcu_ref_put (ref=0x7f8908001e70, release=0x55637f1fd62a <session_release>) at /usr/include/urcu/ref.h:68 #9 0x000055637f1fdad2 in session_put (session=0x7f8908000d10) at session.c:942 #10 0x000055637f2369e6 in process_client_msg (cmd_ctx=0x7f890800e6e0, sock=0x7f8919308560, sock_error=0x7f8919308564) at client.c:2102 #11 0x000055637f2375ab in thread_manage_clients (data=0x556380cd1840) at client.c:2347 #12 0x000055637f22fb3a in launch_thread (data=0x556380cd18b0) at thread.c:65 #13 0x00007f891e81046f in start_thread () from /usr/lib/libpthread.so.0 #14 0x00007f891e7203d3 in clone () from /usr/lib/libc.so.6 T8 is holding session list lock while the cmd_destroy_session command is being processed. More specifically, it is attempting to destroy an "agent_context" by communicating with an "agent" application. Meanwhile, T13 is still registering that same "agent" application. Cause ----- The deadlock itself is pretty simple to understand. The "agent thread" (T13) has the responsability of accepting new agent application connections. When such a connection occurs, the thread creates a new `agent_app` instance and sends the current sessions' configuration (i.e. their event rules and contexts) to the agent application. When that "update" is complete, a "registration done" message is sent to the new agent application. From the stacktrace above, we can see that T13 is attempting to update the agent application with its initial configuration, but it is blocked on the acquisition of the session list lock. The application's agent is also blocked since it is waiting for the "registration done" message before allowing tracing to proceed (not shown here, but seen in the test logs). Meanwhile, T8 is holding the session list lock while destroying a session. This is expected as all client commands are executed with this lock held. It is, amongst other reasons, used to serialize changes to the sessions' configuration and configuration updates sent to the tracers (i.e. because new apps appear or to keep existing tracers in sync with the users' session configuration). The question becomes: why is T8 tearing down an application that is not yet registered? First, inspecting `agent_app` immediately shows that this structure has no built-in synchronization mechanism. Therefore, the fact that two threads are accessing it at the same time raises a big red flag. Speculating on the intentions of the original design, my intuition is that the "agent_management" thread's role is limited to instantiating an `agent_app` and synchronizing it with the various sessions' configuration. Once that synchronization is performed, the agent application should be published and never accessed again by the "agent thread". Configuration updates (i.e. new event rules, contexts) are then sent synchronously as they are requested by a client in the context of the client thread. Those updates are performed while holding the session list lock. Hence, there is only one thread that should manipulate the agent application at any given time making an explicit `agent_app` lock unnecessary. Overall, this would echo what is done when a 'user space tracer' application registers to the session daemon (see dispatch.c:368). Evidently this isn't what is happening here. The agent thread creates the `agent_app`, publishes it, and then performs an "agent app update" (sending the configuration) while holding the session list lock. This means that there is a window where an agent application is visible to the other threads, yet has not been properly registered. Solution -------- The acquisition of the session list lock is moved outside of update_agent_app() to allow the "agent thread" to hold the session list lock during the "configuration update" phase of the agent application registration. Essentially, the sequence of operation changes from: - Agent tcp connection established - call handle_registration() - agent version check - allocation of agent_app instance - new agent_add is published through the global agent_apps_ht_by_sock hashtable *** it is now reachable by all other threads without any form of exclusivity synchronization. *** - update_agent_app - acquire session list lock - iterate over sessions - send configuration - release session list lock - send registration done to: - Agent tcp connection established - call accept_agent_registration() - agent version check - allocation of agent_app instance - acquire session list lock - update_agent_app - iterate over sessions - send configuration - send registration done - new agent_add is published through the global agent_apps_ht_by_sock hashtable - release session list lock Links ----- [1] https://github.com/lttng/lttng-ust-java-tests Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: Ia34c5ad81ed3936acbca756b425423e0cb8dbddf
Move to kernel style SPDX license identifiers The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. See https://spdx.org/ids-how for details. Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Change-Id: I62e7038e191a061286abcef5550b58f5ee67149d Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
trace-chunk: Introduce chunk "path", relayd session "ongoing_rotation", sessiond session "rotated" This commit introduces new attributes in 3 different structures because those are used in surrounding areas of the code. Introduce a trace chunk path attribute which tracks where the chunk currently keeps its files. It allows updating the current chunk location with the "rename" API without having to rely on changing the chunk name override, which is an attribute we may want to keep using when we archive the chunk. Separating the "path" from the "name override" attribute allows easy manipulation of the chunk output without having to keep the name override around in the caller code. Introduce an "ongoing_rotation" relayd session attribute to allow live viewers to retry while a rotation is ongoing. This ongoing rotation attribute is introduced in the same commit as the path chunk attribute because they are used in a surrounding area of the code. Introduce a "rotated" sessiond session attribute in this commit because it is used in a surrounding area of the code. This rotated attribute tracks whether an explicit rotation has been performed on the session. It is a preparation step for the clear feature, which will use this to figure out whether it needs to clear the "root" output path (no rotation prior to clear") or if it needs to clear to a new path. Before introduction of the clear feature, a chunk_id of 0 was used to identify this, but because clear will increment the chunk id without changing the path, we need to track this explicitly through the "rotated" session flag. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Change-Id: Ifdecc66cb4849f3e5f7476ab7db48d8f7532a6d3 Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
sessiond: add clear notifier Add a clear notifier array to reply to clients requesting a clear command. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Change-Id: I422d87b0122b75be47ae5941fed15f09e87460fe Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
sessiond: introduce cleared_after_last_stop Track whether a session was cleared after the last stop, so additional clear will be effect-less until it is started again. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Change-Id: Icaa86acab20081b436bd55d026ec79a10c56034b Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
sessiond: cmd_rotate_session: introduce command argument Add a command type argument to cmd_rotate_session(). Change the internal session_close_trace_chunk() API to introduce the LTTNG_TRACE_CHUNK_COMMAND_TYPE_NO_OPERATION command rather than rely on a NULL pointer, which facilitates passing of command argument across cmd_rotate_session. This introduces the LTTNG_TRACE_CHUNK_COMMAND_TYPE_DELETE command, which is required for the clear feature. Its implementation will follow in a separate commit. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Change-Id: Ic1d8cbab1f98b93f1f6d27a2c6624ac2780932e2 Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Fix: move set base_path of session to URI configuration The load code still uses the "old" API to create and configure network session output (lttng_create_session followed by lttng_set_consumer_url). The session base_path is only set in the cmd_create_session_from_descriptor function. This results in invalid network output paths when using a loaded session configuration (xml). While we might want to move the load code to the new API, there is a case to be made in not breaking the previous API behaviour. To restore the expected behaviour of lttng_set_consumer_url, move the assignation of the session base_path to the cmd_set_consumer_uri function (LTTNG_SET_CONSUMER_URI). Both the previous and session descriptor based creation API uses this code path when needed (network output). Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
relayd protocol: reply path for close chunk and create session 2.11 Since the relay daemon is expected to be able to move the target destination of the trace, reply the chunk and session path so session can have relevant data rather than guessing their location. The session daemon now use this information to send the path back to the client for rotation and destroy commands, as well as for rotation completion notifications. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
relayd comm: add base path to create session Add base path and session_name_contains_creation_time flag to session creation 2.11 message. Use it to ensure the "auto-<ts>" session names don't get duplicate timestamps for their output paths. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Fix: honor base path for network URIs Starting from 2.11, the following use-case stopped working as expected: lttng create --set-url=net://localhost/my/path/custom lttng enable-event -u -a lttng start [ run app ] The output trace is expected in the following directory on the relayd (no timestamp suffix): $LTTNG_HOME/lttng-traces/[hostname]/my/path/custom Add the base_path information to the session object in the session daemon, extracted from the network URI, and pass that information to the relay daemon through the create session (2.11) command. It also fixes the use-case: lttng create --snapshot --set-url=net://localhost/my/path/custom lttng enable-event -u -a lttng start [ run app ] lttng snapshot record which is expected to record the snapshot under: $LTTNG_HOME/lttng-traces/[hostname]/my/path/custom/snapshot-[N]-[timestamp] Similar situation for: lttng create --snapshot lttng enable-event -u -a lttng start [ run app ] lttng snapshot record net://localhost/my/path/custom which is expected to record the snapshot under: $LTTNG_HOME/lttng-traces/[hostname]/my/path/custom/snapshot-[N]-[timestamp] Note that specifying the base_path on the snapshot record command overrides the base path specified at create. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Fix: perform a rotation to a null trace chunk on session destruction In order to guarantee the consumption of all data by the time a session's destruction completes, a rotation to a "null" trace chunk is performed as part of a session's destruction. This ensures that a session is only reclaimed when all of its streams (on both the consumers and the relay daemon) have been destroyed. The notion of a "quiet" rotation is introduced in order to re-use the session rotation infrastructure, but without the rotation being visible to external users through either the notification system or a rename of the trace output folder. Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>