/tmp filesystem filling with artifacts

[LFrank2021]

Hi,
I think I saw a similar discussion somewhere.
But I just ran in a /-FS full (which includes /tmp :( )
I found several libsignal(\d+) directories with libsignal_jni_amd64.so inside it.
As well as sqlite-x-y-z*libsqlitejdbc.[so|lck] files.
I assume these come from the signal-cli.
Why are they left on disk?
What can I change to get them cleaned up successfully?

Currently I am using

• libsignal_jni.so.0.86.1
• signal-cli-0.13.22
  both self compiled.

Best regards
Frank

[xcpn]

I assume you built the native ELF binary?

At least for the native binary, it should be extracting the library during runtime and then deleting it after it's done.

I built the native binary for ARM64 yesterday (v0.13.24), and with just a little bit of testing I did not observe this behavior occurring.

[xcpn]

The native binary needs GraalVM 21, not 25. After you clone the repository, you can check the build.gradle.kts file to determine the version. Here's the file for v0.13.24. Also why are you trying to build v0.13.22, it's 3 months old.

The deprecation option warnings you got are not present in my output, here is how mine looks.

To honour the JVM settings for this build a single-use Daemon process will be forked. For more on this, please refer to https://docs.gradle.org/9.3.0/userguide/gradle_daemon.html#sec:disabling_the_daemon in the Gradle documentation.
Daemon will be stopped at the end of the build 

> Task :generateResourcesConfigFile
[native-image-plugin] Resources configuration written into /home/te/signalcli-build/signal-cli/build/native/generated/generateResourcesConfigFile/resource-config.json

> Task :nativeCompile
[native-image-plugin] GraalVM Toolchain detection is disabled
[native-image-plugin] GraalVM location read from environment variable: GRAALVM_HOME
[native-image-plugin] Native Image executable path: /home/te/.sdkman/candidates/java/21.0.2-graalce/lib/svm/bin/native-image
========================================================================================================================
GraalVM Native Image: Generating 'signal-cli' (executable)...
========================================================================================================================
For detailed information and explanations on the build output, visit:
https://github.com/oracle/graal/blob/master/docs/reference-manual/native-image/BuildOutput.md
------------------------------------------------------------------------------------------------------------------------
The URL protocol jar is not tested and might not work as expected.
Supported URL protocols enabled by default: file,resource. Supported URL protocols available on demand: http,https.
[1/8] Initializing...                                                                                   (53.7s @ 0.17GB)
 Java version: 21.0.2+13, vendor version: GraalVM CE 21.0.2+13.1
 Graal compiler: optimization level: 2, target machine: compatibility
 C compiler: gcc (linux, x86_64, 10.2.1)
 Garbage collector: Serial GC (max heap size: 80% of RAM)
 3 user-specific feature(s):
 - com.oracle.svm.thirdparty.gson.GsonFeature
 - okhttp3.internal.graal.OkHttpFeature
 - org.sqlite.nativeimage.SqliteJdbcFeature
------------------------------------------------------------------------------------------------------------------------
Build resources:
 - 5.86GB of memory (75.6% of 7.76GB system memory, determined at start)
 - 2 thread(s) (100.0% of 2 available processor(s), determined at start)
[2/8] Performing analysis...  [*****]                                                                  (621.8s @ 1.73GB)
   19,927 reachable types   (90.7% of   21,971 total)
   31,677 reachable fields  (67.6% of   46,874 total)
   96,089 reachable methods (61.8% of  155,372 total)
    5,912 types, 1,601 fields, and 5,977 methods registered for reflection
      143 types,    77 fields, and   152 methods registered for JNI access
        4 native libraries: dl, pthread, rt, z
[3/8] Building universe...                                                                              (76.9s @ 2.46GB)
[4/8] Parsing methods...      [*******]                                                                 (57.0s @ 2.27GB)
[5/8] Inlining methods...     [***]                                                                     (34.0s @ 1.77GB)
[6/8] Compiling methods...    [*********************]                                                  (453.6s @ 2.74GB)
[7/8] Layouting methods...    [********]                                                                (61.3s @ 2.50GB)
[8/8] Creating image...       [*********]                                                               (81.2s @ 2.74GB)
  47.26MB (18.38%) for code area:    61,410 compilation units
 206.34MB (80.23%) for image heap:  473,785 objects and 691 resources
   3.58MB ( 1.39%) for other data
 257.18MB in total
------------------------------------------------------------------------------------------------------------------------
Top 10 origins of code area:                                Top 10 object types in image heap:
  13.14MB java.base                                          156.17MB byte[] for embedded resources
   5.42MB bcprov-jdk18on-1.83.jar                             14.17MB byte[] for code metadata
   4.56MB signal-service-java-2.15.3_unofficial_137.jar        8.21MB byte[] for java.lang.String
   4.14MB kotlin-reflect-2.1.0.jar                             4.95MB java.lang.Class
   3.71MB java.xml                                             4.53MB java.lang.String
   2.23MB libsignal-cli-0.13.24.jar                            4.40MB char[]
   2.08MB jackson-databind-2.20.1.jar                          1.67MB com.oracle.svm.core.hub.DynamicHubCompanion
   1.55MB signal-cli-0.13.24.jar                               1.61MB byte[] for reflection metadata
   1.44MB svm.jar (Native Image)                               1.02MB byte[] for general heap data
 802.76kB logback-core-1.5.25.jar                            940.75kB java.lang.String[]
   7.77MB for 49 more packages                                 8.70MB for 4220 more object types
------------------------------------------------------------------------------------------------------------------------
Recommendations:
 INIT: Adopt '--strict-image-heap' to prepare for the next GraalVM release.
 HEAP: Set max heap for improved and more predictable memory usage.
------------------------------------------------------------------------------------------------------------------------
                      217.3s (15.0% of total time) in 162 GCs | Peak RSS: 4.72GB | CPU load: 1.76
------------------------------------------------------------------------------------------------------------------------
Produced artifacts:
 /home/te/signalcli-build/signal-cli/build/native/nativeCompile/signal-cli (executable)
========================================================================================================================
Finished generating 'signal-cli' in 24m 6s.
[native-image-plugin] Native Image written to: /home/te/signalcli-build/signal-cli/build/native/nativeCompile

BUILD SUCCESSFUL in 26m 10s
14 actionable tasks: 10 executed, 4 up-to-date
Consider enabling configuration cache to speed up this build: https://docs.gradle.org/9.3.0/userguide/configuration_cache_enabling.html

It should look similar to this and not identical. Here is the command I run in my bash script just for reference. Of course yours doesn't need to look exactly like that, it depends on your setup.

./gradlew --no-daemon -Dorg.gradle.internal.launcher.welcomeMessageEnabled=false -Dorg.gradle.java.home="$JAVA_HOME" clean nativeCompile

Does the native version still need the libsignal-cli shared library?

You mean the libsignal-client library? You include it similar to this. The binary extracts it during runtime and deletes it on exit.

Upon generating the binary and executing it, you should get no warning at all. you can just run ./signal-cli register and see if it works. This command does use the library and it should be enough to debug if there are any issues.

te@DEBTE02:~/signalcli-build/v0.13.24$ ./signal-cli register
No local users found, you first need to register or link an account
te@DEBTE02:~/signalcli-build/v0.13.24$ ./signal-cli --version
signal-cli 0.13.24

[LFrank2021]

Thanks for the reminder, that v21 is needed and the information, where to check it.
Covering the libsignal-client library:
For the past years, I put the new compile in the java.library.path.
I did nothing special for the native version.
With the next version that will require a newer libsignal-client library, do I keep putting it in the java.library.path or do I include it with the native compile in some other way?
Reading the link you provided, as I understand it, I do indeed compile the libsignal-client first and then provide it to the native build.

-Plibsignal_client_path="/PATH/TO/libsignal-client/java/client/build/libs/libsignal-client-a.bc.d.jar"

For my current compile, I assume it is found because it is part of my gradle cache?

/opt/signal-cli-0.13.22/lib/libsignal-client-0.86.1.jar
/root/.gradle/caches/modules-2/files-2.1/org.signal/libsignal-client
/root/.gradle/caches/modules-2/files-2.1/org.signal/libsignal-client/0.86.1/3151a8eef1f7c0440dfe40597c9b57ae85b971cc/libsignal-client-0.86.1.jar
/root/.gradle/caches/modules-2/metadata-2.107/descriptors/org.signal/libsignal-client

Could you help me understand this a bit more.
As for: Why I did recompile 0.13.22?
a) because it is what I am currently using
b) because all resources are already there
c) to just start understanding if this really helps my problem

