Hi,
This is a stable release announcement for the LTTng-UST project. LTTng-UST
is a tracer for Linux user-space applications. The respective versions are
2.13.2 and 2.12.4.
The most important change introduced in these releases is the implementation
of a LTTng-UST Log4j 2.x log appender. Note that in the context of
CVE-2021-45046 [2], LTTng-UST per-se is not affected because it does not
use Log4j for its own logging, but rather implements a log appender (a log
"sink").
Here are the noteworthy changes:
In both 2.13.2 and 2.12.4:
* Add a Log4j 2.x Java agent
Before those releases, LTTng-UST only implemented a Log4j 1.x appender.
Considering that Log4j 1.x has been unmaintained since 2015 [1], and that
a range of Log4j 2.x versions are affected by the critical vulnerability
CVE-2021-45046, allowing Log4j users which use LTTng-UST as a log appender
to upgrade from Log4j 1.x to an up-to-date 2.x is very much relevant,
thus explaining why this new feature is introduced in LTTng-UST stable
releases.
This adds a new agent to the LTTng-UST Java agents suite supporting the
Log4j 2.x logging backend.
This backport differs from the master branch for the
'--enable-java-agent-all' option won't select this new agent since we
wanted to avoid introducing a new dependency in existing configurations.
The name of the new agent jar file is "lttng-ust-agent-log4j2.jar".
It will be installed in the arch-agnostic "$prefix/share/java" path
e.g: "/usr/share/java".
It uses the same jni library "liblttng-ust-log4j-jni.so" as the Log4j 1.x agent.
The agent was designed as a mostly drop-in replacement for applications
upgrading from Log4j 1.x to 2.x. It requires no modification to the
tracing configuration as it uses the same domain "-l / LOG4J" and the
loglevels integer representations are converted to the Log4j 1.x values
(excluding custom loglevels).
* Fix: concurrent exec(2) file descriptor leak
If exec(2) is executed by the application concurrently with LTTng-UST
listener threads between the creation of a file descriptor with
socket(2), recvmsg(2), or pipe(2) and call to fcntl(3) FD_CLOEXEC, those
file descriptors will stay open after the exec, which is not intended.
As a consequence, shared memory files for ring buffers can stay present
on the file system for long-running traced processes.
Rather than fcntl(2) FD_CLOEXEC to make sure the file descriptors are
closed on exec immediately upon their creation.
Noteworthy specifically in 2.13.2:
* Fix: sample discarded events count before reserve
Sampling the discarded events count in the buffer_end callback is done
out of order, and may therefore include increments performed by following
events (in following packets) if the thread doing the end-of-packet
event write is preempted for a long time.
Sampling the event discarded counts before reserving space for the last
event in a packet, and keeping this as part of the private ring buffer
context, should fix this race.
This fix is only part of the 2.13 stable branch and not backported to
2.12 because the lib ring buffer code used to implement this fix did not
exist in 2.12. Given that the impact of this bug is only imprecision of
discarded event reporting in corner-case scenarios (small impact, rare
occurrence), the complexity of implementing this fix in 2.12 is not justified.
The effect of this issue is that the lttng-tools
tests/regression/tools/streaming/test_high_throughput_limits test is flaky.
Feedback is welcome!
Thanks,
Mathieu
[1] https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
[2] https://www.cve.org/CVERecord?id=CVE-2021-45046
Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com