Fresh install does not open 8080 port

Apps & Services openHABian
1

I did not update my openHAB installation since OH2, but with OH5 I decided to give it a try.

I did a fresh install on a “naked” SD card and went through all installation. The system is up and running and I can connect to it through SSH, however it does not listen on port 8080. When I check the open ports, I get only 22 and the SMB ports 139 and 445:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN     
tcp6       0      0 127.0.0.1:34627         :::*                    LISTEN     
tcp6       0      0 :::445                  :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 :::139                  :::*                    LISTEN     
udp        0      0 0.0.0.0:5353            0.0.0.0:*                          
udp        0      0 0.0.0.0:33244           0.0.0.0:*                          
udp        0      0 192.168.0.255:137       0.0.0.0:*                          
udp        0      0 192.168.0.17:137        0.0.0.0:*                          
udp        0      0 0.0.0.0:137             0.0.0.0:*                          
udp        0      0 192.168.0.255:138       0.0.0.0:*                          
udp        0      0 192.168.0.17:138        0.0.0.0:*                          
udp        0      0 0.0.0.0:138             0.0.0.0:*                          
udp6       0      0 :::5353                 :::*                               
udp6       0      0 :::59739                :::*

The installation process seems having finished correctly:

openhabian@openhabian:/boot $ tail first-boot.log 
Removing libgles2:arm64 (1.6.0-1) ...
Removing libwayland-client0:arm64 (1.23.1-3+rpt1) ...
Processing triggers for libc-bin (2.36-9+rpt2+deb12u12) ...
Updating FireMotD available updates count ... 
OK
2025-07-31_15:07:42_BST [openHABian] Execution of 'openhabian-config unattended' completed.
2025-07-31_15:07:42_BST [openHABian] First time setup successfully finished. Rebooting your system!
2025-07-31_15:07:42_BST [openHABian] After rebooting the openHAB dashboard will be available at: http://openhabian:8080
2025-07-31_15:07:42_BST [openHABian] After rebooting to gain access to a console, simply reconnect using ssh.
Removed "/etc/systemd/system/multi-user.target.wants/comitup.service".

When I check the openhab process, I get the following but I do not know how it should show if it works correctly. Is this showing that it is running?

openhabian@openhabian:~ $ sudo /bin/systemctl status openhab.service
● openhab.service - openHAB - empowering the smart home
     Loaded: loaded (/lib/systemd/system/openhab.service; disabled; preset: enabled)
     Active: active (running) since Thu 2025-07-31 15:36:57 BST; 13min ago
       Docs: https://www.openhab.org/docs/
             https://community.openhab.org
   Main PID: 1771 (java)
      Tasks: 33 (limit: 1050)
        CPU: 1min 33.656s
     CGroup: /system.slice/openhab.service
             └─1771 /usr/bin/java -XX:-UsePerfData -Dopenhab.home=/usr/share/openhab -Dopenhab.conf=/etc/openhab -Dopenhab.runtime=/usr/share/openhab/runtime -Dopenhab.userdata=/var/lib/openhab -Dopenhab.logdir=/var/log/openhab -Dfelix.c>

Jul 31 15:38:25 openhabian karaf[1771]:                 at org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.lambda$download$0(MavenDownloadManager.java:138)
Jul 31 15:38:25 openhabian karaf[1771]:                 at org.apache.karaf.features.internal.download.impl.DefaultFuture.notifyListener(DefaultFuture.java:350)
Jul 31 15:38:25 openhabian karaf[1771]:                 at org.apache.karaf.features.internal.download.impl.DefaultFuture.notifyListeners(DefaultFuture.java:335)
Jul 31 15:38:25 openhabian karaf[1771]:                 at org.apache.karaf.features.internal.download.impl.DefaultFuture.setValue(DefaultFuture.java:259)
Jul 31 15:38:25 openhabian karaf[1771]:                 at org.apache.karaf.features.internal.download.impl.AbstractDownloadTask.setFile(AbstractDownloadTask.java:61)
Jul 31 15:38:25 openhabian karaf[1771]:                 at org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:61)
Jul 31 15:38:25 openhabian karaf[1771]:                 at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
Jul 31 15:38:25 openhabian karaf[1771]:                 at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
Jul 31 15:38:25 openhabian karaf[1771]:                 at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
Jul 31 15:38:25 openhabian karaf[1771]:                 ... 3 more

The error message in the end shows that karaf cannot be installed properly but this conflicts with the message that everything could be installed well:

