Port conflict on http[s] port after upgrading to OH4

Setup, Configuration and Use Migration
1

I’m running OH in docker, and I just upgraded from 3 to 4, and the web interface is longer coming up because of a port binding error.

In the logs I see the following:

2023-08-11 22:20:36.784 [INFO ] [lipse.jetty.server.AbstractConnector] - Started 0.0.0.0:8444@283e8eb9{SSL, (ssl, http/1.1)}{0.0.0.0:8444}
2023-08-11 22:20:36.805 [INFO ] [lipse.jetty.server.AbstractConnector] - Started default@722877c0{HTTP/1.1, (http/1.1, h2c)}{127.0.0.1:8087}
2023-08-11 22:20:36.817 [ERROR] [j.pax.web.service.internal.Activator] - Unable to start Pax Web server: Failed to bind to /127.0.0.1:8444
java.io.IOException: Failed to bind to /127.0.0.1:8444
    at org.eclipse.jetty.server.ServerConnector.openAcceptChannel(ServerConnector.java:349) ~[?:?]
    at org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:310) ~[?:?]
    at org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80) ~[?:?]
    at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:234) ~[?:?]
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) ~[?:?]
    at org.eclipse.jetty.server.Server.doStart(Server.java:401) ~[?:?]
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) ~[?:?]
    at org.ops4j.pax.web.service.jetty.internal.JettyServerWrapper.start(JettyServerWrapper.java:623) ~[?:?]
    at org.ops4j.pax.web.service.jetty.internal.JettyServerController.start(JettyServerController.java:109) ~[?:?]
    at org.ops4j.pax.web.service.internal.Activator.performConfiguration(Activator.java:555) ~[?:?]
    at org.ops4j.pax.web.service.internal.Activator.updateController(Activator.java:445) ~[?:?]
    at org.ops4j.pax.web.service.internal.Activator.lambda$updateServerControllerFactory$1(Activator.java:347) ~[?:?]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
    at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
    at java.lang.Thread.run(Thread.java:833) ~[?:?]
Caused by: java.net.BindException: Address already in use
    at sun.nio.ch.Net.bind0(Native Method) ~[?:?]
    at sun.nio.ch.Net.bind(Net.java:555) ~[?:?]
    at sun.nio.ch.ServerSocketChannelImpl.netBind(ServerSocketChannelImpl.java:337) ~[?:?]
    at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:294) ~[?:?]
    at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:89) ~[?:?]
    at org.eclipse.jetty.server.ServerConnector.openAcceptChannel(ServerConnector.java:344) ~[?:?]

There is nothing else using port 8444. When I stop the container, the port is free, and when I start the OH container I see java listening to the port. I even get the error if I change the port of OH to something else.

I’ve cleared the temp, cache and addons directories and I’ve restarted the container countless times.

2

Have you tried rebooting the machine?

3

Yes

4

Looks like both pax and jetty are trying to bind to the same port. Which one is supposed to bind to the port, and how do I disable the other?

When I point a browser to the page, I see a jetty error page.

5

i have the same problem did you solve it?

6

No, I did not have more time to spend on debugging this and I reverted to the previous version.

I did see a clue in the logs once I reverted, but I’ve not spend any time looking at it since I got OH3 running again. When running OH3, there was a warning from jetty related to the certificate. I’m speculating that OH3 is not starting the TLS connector for jetty, but for some reason OH4 is starting it. I don’t know what the fix would be, or what actually should listen to that port, though.

Let me know if you figure it out.

7

Running the following command in the karaf console for OH 3:

property-list --pid org.ops4j.pax.web

I get

   org.ops4j.pax.web.config.file = /usr/share/openhab/runtime/etc/jetty.xml
   org.ops4j.pax.web.server.idleTimeout = 300000
   org.ops4j.pax.web.server.maxThreads = 50
   org.ops4j.pax.web.server.minThreads = 2
   org.ops4j.pax.web.session.timeout = 10
   org.ops4j.pax.web.ssl.clientauthneeded = false
   org.ops4j.pax.web.ssl.clientauthwanted = false
   org.osgi.service.http.secure.enabled = true
   org.osgi.service.http.useNIO = true

Looking into the xml file according to my understanding port 8443 is the default port to be used for jetty and pax.
So I am wondering why in first post port 8444 is being used. Did you change anything to use that port ?

8

I change the default port. I use docker, and pass in OPENHAB_HTTP_PORT=8087 and OPENHAB_HTTPS_PORT=8444 to change the ports. Both the jetty and pax port change when I do that.

Looking into the xml file according to my understanding port 8443 is the default port to be used for jetty and pax.

I don’t know enough about the architecture of the container to understand what should be binding to the port. From your properties, it looks like pax is delegating to jetty.

When I start the container, something in the container is binding to that port before jetty gets a chance to bind. It does not matter if I change the default port or not.

Are you also using docker by chance? I’m just wondering if this is a problem with the docker image, or if it’s something in the userdata directory.

9

No I don’t use docker.
Wouldn’t it be a good test to use the standard ports instead of changing them ? In case it works with default ports but does not work when ports are changed then this is a problem related to changing the ports and it would be required to further look into what went wrong ?

10

Wouldn’t it be a good test to use the standard ports instead of changing them?

I’ve tried that, and it makes no difference if I use the default ports or not.

11

@Wolfgang_S Did you find a solution to this?

12

I haven’t had the problem - just tried to help.

13

@arins Did you find a solution to this?

14

Yes it was a config somewhere! I can try to find later today

15

@arins do you mind looking for this. It would save me a lot of time.

16

unfortunately I don’t remember what config I had changed. But what you can do is open the userdata folder in vs code, notepad++ or similar editor and search the entire folder for binding like:

127.0.0.1:8444

For me it was because I was experimenting with jupnp if I remember correctly. so I think it was another binding in either org.jupnp.cfg or org.ops4j.pax.web.cfg configuration.

17

I was not able to find the root cause for this. After hours of looking at this, I decided to start fresh. I reset the docker container, backed up and deleted the userdata folder, then selectively copying back the key files in jsondb. After installing the bindings, everything is green again.

That took about 1/2 hour. I wish I did not have to do that, but it was easier than tracking down whatever config was causing the port conflict.