jojochuang commented on code in PR #11636:
URL: https://github.com/apache/ozone/pull/11636#discussion_r4345362336
##########
hadoop-hdds/rocks-native/src/main/java/org/apache/hadoop/hdds/utils/NativeLibraryLoader.java:
##########
@@ -165,13 +164,13 @@ private Pair<Optional<File>, List<File>>
copyResourceFromJarToTemp(final String
return Pair.of(Optional.empty(), null);
}
- final String nativeLibDir =
- Objects.nonNull(getSystemProperty(NATIVE_LIB_TMP_DIR)) ?
- getSystemProperty(NATIVE_LIB_TMP_DIR) : "";
- final File dir = new File(nativeLibDir).getAbsoluteFile();
+ final String nativeLibDir = getSystemProperty(NATIVE_LIB_TMP_DIR);
- // create a temporary dir to copy the library to
- final Path tempPath = Files.createTempDirectory(dir.toPath(),
libraryName);
+ // create a temporary dir to copy the library to, under java.io.tmpdir
unless NATIVE_LIB_TMP_DIR is set,
+ // since the working directory may not be writable.
+ final Path tempPath = nativeLibDir == null || nativeLibDir.isEmpty()
+ ? Files.createTempDirectory(libraryName)
+ : Files.createTempDirectory(new
File(nativeLibDir).getAbsoluteFile().toPath(), libraryName);
Review Comment:
`java.io.tmpdir` is typically `/tmp` on Linux. Deployments that follow a
hardening policy of mounting `/tmp` with `noexec` can create and write files
there, but Linux rejects the executable mappings needed by `System.load()`;
changing file permissions does not resolve that mount restriction.
With `native.lib.tmp.dir` unset or empty, this changes extraction from the
working directory to JVM temp. A previously working installation can therefore
lose native-library loading after an upgrade if its working directory permits
executable mappings but JVM temp does not. This is relevant when RocksDB itself
is already loaded through its installed-library path or
`ROCKSDB_SHAREDLIB_DIR`, while the Ozone tools library is extracted from the
JAR.
The reviewed loader catches the failure and returns `false`, so I have not
established a whole-service startup failure from this path. The confirmed
consequences are fallback to full snapshot diff, loss of native SST pruning,
and inability to perform snapshot defragmentation.
Could we address this upgrade case and document that affected deployments
must provide a suitable writable directory permitting executable mappings
through the JVM property `-Dnative.lib.tmp.dir=/path/to/native-temp` (or
configure `java.io.tmpdir` appropriately)?
Generated-by: Codex (GPT-6)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
