Java Runtime Environment: openjdk version “17.0.8” 2023-07-18 LTS
openHAB version: 4.0.2
Issue of the topic:
I encountered an annoying behaviour on my system, maybe someone can help me get rid of it:
On my server I use the packages provided on jfrog.io. On Ubuntu every time you update any packages with “apt update && apt upgrade” it then calls “needsrestart” to suggest services that need to be restarted due to updated shared libraries etc. Regardless of what packages are updated on my system, “needrestart” always suggests restarting openhab.service. Today i took some time to check this out and ran “needsrestart -v” after installing an AMD64 microcode update package. In the output i saw this line:
It looks like this is the reason why a restart of the openhab.service is suggested.
As far a i can see I could change the “needsrestart” configuration to ignore those files, but maybe it is an error in the openhab code which leads to keeping this deleted file open. In this case, this should be examined by a developer and I would file an issue on Github.
Any ideas on this how to handle this “the right way” or what’s the cause of this?
A .so file is typically a compiled library. It’s probably listed as opened because you have some add-on which depends on a JNI library to interface with something. As long as that add-on is active that library will be marked as open by openHAB. So I don’t think there is a bug from that part. If that file is indeed deleted, I would expect to need to restart OH so it can load in what ever the new library file happens to be. Without that I would expect OH to crash at some point when it comes time to access that library.
But a big question is why any files are being deleted in that folder in the first place. Files in /var/lib/openhab/tmp should only be messed with when OH is not running in the first place. The upgrade of the openHAB package should stop OH, update the install which includes clearing the cache which deletes the contents of that tmp folder, and then start OH again.
If some other set of steps is happening it’s odd and not standard behavior. But it also means that the needsrestart is correct. If stuff in tmp was deleted while OH was running, OH needs to be restarted.
I just restarted openhab and did an lsof after the logs showed the startup completed:
# lsof -p 509727|grep "/var/lib/openhab/tmp/"|grep DEL
java 509727 openhab DEL REG 253,0 6556917 /var/lib/openhab/tmp/jffi5866463089856923693.so
So it looks like this shared library is opened at startup and then deleted… doesn’t look “normal” to me. I will go and disable all bindings one by one to see where this comes from. Good that the weather forecast announced rain for the next few days .
I needed some time to setup a testing environment to dig deeper into this issue. In the testing environment i restored a backup of my “production” installation to uninstall bindings one by another to see if those deleted shared libraries would vanish. Since searching the internet for “jffi*.so” named shared libraries lead me to this:
i suspected this could be due to some binding related to using external programming interfaces, so i decided to start by uninstalling some automation bindings. (I must admit that i had a few installed that i didn’t really use.) And é voila: After uninstalling the “JRuby Scripting” binding the deleted files were gone!
So my original problem is solved, but this leads me to the question: should i report this somewhere?
The jnr/jffi are, as far as I know, used by JRuby implementation. I come over this library eventually while working on other things, what is notable - ffi is a foreign function interface which allows to call any C library through single layer (libffi). From this point of view it might be valid to reload openhab just to refresh eventual cache on jffi/libffi.
.