openhabian@openhabian:/var/log/openhab $ cat openhab.log
2025-07-31 15:54:39.970 [ERROR] [ternal.service.BootFeaturesInstaller] - Error installing boot features
org.apache.karaf.features.internal.util.MultiException: Error:
        invalid distance too far back
        at org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.<init>(MavenDownloadManager.java:91) ~[?:?]
        at org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72) ~[?:?]
        at org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:474) ~[?:?]
        at org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:469) ~[?:?]
        at org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:223) ~[?:?]
        at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:399) ~[?:?]
        at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1069) ~[?:?]
        at org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:1004) ~[?:?]
        at java.util.concurrent.FutureTask.run(Unknown Source) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[?:?]
        at java.lang.Thread.run(Unknown Source) [?:?]
        Suppressed: java.util.zip.ZipException: invalid distance too far back
                at java.util.zip.InflaterInputStream.read(Unknown Source) ~[?:?]
                at java.util.zip.ZipInputStream.read(Unknown Source) ~[?:?]
                at java.util.jar.Manifest$FastInputStream.fill(Unknown Source) ~[?:?]
                at java.util.jar.Manifest$FastInputStream.readLine(Unknown Source) ~[?:?]
                at java.util.jar.Manifest$FastInputStream.readLine(Unknown Source) ~[?:?]
                at java.util.jar.Attributes.read(Unknown Source) ~[?:?]
                at java.util.jar.Manifest.read(Unknown Source) ~[?:?]
                at java.util.jar.Manifest.<init>(Unknown Source) ~[?:?]
                at java.util.jar.Manifest.<init>(Unknown Source) ~[?:?]
                at org.apache.karaf.features.internal.region.Subsystem.getMetadata(Subsystem.java:682) ~[?:?]
                at org.apache.karaf.features.internal.region.Subsystem.lambda$downloadBundles$1(Subsystem.java:516) ~[?:?]
                at org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.lambda$download$0(MavenDownloadManager.java:138) ~[?:?]
                at org.apache.karaf.features.internal.download.impl.DefaultFuture.notifyListener(DefaultFuture.java:350) ~[?:?]
                at org.apache.karaf.features.internal.download.impl.DefaultFuture.notifyListeners(DefaultFuture.java:335) ~[?:?]
                at org.apache.karaf.features.internal.download.impl.DefaultFuture.setValue(DefaultFuture.java:259) ~[?:?]
                at org.apache.karaf.features.internal.download.impl.AbstractDownloadTask.setFile(AbstractDownloadTask.java:61) ~[?:?]
                at org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:61) ~[?:?]
                at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[?:?]
                at java.util.concurrent.FutureTask.run(Unknown Source) ~[?:?]
                at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) ~[?:?]
                at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[?:?]
                at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[?:?]
                at java.lang.Thread.run(Unknown Source) [?:?]

Trying to open the openhab console gives an error message:

openhabian@openhabian:/var/log/openhab $ openhab-cli console

Logging in as openhab
Failed to get the session.

Any idea what I could to finish the successful installation?

2

Did you burn the openHABian image or did you try to manually install openHABian?

Are there any errors or warnings further up in the openHABian installation log?

A ZipException usually means that a ZIP file (in in this case more likely a KAR or JAR file) is corrupted. Perhaps something went wrong while downloading the file. I can’t say for sure, I’ve never seen an error anything like this for OH.

I’d try clearing the cache as a first step since it’s easy to do. If that doesn’t work I’d try sudo apt purge openhab and then using openhabian-config reinstall openHAB. If that doesn’t work I’m not sure what else to try short of downloading and burning the image again.

3

Hi Rick. Thank you for the quick reply.

I had burned this image: openhabian-raspios64-latest-202507301306-crc89fa11d1.img.xz. It seems the latest. In the installation log, there is no error.

I did the steps you suggested, and it installed well, but still without opening 8080 (and karaf).

I will now re-burn the image and see if it works better afterwords.

4

Correction. This time, after quite some time, 8080 started up and works.

Thanks @rlkoshak for your help. The reinstall of openhab through openhabian-config did it.

1 Like
5

As you are coming from OH2, I wonder what rpi you have. Might be a good moment to replace it with a 5.

I’m also interested in your migration experience, keep us posted!

6

@lsiepel OK I will. For now, I made the following observations:

  • Port 8080 is sometimes inactivated and can only reactivated by reloading the openHAB service.

  • I tried the openhabian-config restore of a backup of OH2, but it failed with the following message:

    Extracting zip file to temporary folder.
  error:  invalid compressed data to inflate /tmp/openhab/restore/userdata/kar/openhab-addons-3.3.0/org/openhab/addons/bundles/org.openhab.binding.allplay/3.3.0/org.openhab.binding.allplay-3.3.0.jar
  error:  invalid compressed data to inflate /tmp/openhab/restore/userdata/kar/openhab-addons-3.3.0/org/openhab/addons/bundles/org.openhab.binding.boschshc/3.3.0/org.openhab.binding.boschshc-3.3.0.jar
Unable to unzip /var/lib/openhab/backups/openhab-backup-25_07_31-12_00_34.zip, Aborting...
FAILED (restore)

I am currently trying all that on a RPi3 with 1 GB memory, and the instructions wrote that the little memory might affect the proper functioning. However, it never said that it is missing memory, as it is can access more than 2 GB Swap file which it almost does not use.

I ordered a new RPI4 with 4 GB today which I will receive tomorrow. I will report again using the new Raspi.

7

That slightly implies that OH is crashing and restarting. Do you see that happening in the logs? You can easily tell really just checking the timestamps of the openhab.log.X.gz files. Every time OH starts it opens a new openhab.log file and it rotates the old ones, keeping seven archives. If there are timestamps since the last time you know you restarted OH that means it’s restarting.

That is almost certainly not going to work unless you are restoring to an OH 2 instance.

But the error points to something even worse, your backup is corrupted somehow. But the good news is it seems to be only stuff in tmp which you don’t want to restore anyway, particularly not when restoring a version of configs different from the version of OH running. OH needs to download and reinstall all that stuff.

It’s weird though, as the filenames imply this backup came from OH 3, not OH 2.

8

@rlkoshak Sorry, yes, it was OH3, not OH2.

I used the same SD card now on a RPi4 with 4 GB, and it showed the same problem of losing 8080.

I rewrote the SD card a third time (to have a clean reinstall of OH5 based on the new hardware), and for now, it seems stable. It seems that the 8080 problem had nothing to do with the small memory (otherwise the problem would not have shown up on the RPi4), but maybe with the OH5 configuration process in a RPi3/1 GB environment?

While my old installation was mostly configuration file based, I decided to go for the graphical environment now (I had too much trouble in OH3 the system ‘detecting’ things that had already been defined in the files). Even a dinosaur like myself has to go with times :wink:

I have been working a lot configuring things, but until now, 8080 stayed stable.