[lttng-dev] [barectf] How to ensure that last events before a crash get recorded

RADERMACHER Ansgar Ansgar.RADERMACHER at cea.fr
Fri Mar 5 07:27:53 EST 2021


Hi Philippe,

thanks for your response. The reason not to use LTTng is simple: while I develop on Linux, our client is chiefly using Windows with the mingw environment.

Best regards

Ansgar

________________________________
From: P
hilippe Proulx [eeppeliteloop at gmail.com]
Sent: Friday, March 05, 2021 13:11
To: RADERMACHER Ansgar
Cc: lttng-dev at lists.lttng.org
Subject: Re: [lttng-dev] [barectf] How to ensure that last events before a crash get recorded

On Thu, Mar 4, 2021 at 10:28 RADERMACHER Ansgar via lttng-dev <lttng-dev at lists.lttng.org<mailto:lttng-dev at lists.lttng.org>> wrote:
Hi,

when doing tracing with barectf, the trace elements are written into a buffer first and only written when the buffer is full - or if the function barectf_platform_fs_fini gets called.
In case of a crash, it's therefore possible to loose some events. What is the best option to prevent this issue? I've used signal handlers that call the function barectf_platform_fs_fini. This seems to work well with Linux, but is not portable. When using the provided sample platform, there is also the option to reduce the buffer size, but this is not ideal, as trace events that are too big for the buffer are not written.

First question: why are you using barectf on Linux vs LTTng?

LTTng supports writing the sub-buffers to NVRAM and, if the system crashes, convert those sub-buffers to a CTF trace with the lttng-crash utility. See <
https://lttng.org/docs/v2.12/#doc-persistent-memory-file-systems>.

With NVRAM, you could do this with barectf with a corresponding platform using it. It's always up to the platform author to decide where buffers are and where complete packets go; it's not a feature of barectf as such.

Hope it helps,

Phil


Best regards

Ansgar


_______________________________________________
lttng-dev mailing list
lttng-dev at lists.lttng.org<mailto:lttng-dev at lists.lttng.org>
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Philippe Proulx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20210305/e6bf651f/attachment.htm>


More information about the lttng-dev mailing list