some tracepoints not exist in metadata?

some tracepoints not exist in metadata?

[zhenyu.ren via lttng-dev]

[-- Attachment #1.1: Type: text/plain, Size: 579 bytes --]

Hi,
   I find sometimes there are some tracepoints not exist in metadata file(but they are in the list of lttng list -u) and the end result is  they can NOT be logged. I can not always reproduce it. It bothered me for 2 days. 
   The lttng version is 2.7, I know it is not the latest version but there are some reasons I can't update it. So, is this a known bug?  If yes, It will be very appreciated if you can give me any advice about the bug info(I can cherry pick the correspond fix). Otherwise, maybe I have to give up my favoriate Lttng....

Thank you in advance!
zhenyu.ren

[-- Attachment #1.2: Type: text/html, Size: 1133 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] some tracepoints not exist in metadata?

[zhenyu.ren via lttng-dev]

[-- Attachment #1.1: Type: text/plain, Size: 579 bytes --]

Hi,
   I find sometimes there are some tracepoints not exist in metadata file(but they are in the list of lttng list -u) and the end result is  they can NOT be logged. I can not always reproduce it. It bothered me for 2 days. 
   The lttng version is 2.7, I know it is not the latest version but there are some reasons I can't update it. So, is this a known bug?  If yes, It will be very appreciated if you can give me any advice about the bug info(I can cherry pick the correspond fix). Otherwise, maybe I have to give up my favoriate Lttng....

Thank you in advance!
zhenyu.ren

[-- Attachment #1.2: Type: text/html, Size: 1133 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

回复： some tracepoints not exist in metadata?

[zhenyu.ren via lttng-dev]

[-- Attachment #1.1: Type: text/plain, Size: 1036 bytes --]

I'd like to add that both "lttng list -u" and "lttng list $session_name" can get those tracepoints' names... 
------------------------------------------------------------------
发件人：zhenyu.ren via lttng-dev <lttng-dev@lists.lttng.org>
发送时间：2020年7月1日(星期三) 11:05
收件人：lttng-dev <lttng-dev@lists.lttng.org>; mathieu.desnoyers <mathieu.desnoyers@efficios.com>
主　题：[lttng-dev] some tracepoints not exist in metadata?

Hi,
   I find sometimes there are some tracepoints not exist in metadata file(but they are in the list of lttng list -u) and the end result is  they can NOT be logged. I can not always reproduce it. It bothered me for 2 days. 
   The lttng version is 2.7, I know it is not the latest version but there are some reasons I can't update it. So, is this a known bug?  If yes, It will be very appreciated if you can give me any advice about the bug info(I can cherry pick the correspond fix). Otherwise, maybe I have to give up my favoriate Lttng....

Thank you in advance!
zhenyu.ren

[-- Attachment #1.2: Type: text/html, Size: 2728 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] 回复： some tracepoints not exist in metadata?

[zhenyu.ren via lttng-dev]

[-- Attachment #1.1: Type: text/plain, Size: 1036 bytes --]

I'd like to add that both "lttng list -u" and "lttng list $session_name" can get those tracepoints' names... 
------------------------------------------------------------------
发件人：zhenyu.ren via lttng-dev <lttng-dev@lists.lttng.org>
发送时间：2020年7月1日(星期三) 11:05
收件人：lttng-dev <lttng-dev@lists.lttng.org>; mathieu.desnoyers <mathieu.desnoyers@efficios.com>
主　题：[lttng-dev] some tracepoints not exist in metadata?

Hi,
   I find sometimes there are some tracepoints not exist in metadata file(but they are in the list of lttng list -u) and the end result is  they can NOT be logged. I can not always reproduce it. It bothered me for 2 days. 
   The lttng version is 2.7, I know it is not the latest version but there are some reasons I can't update it. So, is this a known bug?  If yes, It will be very appreciated if you can give me any advice about the bug info(I can cherry pick the correspond fix). Otherwise, maybe I have to give up my favoriate Lttng....

Thank you in advance!
zhenyu.ren

[-- Attachment #1.2: Type: text/html, Size: 2728 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

回复： 回复： some tracepoints not exist in metadata?

[zhenyu.ren via lttng-dev]

[-- Attachment #1.1: Type: text/plain, Size: 1637 bytes --]

Ah, I have to say that I use the wildcard in tracepoint name when enable-event to the channel, i.e. ./lttng enable-event -u system_event* -c channel0 -s misc_data. Of course, there are the other tracepoints with wildcard succeed in registring.
------------------------------------------------------------------
发件人：zhenyu.ren via lttng-dev <lttng-dev@lists.lttng.org>
发送时间：2020年7月1日(星期三) 11:44
收件人：lttng-dev <lttng-dev@lists.lttng.org>; mathieu.desnoyers <mathieu.desnoyers@efficios.com>
主　题：[lttng-dev] 回复： some tracepoints not exist in metadata?

I'd like to add that both "lttng list -u" and "lttng list $session_name" can get those tracepoints' names... 
------------------------------------------------------------------
发件人：zhenyu.ren via lttng-dev <lttng-dev@lists.lttng.org>
发送时间：2020年7月1日(星期三) 11:05
收件人：lttng-dev <lttng-dev@lists.lttng.org>; mathieu.desnoyers <mathieu.desnoyers@efficios.com>
主　题：[lttng-dev] some tracepoints not exist in metadata?

Hi,
   I find sometimes there are some tracepoints not exist in metadata file(but they are in the list of lttng list -u) and the end result is  they can NOT be logged. I can not always reproduce it. It bothered me for 2 days. 
   The lttng version is 2.7, I know it is not the latest version but there are some reasons I can't update it. So, is this a known bug?  If yes, It will be very appreciated if you can give me any advice about the bug info(I can cherry pick the correspond fix). Otherwise, maybe I have to give up my favoriate Lttng....

Thank you in advance!
zhenyu.ren

[-- Attachment #1.2: Type: text/html, Size: 4576 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] 回复： 回复： some tracepoints not exist in metadata?

[zhenyu.ren via lttng-dev]

[-- Attachment #1.1: Type: text/plain, Size: 1637 bytes --]

Ah, I have to say that I use the wildcard in tracepoint name when enable-event to the channel, i.e. ./lttng enable-event -u system_event* -c channel0 -s misc_data. Of course, there are the other tracepoints with wildcard succeed in registring.
------------------------------------------------------------------
发件人：zhenyu.ren via lttng-dev <lttng-dev@lists.lttng.org>
发送时间：2020年7月1日(星期三) 11:44
收件人：lttng-dev <lttng-dev@lists.lttng.org>; mathieu.desnoyers <mathieu.desnoyers@efficios.com>
主　题：[lttng-dev] 回复： some tracepoints not exist in metadata?

I'd like to add that both "lttng list -u" and "lttng list $session_name" can get those tracepoints' names... 
------------------------------------------------------------------
发件人：zhenyu.ren via lttng-dev <lttng-dev@lists.lttng.org>
发送时间：2020年7月1日(星期三) 11:05
收件人：lttng-dev <lttng-dev@lists.lttng.org>; mathieu.desnoyers <mathieu.desnoyers@efficios.com>
主　题：[lttng-dev] some tracepoints not exist in metadata?

Hi,
   I find sometimes there are some tracepoints not exist in metadata file(but they are in the list of lttng list -u) and the end result is  they can NOT be logged. I can not always reproduce it. It bothered me for 2 days. 
   The lttng version is 2.7, I know it is not the latest version but there are some reasons I can't update it. So, is this a known bug?  If yes, It will be very appreciated if you can give me any advice about the bug info(I can cherry pick the correspond fix). Otherwise, maybe I have to give up my favoriate Lttng....

Thank you in advance!
zhenyu.ren

[-- Attachment #1.2: Type: text/html, Size: 4576 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: 回复： 回复： some tracepoints not exist in metadata?

[Mathieu Desnoyers via lttng-dev]

[-- Attachment #1.1: Type: text/plain, Size: 2289 bytes --]

Hi, 

Make sure you use single quotes in your shell around wildcards, else the 
shell will try to expand them to files in the current directory, e.g., you need to do: 

lttng enable-event -u 'system_event*' -c channel0 -s misc_data 

This could very well explain why sometimes your events don't get enabled: if the 
wildcard matches files in the current directory. 

Thanks, 

Mathieu 

----- On Jun 30, 2020, at 11:56 PM, zhenyu.ren <zhenyu.ren@aliyun.com> wrote: 

> Ah, I have to say that I use the wildcard in tracepoint name when enable-event
> to the channel, i.e. ./lttng enable-event -u system_event* -c channel0 -s
> misc_data. Of course, there are the other tracepoints with wildcard succeed in
> registring.

>> ------------------------------------------------------------------
>> 发件人：zhenyu.ren via lttng-dev <lttng-dev@lists.lttng.org>
>> 发送时间：2020年7月1日(星期三) 11:44
>> 收件人：lttng-dev <lttng-dev@lists.lttng.org>; mathieu.desnoyers
>> <mathieu.desnoyers@efficios.com>
>> 主 题：[lttng-dev] 回复： some tracepoints not exist in metadata?

>> I'd like to add that both "lttng list -u" and "lttng list $session_name" can get
>> those tracepoints' names...
>> ------------------------------------------------------------------
>> 发件人：zhenyu.ren via lttng-dev <lttng-dev@lists.lttng.org>
>> 发送时间：2020年7月1日(星期三) 11:05
>> 收件人：lttng-dev <lttng-dev@lists.lttng.org>; mathieu.desnoyers
>> <mathieu.desnoyers@efficios.com>
>> 主 题：[lttng-dev] some tracepoints not exist in metadata?

>> Hi,
>> I find sometimes there are some tracepoints not exist in metadata file(but they
>> are in the list of lttng list -u) and the end result is they can NOT be logged.
>> I can not always reproduce it. It bothered me for 2 days.
>> The lttng version is 2.7, I know it is not the latest version but there are some
>> reasons I can't update it. So, is this a known bug? If yes, It will be very
>> appreciated if you can give me any advice about the bug info(I can cherry pick
>> the correspond fix). Otherwise, maybe I have to give up my favoriate Lttng....

>> Thank you in advance!
>> zhenyu.ren

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 

[-- Attachment #1.2: Type: text/html, Size: 5753 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] 回复： 回复： some tracepoints not exist in metadata?

[Mathieu Desnoyers via lttng-dev]

[-- Attachment #1.1: Type: text/plain, Size: 2289 bytes --]

Hi, 

Make sure you use single quotes in your shell around wildcards, else the 
shell will try to expand them to files in the current directory, e.g., you need to do: 

lttng enable-event -u 'system_event*' -c channel0 -s misc_data 

This could very well explain why sometimes your events don't get enabled: if the 
wildcard matches files in the current directory. 

Thanks, 

Mathieu 

----- On Jun 30, 2020, at 11:56 PM, zhenyu.ren <zhenyu.ren@aliyun.com> wrote: 

> Ah, I have to say that I use the wildcard in tracepoint name when enable-event
> to the channel, i.e. ./lttng enable-event -u system_event* -c channel0 -s
> misc_data. Of course, there are the other tracepoints with wildcard succeed in
> registring.

>> ------------------------------------------------------------------
>> 发件人：zhenyu.ren via lttng-dev <lttng-dev@lists.lttng.org>
>> 发送时间：2020年7月1日(星期三) 11:44
>> 收件人：lttng-dev <lttng-dev@lists.lttng.org>; mathieu.desnoyers
>> <mathieu.desnoyers@efficios.com>
>> 主 题：[lttng-dev] 回复： some tracepoints not exist in metadata?

>> I'd like to add that both "lttng list -u" and "lttng list $session_name" can get
>> those tracepoints' names...
>> ------------------------------------------------------------------
>> 发件人：zhenyu.ren via lttng-dev <lttng-dev@lists.lttng.org>
>> 发送时间：2020年7月1日(星期三) 11:05
>> 收件人：lttng-dev <lttng-dev@lists.lttng.org>; mathieu.desnoyers
>> <mathieu.desnoyers@efficios.com>
>> 主 题：[lttng-dev] some tracepoints not exist in metadata?

>> Hi,
>> I find sometimes there are some tracepoints not exist in metadata file(but they
>> are in the list of lttng list -u) and the end result is they can NOT be logged.
>> I can not always reproduce it. It bothered me for 2 days.
>> The lttng version is 2.7, I know it is not the latest version but there are some
>> reasons I can't update it. So, is this a known bug? If yes, It will be very
>> appreciated if you can give me any advice about the bug info(I can cherry pick
>> the correspond fix). Otherwise, maybe I have to give up my favoriate Lttng....

>> Thank you in advance!
>> zhenyu.ren

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 

[-- Attachment #1.2: Type: text/html, Size: 5753 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

回复：回复： 回复： some tracepoints not exist in metadata?

[zhenyu.ren via lttng-dev]

[-- Attachment #1.1: Type: text/plain, Size: 3029 bytes --]

Thanks a lot. I will try single quotes but it may take hours get the result. Yesterday, I enabled the verbose option ,and found the following message "UST app reply event failed. Application died (in add_event_ust_registry() at ust-app.c:5405)" and "UST app notify socket unregister 34 (in ust_app_notify_sock_unregister() at ust-app.c:5562)". In fact ,the socket that Lttng-sessiond send reply to my app return an error with EPIPE. It seems that the pipe breaked.So do you have any hint for that?

Thank you  
------------------------------------------------------------------
发件人：Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
发送时间：2020年7月1日(星期三) 20:07
收件人：zhenyu.ren <zhenyu.ren@aliyun.com>
抄　送：lttng-dev <lttng-dev@lists.lttng.org>
主　题：Re: 回复：[lttng-dev] 回复： some tracepoints not exist in metadata?

Hi,

Make sure you use single quotes in your shell around wildcards, else the
shell will try to expand them to files in the current directory, e.g., you need to do:

lttng enable-event -u 'system_event*' -c channel0 -s misc_data

This could very well explain why sometimes your events don't get enabled: if the
wildcard matches files in the current directory.

Thanks,

Mathieu

----- On Jun 30, 2020, at 11:56 PM, zhenyu.ren <zhenyu.ren@aliyun.com> wrote:

Ah, I have to say that I use the wildcard in tracepoint name when enable-event to the channel, i.e. ./lttng enable-event -u system_event* -c channel0 -s misc_data. Of course, there are the other tracepoints with wildcard succeed in registring.
------------------------------------------------------------------
发件人：zhenyu.ren via lttng-dev <lttng-dev@lists.lttng.org>
发送时间：2020年7月1日(星期三) 11:44
收件人：lttng-dev <lttng-dev@lists.lttng.org>; mathieu.desnoyers <mathieu.desnoyers@efficios.com>
主　题：[lttng-dev] 回复： some tracepoints not exist in metadata?

I'd like to add that both "lttng list -u" and "lttng list $session_name" can get those tracepoints' names... 
------------------------------------------------------------------
发件人：zhenyu.ren via lttng-dev <lttng-dev@lists.lttng.org>
发送时间：2020年7月1日(星期三) 11:05
收件人：lttng-dev <lttng-dev@lists.lttng.org>; mathieu.desnoyers <mathieu.desnoyers@efficios.com>
主　题：[lttng-dev] some tracepoints not exist in metadata?

Hi,
   I find sometimes there are some tracepoints not exist in metadata file(but they are in the list of lttng list -u) and the end result is  they can NOT be logged. I can not always reproduce it. It bothered me for 2 days. 
   The lttng version is 2.7, I know it is not the latest version but there are some reasons I can't update it. So, is this a known bug?  If yes, It will be very appreciated if you can give me any advice about the bug info(I can cherry pick the correspond fix). Otherwise, maybe I have to give up my favoriate Lttng....
Thank you in advance!
zhenyu.ren

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

[-- Attachment #1.2: Type: text/html, Size: 7922 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] 回复：回复： 回复： some tracepoints not exist in metadata?

[zhenyu.ren via lttng-dev]

[-- Attachment #1.1: Type: text/plain, Size: 3029 bytes --]

Thanks a lot. I will try single quotes but it may take hours get the result. Yesterday, I enabled the verbose option ,and found the following message "UST app reply event failed. Application died (in add_event_ust_registry() at ust-app.c:5405)" and "UST app notify socket unregister 34 (in ust_app_notify_sock_unregister() at ust-app.c:5562)". In fact ,the socket that Lttng-sessiond send reply to my app return an error with EPIPE. It seems that the pipe breaked.So do you have any hint for that?

Thank you  
------------------------------------------------------------------
发件人：Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
发送时间：2020年7月1日(星期三) 20:07
收件人：zhenyu.ren <zhenyu.ren@aliyun.com>
抄　送：lttng-dev <lttng-dev@lists.lttng.org>
主　题：Re: 回复：[lttng-dev] 回复： some tracepoints not exist in metadata?

Hi,

Make sure you use single quotes in your shell around wildcards, else the
shell will try to expand them to files in the current directory, e.g., you need to do:

lttng enable-event -u 'system_event*' -c channel0 -s misc_data

This could very well explain why sometimes your events don't get enabled: if the
wildcard matches files in the current directory.

Thanks,

Mathieu

----- On Jun 30, 2020, at 11:56 PM, zhenyu.ren <zhenyu.ren@aliyun.com> wrote:

Ah, I have to say that I use the wildcard in tracepoint name when enable-event to the channel, i.e. ./lttng enable-event -u system_event* -c channel0 -s misc_data. Of course, there are the other tracepoints with wildcard succeed in registring.
------------------------------------------------------------------
发件人：zhenyu.ren via lttng-dev <lttng-dev@lists.lttng.org>
发送时间：2020年7月1日(星期三) 11:44
收件人：lttng-dev <lttng-dev@lists.lttng.org>; mathieu.desnoyers <mathieu.desnoyers@efficios.com>
主　题：[lttng-dev] 回复： some tracepoints not exist in metadata?

I'd like to add that both "lttng list -u" and "lttng list $session_name" can get those tracepoints' names... 
------------------------------------------------------------------
发件人：zhenyu.ren via lttng-dev <lttng-dev@lists.lttng.org>
发送时间：2020年7月1日(星期三) 11:05
收件人：lttng-dev <lttng-dev@lists.lttng.org>; mathieu.desnoyers <mathieu.desnoyers@efficios.com>
主　题：[lttng-dev] some tracepoints not exist in metadata?

Hi,
   I find sometimes there are some tracepoints not exist in metadata file(but they are in the list of lttng list -u) and the end result is  they can NOT be logged. I can not always reproduce it. It bothered me for 2 days. 
   The lttng version is 2.7, I know it is not the latest version but there are some reasons I can't update it. So, is this a known bug?  If yes, It will be very appreciated if you can give me any advice about the bug info(I can cherry pick the correspond fix). Otherwise, maybe I have to give up my favoriate Lttng....
Thank you in advance!
zhenyu.ren

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

[-- Attachment #1.2: Type: text/html, Size: 7922 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: 回复：回复： 回复： some tracepoints not exist in metadata?

[Jonathan Rajotte-Julien via lttng-dev]

On Thu, Jul 02, 2020 at 08:38:57AM +0800, zhenyu.ren via lttng-dev wrote:
> Thanks a lot. I will try single quotes but it may take hours get the result.
> Yesterday, I enabled the verbose option ,and found the following message "UST
> app reply event failed. Application died (in add_event_ust_registry() at
> ust-app.c:5405)" and "UST app notify socket unregister 34 (in
> ust_app_notify_sock_unregister() at ust-app.c:5562)". In fact ,the socket that
> Lttng-sessiond send reply to my app return an error with EPIPE. It seems that
> the pipe breaked.So do you have any hint for that?

From lttng master:
    ret = ustctl_reply_register_event(sock, event_id, ret_code);
    if (ret < 0) {
    	if (ret != -EPIPE && ret != -LTTNG_UST_ERR_EXITING) {
    		ERR("UST app reply event failed with ret %d", ret);
    	} else {
    		DBG3("UST app reply event failed. Application died");
    	}
    	/*
    	 * No need to wipe the create event since the application socket will
    	 * get close on error hence cleaning up everything by itself.
    	 */
    	goto error;
    }

EPIPE ifor this socket is considered as an expected scenario.

This normally indicates a short-lived application or that your application
crashed while lttng-ust and lttng-tools were performing an event registration.
Considering that the path leading to the ustctl_reply_register_event call is
preceded by a call fetching information from the same socket
(ustctl_recv_register_event), I expect this to be a completely normal scenario
unless you provide evidence that this application under tracing was acting
normally and had a long lifetime.

Cheers

Re: [lttng-dev] 回复：回复： 回复： some tracepoints not exist in metadata?

[Jonathan Rajotte-Julien via lttng-dev]

On Thu, Jul 02, 2020 at 08:38:57AM +0800, zhenyu.ren via lttng-dev wrote:
> Thanks a lot. I will try single quotes but it may take hours get the result.
> Yesterday, I enabled the verbose option ,and found the following message "UST
> app reply event failed. Application died (in add_event_ust_registry() at
> ust-app.c:5405)" and "UST app notify socket unregister 34 (in
> ust_app_notify_sock_unregister() at ust-app.c:5562)". In fact ,the socket that
> Lttng-sessiond send reply to my app return an error with EPIPE. It seems that
> the pipe breaked.So do you have any hint for that?

From lttng master:
    ret = ustctl_reply_register_event(sock, event_id, ret_code);
    if (ret < 0) {
    	if (ret != -EPIPE && ret != -LTTNG_UST_ERR_EXITING) {
    		ERR("UST app reply event failed with ret %d", ret);
    	} else {
    		DBG3("UST app reply event failed. Application died");
    	}
    	/*
    	 * No need to wipe the create event since the application socket will
    	 * get close on error hence cleaning up everything by itself.
    	 */
    	goto error;
    }

EPIPE ifor this socket is considered as an expected scenario.

This normally indicates a short-lived application or that your application
crashed while lttng-ust and lttng-tools were performing an event registration.
Considering that the path leading to the ustctl_reply_register_event call is
preceded by a call fetching information from the same socket
(ustctl_recv_register_event), I expect this to be a completely normal scenario
unless you provide evidence that this application under tracing was acting
normally and had a long lifetime.

Cheers
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: 回复：回复： 回复： some tracepoints not exist in metadata?

[Mathieu Desnoyers via lttng-dev]

----- On Jul 2, 2020, at 8:45 AM, Jonathan Rajotte jonathan.rajotte-julien@efficios.com wrote:

> On Thu, Jul 02, 2020 at 08:38:57AM +0800, zhenyu.ren via lttng-dev wrote:
>> Thanks a lot. I will try single quotes but it may take hours get the result.
>> Yesterday, I enabled the verbose option ,and found the following message "UST
>> app reply event failed. Application died (in add_event_ust_registry() at
>> ust-app.c:5405)" and "UST app notify socket unregister 34 (in
>> ust_app_notify_sock_unregister() at ust-app.c:5562)". In fact ,the socket that
>> Lttng-sessiond send reply to my app return an error with EPIPE. It seems that
>> the pipe breaked.So do you have any hint for that?
> 
> From lttng master:
>    ret = ustctl_reply_register_event(sock, event_id, ret_code);
>    if (ret < 0) {
>    	if (ret != -EPIPE && ret != -LTTNG_UST_ERR_EXITING) {
>    		ERR("UST app reply event failed with ret %d", ret);
>    	} else {
>    		DBG3("UST app reply event failed. Application died");
>    	}
>    	/*
>    	 * No need to wipe the create event since the application socket will
>    	 * get close on error hence cleaning up everything by itself.
>    	 */
>    	goto error;
>    }
> 
> EPIPE ifor this socket is considered as an expected scenario.
> 
> This normally indicates a short-lived application or that your application
> crashed while lttng-ust and lttng-tools were performing an event registration.
> Considering that the path leading to the ustctl_reply_register_event call is
> preceded by a call fetching information from the same socket
> (ustctl_recv_register_event), I expect this to be a completely normal scenario
> unless you provide evidence that this application under tracing was acting
> normally and had a long lifetime.

In addition, one thing to consider is that if the application is a daemon
process closing all file descriptors, using fork, clone or daemon, then
helper libraries need to be preloaded with the daemon following instructions
in the man-page lttng-ust(3) under section "Using LTTng-UST with daemons".

Failure to preload those libraries in daemons would trigger the observed
scenario: the application hangs up the UST communication socket
and never reconnects.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: [lttng-dev] 回复：回复： 回复： some tracepoints not exist in metadata?

[Mathieu Desnoyers via lttng-dev]

----- On Jul 2, 2020, at 8:45 AM, Jonathan Rajotte jonathan.rajotte-julien@efficios.com wrote:

> On Thu, Jul 02, 2020 at 08:38:57AM +0800, zhenyu.ren via lttng-dev wrote:
>> Thanks a lot. I will try single quotes but it may take hours get the result.
>> Yesterday, I enabled the verbose option ,and found the following message "UST
>> app reply event failed. Application died (in add_event_ust_registry() at
>> ust-app.c:5405)" and "UST app notify socket unregister 34 (in
>> ust_app_notify_sock_unregister() at ust-app.c:5562)". In fact ,the socket that
>> Lttng-sessiond send reply to my app return an error with EPIPE. It seems that
>> the pipe breaked.So do you have any hint for that?
> 
> From lttng master:
>    ret = ustctl_reply_register_event(sock, event_id, ret_code);
>    if (ret < 0) {
>    	if (ret != -EPIPE && ret != -LTTNG_UST_ERR_EXITING) {
>    		ERR("UST app reply event failed with ret %d", ret);
>    	} else {
>    		DBG3("UST app reply event failed. Application died");
>    	}
>    	/*
>    	 * No need to wipe the create event since the application socket will
>    	 * get close on error hence cleaning up everything by itself.
>    	 */
>    	goto error;
>    }
> 
> EPIPE ifor this socket is considered as an expected scenario.
> 
> This normally indicates a short-lived application or that your application
> crashed while lttng-ust and lttng-tools were performing an event registration.
> Considering that the path leading to the ustctl_reply_register_event call is
> preceded by a call fetching information from the same socket
> (ustctl_recv_register_event), I expect this to be a completely normal scenario
> unless you provide evidence that this application under tracing was acting
> normally and had a long lifetime.

In addition, one thing to consider is that if the application is a daemon
process closing all file descriptors, using fork, clone or daemon, then
helper libraries need to be preloaded with the daemon following instructions
in the man-page lttng-ust(3) under section "Using LTTng-UST with daemons".

Failure to preload those libraries in daemons would trigger the observed
scenario: the application hangs up the UST communication socket
and never reconnects.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev