erik@MinipcLG2:~$ sudo apt update
Geraakt:1 https://packages.microsoft.com/repos/code stable InRelease
Geraakt:2 http://archive.ubuntu.com/ubuntu noble InRelease
Geraakt:3 http://security.ubuntu.com/ubuntu noble-security InRelease
Genegeerd:4 http://packages.linuxmint.com xia InRelease
Geraakt:5 https://repos.azul.com/zulu/deb stable InRelease
Geraakt:6 http://archive.ubuntu.com/ubuntu noble-updates InRelease
Geraakt:7 http://packages.linuxmint.com xia Release
Geraakt:8 http://archive.ubuntu.com/ubuntu noble-backports InRelease
Geraakt:9 https://openhab.jfrog.io/artifactory/openhab-linuxpkg stable InReleasePakketlijsten worden ingelezen... Klaar
Boom van vereisten wordt opgebouwd... Klaar
De statusinformatie wordt gelezen... Klaar
Alle pakketten zijn up-to-date.
erik@MinipcLG2:~$ sudo apt upgrade -y
Pakketlijsten worden ingelezen... Klaar
Boom van vereisten wordt opgebouwd... Klaar
De statusinformatie wordt gelezen... Klaar
Opwaardering wordt doorgerekend... Klaar
0 opgewaardeerd, 0 nieuw geïnstalleerd, 0 te verwijderen en 0 niet opgewaardeerd.
erik@MinipcLG2:~$ sudo needrestart
Scanning processes...
Scanning candidates...
Scanning processor microcode...
Scanning linux images...
Running kernel seems to be up-to-date.
The processor microcode seems to be up-to-date.
Restarting services...
systemctl restart openhab.service
No containers need to be restarted.
No user sessions are running outdated binaries.
No VM guests are running outdated hypervisor (qemu) binaries on this host.
erik@MinipcLG2:~$
That doesn’t seem logical?
I only noticed this as from OH5.0.1, but @glen_mnoticed it earlier. Of course the symptom can be suppressed by adding OH to an “override” list, but maybe there’s something wrong with how OH presents itself? Why does needrestart think it needs to be restarted?
Probably because some library that OH (or more likely Java) depends on have been updated. The new version of the library will not be used until the dependent application is restarted. I usually disable restarting OH on these prompts, and do it when I have the time, since I want to be ready in case something doesn’t initialize correctly (but that rarely happens).
Just ran sudo needrestart -v on my system, and noticed this regarding OH:
[main] #2003246 uses deleted /var/lib/openhab/tmp/jffi18380869826989340677.so
[main] #2003246 is not a child
[main] #2003246 exe => /usr/lib/jvm/zulu21-ca-amd64/bin/java
[Core] #2003246 is a NeedRestart::Interp::Java
[Core] #2003246 source is UNKNOWN
[main] #2003246 is openhab.service
So apparently it’s some temporary library file that is still in use, but have been deleted. If this happens frequently that would explain why OH continues to show up. The question is why this file gets deleted while OH is up and running?
The latter of the 2 topics had some clues in there, so I tried uninstalling the Jython Automation add-on, which now seems to have removed OpenHAB from the ‘needrestart’ candidate list.
I had only installed the Jython add-on with the intent of having a play, but never got around to using it (only using JS Scripting at present), so this was an easy workaround for me, but obviously not a solution for the many who are using it (And there may be other add-ons too which cause the same issue??).
That said, I will wait a few days and see what happens, before I am certain that the problem has gone away…. But OpenHAB was a needrestart candidate straight after a system reboot before, so it’s looking promising.
Do you have JRuby? This was mentioned in the last post in that topic, which led me to look at other add-ons, and found the Jython scripting seemed to be the culprit.
Yes, I know that Coincidence != Causation , so reinstalled the Jython scripting add-on, and OpenHab immediately became a candidate for restart….
Remove the Jython add-on , Restart OpenHab, and it’s no longer a need restart candidate.Whilst I have no idea of the specific root cause, it makes me feel like its an add-on issue, not a core issue.
A quick search of the github repository found nothing for the above mentioned jffi or libffi in Core, but in addons, turned up in Python Scripting, and Linuxinput addons. It’s probably a crude approach, as this doesn’t take into account underlying libraries that may leverage it too (Case in point, that Jython didn’t show up in my search, but it clearly leverages it somehow).
As a random thought, I have no idea if this is something which could be brought in via an library ‘include’ etc. in one of the scripting languages?
I use Jruby, but not python, so that would explain why I get these as well. The big question is why this library is loaded from the tmp directory, and then removed?
@ErikDB Sorry - I edited my post, about the time you replied. PythonScripting may be the other one to look at?
Alternatively, do you have somewhere you could install a fresh copy of OH, and then install the same addons you have on your current system, one-by-one, performing a needrestart -v command after each?
As we progress with this, I’m starting to think that:
We could end up with a list of add-ons which contribute to this behaviour
But there is the note in the above quote, that it could be a valid behaviour - I guess that needs to be confirmed by someone who knows this stuff inside out
And even if confirmed as an issue, then we could end up with a number of add-ons/different contributors who would need to address the respective add-ons, should they feel so inclined
The workaround mentioned in the other posts (adding the ubuntu config file) is starting to sound like an easier option to suppress the restarts?
The problem with this is that we miss cases when we really should restart OH such as for a security update to a library. For what it’s worth, I do have Jython installed. Right now I look at what is being updated and take a guess as to whether or not I should restart OH based on that.
I think I’m fine with that risk. Also, it’s not like my openHAB session would run for months on end. I pretty regularly stop it to change a binding jar, or reboot the Linux system for some other reason.
But a cleaner solution is always nicer, or course.
I have the same problem. I don’t have a solution, but some other observations:
It seems to be caused by the Bluetooth binding. If the Bluetooth binding is installed, I have the issue, if it isn’t, I don’t. I don’t need to add any related things, just installing the binding is enough to trigger the problem.
I have these other bindings installed with no issues
Astro
DSCAlarm
Mail
Network
Remote openHAB
SNMP
Unifi
Z-Wave
I don’t have Jython, JRuby, Python Scripting, or LinuxInput installed
It happens on both openhab 5.0.1 and 4.3.7. Maybe other versions as well but I only installed the Bluetooth binding recently. openHAB seems to create a file during startup, then quickly delete it, which causes needrestart to flag it. But if you restart openHAB it just creates and deletes the file again, putting you in the same situation.
In 4.3.7 the problem file is named /var/lib/openhab/tmp/libtmp17415077388055844394libjunixsocket-native-2.10.0.so . The numbers after libtmp seem to be random
In 5.0.1 the problem file is named /var/lib/openhab/tmp/jffi1570961906974703666.so . Again, the numbers after jffi seem to be random
I have the issue on two separate systems (I haven’t tried the Bluetooth binding on any others). The hardware is completely different on them (one is a 7th gen Intel NUC and the other is an AMD Ryzen 9000) but they both run Debian 13 Trixie.
I’m using the same workaround of telling needrestart to ignore openHAB, and just inspecting the output of needrestart -v periodically to decide if I need to restart it manually.
Does anyone else here with this issue have the Bluetooth binding installed?
