[
https://issues.apache.org/jira/browse/KUDU-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18108059#comment-18108059
]
ASF subversion and git services commented on KUDU-3788:
-------------------------------------------------------
Commit 09f1e1482d01fd73ee2b0b642c00ac61b5b39dc1 in kudu's branch
refs/heads/master from Ashwani Raina
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=09f1e1482 ]
[dist-test] Fix chrpath ETXTBSY race in dist slaves
chrpath rewrites ELF RPATH/RUNPATH entries in-place using an open() with
write permission. Linux returns ETXTBSY for that open() when the target
inode is currently being executed by some process.
Since KUDU-3788 all dist-test slaves share a single prebuilt thirdparty
installation. fixup_rpaths() is called at the start of every task
regardless of build type and walks the entire thirdparty tree. If an
ASAN or TSAN task on the same slave has already spawned llvm-symbolizer,
any subsequent task calling chrpath on that binary will fail with
ETXTBSY. The failure surfaces in whichever task runs fixup_rpaths()
concurrently, which can be a DEBUG/RELEASE task even though the cause is
always an ASAN/TSAN task holding llvm-symbolizer open for execution.
Multiple such errors ('open: Text file busy') were seen in dist-test
runs, all pointing to chrpath failing to rewrite llvm-symbolizer.
The rewritten RPATH is what makes a lock-free fix possible: fix_rpath()
rewrites each thirdparty component to '$ORIGIN/<relative path to
thirdparty>'. That value is anchored at $ORIGIN and is a pure function
of the binary's position within the extracted tree, so it does not
depend on the absolute extraction path, the build type, or the session.
Any two tasks that share a binary therefore compute the identical target
RPATH. This yields two properties that together remove the race without
any coordination:
- Idempotent short-circuit: if the computed RPATH already equals the
current one, fix_rpath() returns without opening the inode for
writing. The first task to relativize a shared binary makes it a
no-op for every later task, so chrpath is never invoked on a binary
another task is already executing (e.g. llvm-symbolizer, which ships
with '$ORIGIN/../lib' and is skipped outright). Since all sharers
target the same value, even a concurrent rewrite writes identical
bytes.
- ETXTBSY fallback: for the first rewrite of a binary that is genuinely
busy, attempt the in-place chrpath and, only if it fails, classify
the failure by probing the kernel errno directly (chrpath reports
ETXTBSY via the locale-dependent strerror text "Text file busy", so
matching on errno is robust). On ETXTBSY, copy the binary to a
sibling temp file, rewrite the RPATH on the copy, and atomically
replace the original with os.rename(). os.rename() only updates the
directory entry, so any process already executing the original inode
continues undisturbed. Any non-ETXTBSY failure is propagated.
This eliminates the ETXTBSY failure for all build types without
requiring any coordination between concurrent tasks.
Change-Id: I80cdc5b903f5ed0865ec5a92f905a46719f7e316
Reviewed-on: http://gerrit.cloudera.org:8080/24681
Reviewed-by: Alexey Serbin <[email protected]>
Reviewed-by: Abhishek Chennaka <[email protected]>
Reviewed-by: Zoltan Martonka <[email protected]>
Tested-by: Ashwani Raina <[email protected]>
> Allow fethcing and using pre-built 3rd-party components when building Kudu
> --------------------------------------------------------------------------
>
> Key: KUDU-3788
> URL: https://issues.apache.org/jira/browse/KUDU-3788
> Project: Kudu
> Issue Type: Improvement
> Reporter: Alexey Serbin
> Assignee: Alexey Serbin
> Priority: Major
> Fix For: 1.19.0
>
>
> It would be nice to allow to fetch and use pre-built 3rd-party components
> when building Kudu. Each of the 3rd-party components should be checked
> against a presence of pre-built version that matches the machine architecture
> and OS, and the matching rule should compare at least the following
> attributes:
> * Component name (e.g., gflags)
> * Component version (minor, major, patch, or just source hash if no semantic
> versioning is available)
> * The machine's CPU architecture that binaries/libraries are built for (e.g.,
> x86_64, arm64)
> * OS name or flavor/distro name if applicable (e.g., macOS, Ubuntu, Debian,
> RHEL, etc.)
> * OS version: major, minor (e.g., 9.1 for RHEL, 24.04 for Ubuntu, 15.7 for
> macOS, etc.)
> * The toolchain that the bits are built with: compiler name, major and minor
> versions, and the standard C++ library flavor where applicable (e.g.,
> gcc-10.5-libstdc++, clang-15.0)
> * Sanitizer option: TSAN if built with tread sanitizer support, or none if a
> regular build
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
