Alexey Serbin has posted comments on this change. ( http://gerrit.cloudera.org:8080/24681 )
Change subject: [dist-test] Fix chrpath ETXTBSY race in dist slaves ...................................................................... Patch Set 3: (5 comments) http://gerrit.cloudera.org:8080/#/c/24681/3//COMMIT_MSG Commit Message: PS3: Thank you for the root cause analysis! I didn't expect this issue since I didn't pay much attention to the shenanigans that dist-test needs to run. With that, should we switch the pre-commit Jenkins job to legacy (non-prebuilt) mode to maintain its own thirdparty copy per workspace? Or maybe you didn't find any other issues besides this one with chrpath? http://gerrit.cloudera.org:8080/#/c/24681/3//COMMIT_MSG@10 PS3, Line 10: open nit: open() call http://gerrit.cloudera.org:8080/#/c/24681/3//COMMIT_MSG@16 PS3, Line 16: lvm-symbolizer BTW, maybe we should avoid calling chrpath for llvm-symbolizer (and maybe for many other 3rd-party components, if not all): it's RPATH is relative to the binary itself, so no need to update RPATH there: $ chrpath llvm-symbolizer llvm-symbolizer: RPATH=$ORIGIN/../lib http://gerrit.cloudera.org:8080/#/c/24681/3//COMMIT_MSG@30 PS3, Line 30: This eliminates : the ETXTBSY failure for all build types without requiring any : coordination between concurrent tasks. But will it work if different dist-test sessions have different RPATH settings, or RPATH is always the same for all dist-test runs? If dist-test have different RPATH for different runs, using same settings for shared binaries (such as llvm-symbolizer) isn't going to work if there is a race that doesn't end up with EXTBSY, but there are two different dist-test sessions using the same binary, right? http://gerrit.cloudera.org:8080/#/c/24681/3/build-support/run_dist_test.py File build-support/run_dist_test.py: http://gerrit.cloudera.org:8080/#/c/24681/3/build-support/run_dist_test.py@110 PS3, Line 110: Work around this by writing to a temporary copy and : # atomically replacing the original via os.rename(), which only updates : # the directory entry and leaves any in-flight execution of the original : # inode undisturbed. A process-unique suffix avoids a collision when two : # tasks concurrently fall back for the same binary. Would it be cleaner to do this unconditionally before trying to run "chrpath -r" on the original binary? In other words, always copy the binary into a temporary file, then run "chrpath -r" or whatever shenanigans on the guaranteed unique file object, and then atomically rename the temporary back? -- To view, visit http://gerrit.cloudera.org:8080/24681 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I80cdc5b903f5ed0865ec5a92f905a46719f7e316 Gerrit-Change-Number: 24681 Gerrit-PatchSet: 3 Gerrit-Owner: Ashwani Raina <[email protected]> Gerrit-Reviewer: Abhishek Chennaka <[email protected]> Gerrit-Reviewer: Alexey Serbin <[email protected]> Gerrit-Reviewer: Ashwani Raina <[email protected]> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Reviewer: Zoltan Martonka <[email protected]> Gerrit-Comment-Date: Fri, 14 Aug 2026 05:49:28 +0000 Gerrit-HasComments: Yes
