starting with my previous data but with cleared cache and tmp
starting empty OpenHAB image with different versions (2.4, 2.5.4, 2.5.4-debian, 2.5.4-alpine, latest).
setting log:set DEBUG core.karaf.internal
I always end up seeing this message, which doesn’t even say what the real problem was… There is no stack trace or causing exception. Only this message.
This may be RPi or situation specific - I tried this whole setup with docker and whatnot before with OpenMediaVault (debian) installed on VM and it worked ok. I’d just like to hear some tips on how to debug this error.
After waiting awhile to make sure OH has a chance to come online. If the error persists, try stopping OH and clearing the cache (delete the contents of userdata/cache and userdata/tmp. Restart and tell us whether the problem persists.
When UID and GID are not set up correctly OpenHAB refuse to even start.
pi@nas:/srv/dev-disk-by-label-AData/OpenHAB/openhab $ ls -nl
total 24
drwxr-sr-x+ 2 1000 100 4096 May 17 16:05 addons
drwxr-xr-x+ 13 1000 100 4096 Apr 19 15:08 conf
drwxr-xr-x+ 8 1000 100 4096 May 17 15:12 userdata
pi@nas:/srv/dev-disk-by-label-AData/OpenHAB/openhab $ grep pi /etc/passwd
pi:x:1000:1000:,,,:/home/pi:/bin/bash
pi@nas:/srv/dev-disk-by-label-AData/OpenHAB/openhab $ grep users /etc/group
users:x:100:pi
Gentelmen, I appreciate the time you put in looking into those configs and your guesses and I experimented with various settings for like a week now. I think that what I need now is a solid debug path that would lead me to the root cause of the problem, not just experimenting further.
I don’t understand why I don’t see the full stack trace containing the root cause for failure. I think I need that to solve the issue. Do you know how to set up more verbose logging?
// EDIT:
Oh, I’ve looked into the code and this is very disappointing. The exception is swallowed and only the message is logged Why it’s done like that?
In the Docker-compose confid you posted the OpenHAB container has the same uid as another but a different gid. That is why I asked if there was a typo in the config.
Are the owner, group, and permissions set correctly on the mounted volumes? (UID 1000 GID 100)
Yeah, I also suspected permissions to be the problem but this is not the case which you can actually see from my cmdline output - 3rd column is the owner UID (1000) and 4th is the GID (100). I have also set this recursively to subfolders and files.
Just because it is missing try adding OPENHAB_HTTPS_PORT: "8443" I doubt it will help but it is in all examples I see.
Also network_mode: host is not listed in their example docker-compose file. I know it works in my testing without it.
My OMV Extras is version 5.3.3 and they claim to have fixed it in 5.3.1. This also is not the problem I’m seeing. Docker starts ok and is pulling all the images. I’ve successfully started few other containers (all in this docker-compose file) and they are running as expected.
I’ll give this a try, but it would be surprising if this worked
Keep in mind that this exact docker-compose.yaml file was running flawlessly on another machine.
@Bruce_Osborne as I suspected - this didn’t change anything.
@BrutalBirdie thanks, for sharing but I don’t think its a configuration issue. Also - why do you have network_mode: host and also ports: section? host basically means that you expose all the ports, so why bother listing the ports?
EDIT:
I’m starting to think that the only way to debug this is by forking the OpenHAB, fixing the code I linked in my previous post so it properly logs the whole exception and building the docker image from Dockerfile myself. Do you guys have other ideas?
I know it does no difference but since I created this repo for new users, writing down the Ports can help users figure out how this setup works.
Yes they could read the docs or lookup netstat -tulpen or something like that but why not in the config file
I agree on the explicit/implicit case. I’d probably remove the network_mode: host then since it does no good, and potentially may expose some unwanted ports implicitly