From: Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org>
To: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Cc: lttng-dev <lttng-dev@lists.lttng.org>
Subject: Re: 回复:回复: 回复: some tracepoints not exist in metadata?
Date: Thu, 2 Jul 2020 10:03:10 -0400 (EDT) [thread overview]
Message-ID: <445531696.20175.1593698590049.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20200702124541.GF4207@joraj-alpa>
----- 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
WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org>
To: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Cc: lttng-dev <lttng-dev@lists.lttng.org>
Subject: Re: [lttng-dev] 回复:回复: 回复: some tracepoints not exist in metadata?
Date: Thu, 2 Jul 2020 10:03:10 -0400 (EDT) [thread overview]
Message-ID: <445531696.20175.1593698590049.JavaMail.zimbra@efficios.com> (raw)
Message-ID: <20200702140310.i44W8YQRT6khMAERpnwlYyaopsulEI8R1y9xTaJEuA0@z> (raw)
In-Reply-To: <20200702124541.GF4207@joraj-alpa>
----- 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
next prev parent reply other threads:[~2020-07-02 14:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-01 2:48 some tracepoints not exist in metadata? zhenyu.ren via lttng-dev
2020-07-01 2:48 ` [lttng-dev] " zhenyu.ren via lttng-dev
2020-07-01 3:43 ` 回复: " zhenyu.ren via lttng-dev
2020-07-01 3:43 ` [lttng-dev] " zhenyu.ren via lttng-dev
2020-07-01 3:56 ` 回复: " zhenyu.ren via lttng-dev
2020-07-01 3:56 ` [lttng-dev] " zhenyu.ren via lttng-dev
2020-07-01 12:07 ` Mathieu Desnoyers via lttng-dev
2020-07-01 12:07 ` [lttng-dev] " Mathieu Desnoyers via lttng-dev
2020-07-02 0:38 ` 回复:回复: " zhenyu.ren via lttng-dev
2020-07-02 0:38 ` [lttng-dev] " zhenyu.ren via lttng-dev
2020-07-02 12:45 ` Jonathan Rajotte-Julien via lttng-dev
2020-07-02 12:45 ` [lttng-dev] " Jonathan Rajotte-Julien via lttng-dev
2020-07-02 14:03 ` Mathieu Desnoyers via lttng-dev [this message]
2020-07-02 14:03 ` Mathieu Desnoyers via lttng-dev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=445531696.20175.1593698590049.JavaMail.zimbra@efficios.com \
--to=lttng-dev@lists.lttng.org \
--cc=jonathan.rajotte-julien@efficios.com \
--cc=mathieu.desnoyers@efficios.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.