hi @hmerk
yes, could be. But the unavailability could also come from the hundreds of processes which are eating the available cpu and ram. its like i had former other addons which pinging. Its useless that these pings are done on hundreds of interfaces which existing on docker. and so its also useless that it is discovering things from interfaces which are not the main interface. So if it is possible to limit the interface where the java-process is communicating on then it would work all fine. For pings i opened an issue and a workaround is known. For this i just dont know any workaround to NOT OPEN hundreds of processes “SocketListener” and “JmDNS”, because the workaround in addons.cfg from @Mherwege does not work. I greped therefore the counts of these processes and counted them 90/213 which making no sence. On docker you have other containers which has private interfaces. It makes no sence to say that you have to give openhab the host-network that UPNP can work and then let it run not only on the main-network-card interface instead let it act on hundreds of interfaces where no broadcasts/multicasts ever will be received from upnp and so on.
I was merely trying to figure out if the issue now appears due to these suggestion finders.
Just to be sure, when youvdisable the finders, if you can get into the karaf console, can you verify if they are effectively disabled? Do
bundle:list | grep Finder
to find out which ones are running.
If all are running, there should be 4 of these. You cannot disable the process one (it looks for running processes on current machine). But you should be able to disable the others, which does not necessarily mean none of the dependencies are not running anymore due to another reason outside of the finders.
The IP-based finder could potentially create sockets to listen for incoming traffic (but will time out and not get recreated). So disabling that as well could be interesting. The parameter would be:
suggestionFinderIp = false
Again, I think the root cause may indeed be the underlying code tries on too many interfaces. But that is not because of the finders.
I don’t use docker, so no way to test.
Hi @Mherwege
the 2 parameters you gave were in there and im seeing this:
openhab> bundle:list | grep Finder
168 │ Active │ 80 │ 4.1.0 │ openHAB Core :: Bundles :: Process-based Suggested Add-on Finder
245 │ Active │ 80 │ 4.1.0 │ openHAB Core :: Bundles :: IP-based Suggested Add-on Finder
Now i will test if im adding suggestionFinderIp = false
openhab> bundle:list | grep Finder
168 │ Active │ 80 │ 4.1.0 │ openHAB Core :: Bundles :: Process-based Suggested Add-on Finder
openhab>
the top -H is still showing the SocketListeners
docker exec -it openhab-openhab-1 ps -T -p 26|grep Socket|wc -l
91
After 10mins later i looked at CPU-Usage of container: it is about 10-20%. And also the GUI is working now on 4.1.0 with the 3 parameters in as fast as under 4.0.3!
im thinking this too but on docker you will have this if your are not using docker for only openhab. This would be like using a containership for only one container…
Hi @Mherwege
in the night the threads were again growing (without any change)
docker exec -it openhab-openhab-1 ps -T -p 26|grep Socket|wc -l
109
docker exec -it openhab-openhab-1 ps -T -p 26|grep JmDNS|wc -l
309
and CPU/RAM eaten and GUI no more reacting… Im not sure why this >300 threads which counted by wc-l are coming because the UpNP Addon i uninstalled so from this it can not come… What im surely know that the behavoir is not existing in 4.0.X and is reproducable in 4.1.0
Hi @Scriptwriter
I upgraded to 4.1.0 today and experienced exactly the same thing. I’m using docker on Ubuntu in host mode for OH. The upgrade was successful, but the UI was unresponsive at first. After a few minutes I was able to use it (more or less).
CPU usage was extremely high, affecting the whole system. And I also saw a lot of these SocketListener( processes.
Didn’t have time to further investigate, so I downgraded to 4.0.3 for the time being which also solved it for me.
@hmerk
My guess is, that the UI is unresponsive because of the high CPU usage. In my case, I’m on an 8 core Intel CPU (compared to @Scriptwriter’s Raspi). The UI gets started in my case, but is also very slow and hard to use.
For me it’s quite similar. Upgraded from 4.0.4 to 4.1.0 on docker on a Synology NAS in host Network and got CPU usage like never seen before. GUI also very slow or not responding at all. Fired 4.0.4 back up and it’s running without issues.
OK, bcause multiple users of docker and new version 4.1.0 had same problems i filed an issue for that
https://github.com/openhab/openhab-core/issues/3976
A fix is now proposed:
i updated now to 4.1.1 and can confirm that this works fine under docker now.
For me as well! Running smooth since yesterday. Thank you very much!