Closed kpine closed 4 years ago
Thanks - So I want to explore the S6 supervisor that you mentioned in another issue. I see this supervisor a bit fragile with regards to the watchdog script...
I've also been exploring the build in Docker HEALTHCHECK option which seems like a candidate to improve reliability.
The hassio addon for ozw is a pretty good place to start, it's where I stole the idea of waiting on the mqtt port. Looks pretty simple.
So I agree with this. ozw should wait for mqtt host. This saves the network from much downtime.
When the MQTT broker becomes unavailable, a running ozwdaemon will exit (by design). For the standalone container, a restart policy of
always
oron-failure
will result in ozwdaemon aggressively restarting with bad behavior. If no restart policy is set, the container will stay stopped until the user intervenes. For the allinone container, supervisord handles the role of the docker restart policy and attempts to restart ozwdaemon, but sometimes fails (for both of those, see #120).The startup/teardown of ozwdaemon is fairly expensive compared to alternative approaches. It also currently results in several different crashes. In this change we use bash redirection to detect if the MQTT broker connection is even available before starting ozwdaemon (inspired by the HA ozw addon). The startup script will wait for a configurable amount of time until either a) the MQTT broker is accessible and ozwdaemon will be started or b) the timeout expires and the startup script will exit with an error. This won't guarantee the connection to the broker will be successful, but it handles more gracefully the case where the MQTT server is down for a significant amount of time.
It might make sense for ozwdaemon to have this kind of behavior built-in. Perhaps that would be a better long term fix as part of #20?
In my testing this avoids the problems seen in #120, although it's not really a solution for the crashes. With a restart policy the standalone container will restart forever until MQTT is started. For the allinone container, the supervisor will attempt to restart ozwdaemon until MQTT is started. It seemed to try forever. I am not sure if that's the expected behavior, or if it should cause the container to exit after some number of tries?
Docker logs from standalone:
Docker logs from allinone. I don't really understand the
reaped unknown pid
logs. Am I exiting on error incorrectly?ozwdaemon.log when it was waiting for the broker:
Also added documentation for the new environment variable to set the connect timeout, as well as other misc related cleanup changes.