During the 2.13 development cycle, the compatibility pthread_setname_np
compatibility layer was fixed (see
0db3d6ee). Unfortunately, this had a
detrimental effect.
Upon the registration of an application to the session daemon, its name
is sent as part of the 'struct lttng_ust_ctl_reg_msg' registration
message. The application name is sampled using lttng_pthread_getname_np
during the preparation of the message.
However, when the listener thread is launched, its name is changed
early-on to add a '-ust' suffix (see
01f0e40c). This suffixed name is
sampled and sent to the session daemon. Since, until recently, the
pthread_setname_np had no effect on most configurations, this had no
consequence.
I noticed that this has a ripple-effect in the generation of some
path names. For instance, in per-pid mode, snapshots end-up with the
following hierarchy:
/home/jgalar/lttng-traces
└── Mercury
└── florence_jacques-
20210514-162630
└── snapshot-0-
20210514-162726-1
└── ust
└── pid
└── hello-ust-332607-
20210514-162538
├── lol_0
├── lol_1
├── lol_10
├── lol_11
├── lol_2
├── lol_3
├── lol_4
├── lol_5
├── lol_6
├── lol_7
├── lol_8
├── lol_9
└── metadata
Notice how the 'hello' application presents itself with the '-ust'
prefix. For such a short application name, it doesn't really matter
much beyond repeating the 'ust' unnecessarily. However, longer
application names quickly become less readable as we lose four of
the 16 precious allowed characters for a process name.
The procname sampled during the execution of the constructors is
reused. My understanding is that the procname stored in the sock_info
is already used for the 'procname' context.
The resulting hierarchy becomes:
/home/jgalar/lttng-traces
└── Mercury
└── sylvie_rouillard-
20210514-193524
└── snapshot-0-
20210514-193553-0
└── ust
└── pid
└── hello-466576-
20210514-193514
├── lol_0
├── lol_1
├── lol_10
├── lol_11
├── lol_2
├── lol_3
├── lol_4
├── lol_5
├── lol_6
├── lol_7
├── lol_8
├── lol_9
└── metadata
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ibd6f4763c96ea5fb680f55e5cc3d250baca175b0
uint32_t uint16_t_alignment,
uint32_t uint32_t_alignment,
uint32_t uint64_t_alignment,
- uint32_t long_alignment)
+ uint32_t long_alignment,
+ const char *procname)
{
ssize_t len;
struct lttng_ust_ctl_reg_msg reg_msg;
reg_msg.uint64_t_alignment = uint64_t_alignment;
reg_msg.long_alignment = long_alignment;
reg_msg.socket_type = type;
- lttng_pthread_getname_np(reg_msg.name, LTTNG_UST_ABI_PROCNAME_LEN);
+ memset(reg_msg.name, 0, sizeof(reg_msg.name));
+ strncpy(reg_msg.name, procname, sizeof(reg_msg.name) - 1);
memset(reg_msg.padding, 0, sizeof(reg_msg.padding));
len = ustcomm_send_unix_sock(sock, ®_msg, sizeof(reg_msg));
uint32_t uint16_t_alignment,
uint32_t uint32_t_alignment,
uint32_t uint64_t_alignment,
- uint32_t long_alignment)
+ uint32_t long_alignment,
+ const char *procname)
__attribute__((visibility("hidden")));
/*
}
static
-int register_to_sessiond(int socket, enum lttng_ust_ctl_socket_type type)
+int register_to_sessiond(int socket, enum lttng_ust_ctl_socket_type type,
+ const char *procname)
{
return ustcomm_send_reg_msg(socket,
type,
lttng_ust_rb_alignof(uint16_t) * CHAR_BIT,
lttng_ust_rb_alignof(uint32_t) * CHAR_BIT,
lttng_ust_rb_alignof(uint64_t) * CHAR_BIT,
- lttng_ust_rb_alignof(unsigned long) * CHAR_BIT);
+ lttng_ust_rb_alignof(unsigned long) * CHAR_BIT,
+ procname);
}
static
sock_info->root_handle = ret;
}
- ret = register_to_sessiond(sock_info->socket, LTTNG_UST_CTL_SOCKET_CMD);
+ ret = register_to_sessiond(sock_info->socket, LTTNG_UST_CTL_SOCKET_CMD,
+ sock_info->procname);
if (ret < 0) {
ERR("Error registering to %s ust cmd socket",
sock_info->name);
}
ret = register_to_sessiond(sock_info->notify_socket,
- LTTNG_UST_CTL_SOCKET_NOTIFY);
+ LTTNG_UST_CTL_SOCKET_NOTIFY, sock_info->procname);
if (ret < 0) {
ERR("Error registering to %s ust notify socket",
sock_info->name);