I'm trying to deploy an application using zstd-jni on a system where /tmp is mounted noexec.
zstd-jni initialization fails with the following error:
java.lang.ExceptionInInitializerError: Exception java.lang.UnsatisfiedLinkError: /tmp/libzstd-jni-1.5.5-111543552353015917660.so: /tmp/libzstd-jni-1.5.5-111543552353015917660.so: failed to map segment from shared object
I could override java.io.tmpdir but that affects the rest of the application. The other temporary files are no longer noexec.
I could use the ZstdNativePath system property, but that complexifies the deployment scenario, the proper native library for the architecture needs to be extracted and kept in sync with the java library version.
I could call Native.load(File tempFolder) while initializing the application to override the path. That's weird, because my application has nothing to do with Zstd, I just happen to have zstd-jni on the classpath mostly by accident. It's a transitive runtime dependency of kafka-clients. Netty picks it up and tries to use it.
It would be nice to have a new system property to override the path where zstd-jni extracts the native library. That way, the logic for extracting the native library remains in zstd-jni. Only the deployments where /tmp is mounted as noexec are affected and can set the property to a path where the library can be loaded.
I'm trying to deploy an application using
zstd-jni
on a system where/tmp
is mountednoexec
.zstd-jni
initialization fails with the following error:I could override
java.io.tmpdir
but that affects the rest of the application. The other temporary files are no longernoexec
.I could use the
ZstdNativePath
system property, but that complexifies the deployment scenario, the proper native library for the architecture needs to be extracted and kept in sync with the java library version.I could call
Native.load(File tempFolder)
while initializing the application to override the path. That's weird, because my application has nothing to do with Zstd, I just happen to havezstd-jni
on the classpath mostly by accident. It's a transitive runtime dependency ofkafka-clients
. Netty picks it up and tries to use it.It would be nice to have a new system property to override the path where
zstd-jni
extracts the native library. That way, the logic for extracting the native library remains inzstd-jni
. Only the deployments where/tmp
is mounted asnoexec
are affected and can set the property to a path where the library can be loaded.