Summary
The OpenHAB container takes 5 minutes to become healthy, which is a problem if other systems like Traefik depend on the container being healthy.
Expected Behavior
The container should take no longer than 20s to (re-)start, as OpenHAB itself is ready within ~13s.
Current Behavior
Every container restart needs at least 5min. This causes problems with Traefik and other systems that depend on the container being healthy; and can be especially annoying if other services assume that the restart is taking too long.
Additionally, the current settings have the side effect that in case of an error, the healthcheck will need 15min until it detects a failure, which is quite long IMO.
Possible Solution
In #417 it is stated that the healthcheck uses a 5min interval to not overwhelm slower SBCs. A more flexible approach would be to use a combination of --start-period and a shorter interval; e.g. --start-period=600s --interval=20s --timeout=5s --retries=3.
This configuration would be SBC-friendly in the sense that it allows for up to 11min of startup time (600s + 3 times 20s), but still uses a much "tighter" polling so that a) a server that starts faster will not be unnecessarily blocked for 5min, and b) if an error occurs, the healthcheck will trigger in ~1min.
Steps to Reproduce
- Start the container
- Wait until the container becomes healthy
Context
I'm trying to deploy OpenHAB behind Traefik. With the current healthcheck, each container (re-)start or update results in an unnecessary downtime of at least 5min. Additionally, it triggers my monitoring which considers a startup time of more than 2min suspicious.
Image
- The image is
openhab/openhab:latest-debian
Docker Host
- Operating System:
Debian GNU/Linux 13 (trixie)
- Docker Version: 26.1.5+dfsg1
- Kernel Version: 6.12.74+deb13+1-amd64
- Architecture: x86_64
Configuration
services:
{{ service }}:
image: openhab/openhab:latest-debian
network_mode: host
volumes:
- /var/containers/{{ service }}/addons:/openhab/addons:rw
- /var/containers/{{ service }}/conf:/openhab/conf:rw
- /var/containers/{{ service }}/java:/openhab/.java:rw
- /var/containers/{{ service }}/userdata:/openhab/userdata:rw
- /etc/timezone:/etc/timezone:ro
environment:
- TZ=Europe/Berlin
- CRYPTO_POLICY=unlimited
- OPENHAB_HTTP_PORT=8123
Summary
The OpenHAB container takes 5 minutes to become healthy, which is a problem if other systems like Traefik depend on the container being healthy.
Expected Behavior
The container should take no longer than 20s to (re-)start, as OpenHAB itself is ready within ~13s.
Current Behavior
Every container restart needs at least 5min. This causes problems with Traefik and other systems that depend on the container being healthy; and can be especially annoying if other services assume that the restart is taking too long.
Additionally, the current settings have the side effect that in case of an error, the healthcheck will need 15min until it detects a failure, which is quite long IMO.
Possible Solution
In #417 it is stated that the healthcheck uses a 5min interval to not overwhelm slower SBCs. A more flexible approach would be to use a combination of
--start-periodand a shorter interval; e.g.--start-period=600s --interval=20s --timeout=5s --retries=3.This configuration would be SBC-friendly in the sense that it allows for up to 11min of startup time (600s + 3 times 20s), but still uses a much "tighter" polling so that a) a server that starts faster will not be unnecessarily blocked for 5min, and b) if an error occurs, the healthcheck will trigger in ~1min.
Steps to Reproduce
Context
I'm trying to deploy OpenHAB behind Traefik. With the current healthcheck, each container (re-)start or update results in an unnecessary downtime of at least 5min. Additionally, it triggers my monitoring which considers a startup time of more than 2min suspicious.
Image
openhab/openhab:latest-debianDocker Host
Debian GNU/Linux 13 (trixie)Configuration