Blocky failing on system reboot (with Gluetun VPN client) #1417
Unanswered
ezekieldas
asked this question in
Q&A
Replies: 2 comments 2 replies
|
Hi, It's not a full answer, but a hint: the P.S. I inlined your files in the post for future reference since pastebin deletes things. |
0 replies
|
Thanks for the suggestion. tldr; use of I tried many things with little consequence (eg, docker debug, a lot of looking at dockerd logging, modifying compose, etc.). What I eventually realized is these lines weren't coming from init of blocky but rather from shutdown of the server: The test case I was using looked liked this:
If the logs and request were good then I'd do I began looking at the timestamps and could see the last request (vox.com) in the log was executed before shutdown: blocky_logAt this point I applied Including compose file here in case the next poor shmuck searching has this same issue: docker-compose.yml |
2 replies
|
I'm a bit confused by your compose since the blocky container doesn't expose the DNS ports and uses an interesting network mode, which I'm not familiar with. My guess would be that the built-in health check breaks in this setup and docker subsequently shuts the container down since it is considered unhealthy. To test it you could remove the restart policy and disable the container health check in your compose. |
|
My understanding of Docker networking and At some point in my debugging/troubleshooting madness I came across an issue in this repo which referenced disabling the healthcheck. Here I've isolated your suggestion with the results in logging. Now I'm unsure if this behavior is the result of my janky approach OR if there's the possibility of a bug here. I also don't want to waste anyone's time. But if this is looking interesting, do you have wireguard keys/addrs you could drop in to reproduce? Here is the docker-compose.yml with both healthcheck and docker-compose.ymlThese log entries accompany that docker-compose exactly. Make note of timestamps here!!! It reveals the earlier 10 lines or so are from a previous session and that the blocky_log + OS actionNow if I enable healthcheck and |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I have Blocky working with the Gluetun VPN client. I'm able to restart the running containers with
docker compose downand restart withdocker compose up -din which case Gluetun and Blocky are functioning as expected. I've tested this repeatedly. Please see 'docker compose file' below.
However, when I restart the OS (Ubuntu 22.04.4) with a
reboot, on the consecutive boot I see both containers start and Blocky seems to get through most initialization, answering a few requests, yet ultimately fails withTerminating... Stopping server(see: 'blocky debug log' below).I've reduced my Blocky config to what is shown below in 'blocky config'. My troubleshooting steps have included reducing option after option to what I believe is the bare minimum.
I'd be happy to apply any suggestions you may have.
docker-compose.yml
blocky debug log
blocky config
All reactions