As stated above, even the JVM compile should remove those artifacts on a clean exit.
As I am seeing these artifacts, I must have some unclean exits, which I am not aware of.
The native compile yields a performance benefit, but does it prevent those artifacts on clean & unclean exits as well?
If not, then it is just the performance benefit I have to decide upon, to change my compile.
I hope this makes sense.

[xcpn]

Have a lot of work these days and had no time to reply.

The latest version released yesterday introduced some new changes and I now need to make sure everything works correctly with my script. Let me figure everything out so I can make sure the steps regarding your questions haven't been changed, and I'll answer everything.

[xcpn]

Thanks for the reminder, that v21 is needed and the information

The native build now requires v25.

With the next version that will require a newer libsignal-client library, do I keep putting it in the java.library.path or do I include it with the native compile in some other way?

What I do is replace the file (Option 2).

1. Run ./gradlew installDist, which forces Gradle to resolve and download all dependencies using the build.gradle.kts file (downloads the libsignal-client.jar file).
2. Run ./build_jni.sh desktop which generates the native JNI library.
3. Find the JAR file in Gradle cache.
4. Patch that JAR file by replacing the existing JNI (.so file) with your generated one from step 2.
5. Run the command I shared in the previous reply (basically ./gradlew nativeCompile) to compile the native binary.

Since this logic replaces the .so file from the Gradle cache, the last command will pickup the cached JAR and include it during compilation. No need to give a path. This is more or less the logic I use in my bash script, it's not the only way to go about it.

The native compile yields a performance benefit, but does it prevent those artifacts on clean & unclean exits as well?

The native binary gives much better performance overall, and less RAM heavy if running it as a service and not a one-shot execution. Both the native binary and JVM should clean all artifacts upon exit. It's not the one or the other. If either of them has an unclean exit, they won't be able to perform cleanup of course. If you kill the program before it exits, how would it go about cleaning up!

Ultimately you decide what benefits you the most. Personally I want to only carry a single file that I can execute without the need of installed Java. I always run it in either Debian (AMD64) or a Raspberry Pi (ARM64), so it's predictable and will always work. The speed difference between JVM and Native is huge on my systems.

[xcpn]

Pinging you @LFrank2021 because I took a while to reply, in case you didn't see it. If you want me to see a reply soon enough tag me when replying.