-
-
Notifications
You must be signed in to change notification settings - Fork 367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: Sequence complete, Healthy, then Unhealthy, Restarting VPN, Sequence complete and afterwards Healthy again #1017
Comments
This can happen occasionally see https://github.com/qdm12/gluetun/wiki/Healthcheck#internal-healthcheck we tcp dial cloudflare.com:443 and sometimes this can fail and that's fine. Does this happen every time or is it a one off issue? |
It does happen every time the last 10 times I've checked, I don't create an issue for an one off issue :) |
Does it happen consistently on latest but not v3.29.0? |
I checked it a few times in v3.29.0, here the error also exists Gluetun v.3.29.0 Log
|
But for now, the latest-logs look a bit different. Healthy and Unhealthy still exists, but there's no VPN stopping/starting anymore Gluetun Latest Log
|
It's most likely because the nameserver is changed to I'm working on #137 now, let's see if it indirectly solves it. I'll message here once it's done. |
Seems I have the same issue here.
|
Hi all, |
@antro31 that's just a workaround, and it means you don't test if the DNS server is working or not. Can one of you try using
|
I checked it a few times with Gluetun MALICIOUS OFF Log
|
@qdm12 I've been having similar issues recently. Gluetun starting / stopping the VPN due an unhealthy ping. The issue is that the dependent containers seem to lose all connectivity until they are themselves restarted. That wasn't an issue before the healtcheck mechanism was introduced. Maybe the VPN could be restarted only in multiple checks fail over the course of a minute or so ? I don't really know if a gluetun could signal other containers to automatically restart if it has to kick and restart the VPN. For now i have turned off BLOCK_MALICIOUS, as well as SURVEILLANCE and ADS which i had turned on, let's see if that addresses the issue at least temporarily. Thanks for the tool though, it's great and very useful ! |
@romainguinot you can make durations larger https://github.com/qdm12/gluetun/wiki/Health-options
Actually the point of the 'inner vpn restart' is so connected containers don't disconnect. Are you sure there isn't something retarting gluetun externally (as in, container restart)? That would cause connected containers to disconnect. |
Subscribe to #641 its still a work in progress (through another container qmcgaw/deunhealth) and I'm lacking time, but I'm doing my best to finish this soon. |
As far as i can tell no, gluetun does not restart. But if there is an inner VPN restart, some containers are fine with it, some are not. I suspect that those that have long running connections may get "confused" by the VPN restart and lose connectivity, but those who only need periodic web access in short bursts aren't affected. I have turned off for now BLOCK_MALICIOUS, as well as SURVEILLANCE and ADS and will see how it goes. To mitigate this a bit, i have also scheduled a daily restart of the affected container that gets stuck if the inner VPN is restarted. |
I will subscribe. Take your time though it's not a huge deal. Gluetun is really great and it's really appreciated how quick and detailed your responses are. |
Seems I have the same issue here. Good job with your gluetun project! |
+1 for users experiencing this issue. Setting |
I’m also having frequent healthcheck failures and gluetun disconnection, screwing the container behind since few days now.
|
@romainguinot You are correct, long running connections might fail. I had the case within Gluetun and the http client communicating with the Private Internet Access API. The solution for me was to close the idle connections of my http client, but that's really a programming detail and not always possible to do for other containers. Once #641 is done, this should fix that problem though (restart all connected containers). For other people complaining about frequent internal vpn restarts:
|
forgot to reply @qdm12 sorry. For now with the scheduled daily restarts of the affected container it seems to mitigate the issue. One day if there can be a restart of dependent containers that would be great but no rush. I wish in the Synology NAS or in Portainer you could easily mark containers as dependent on gluetun so that they can wait for a healthy gluetun as well before starting up, but that's a minor inconvenience as this is only an issue when the whole NAS is restarted which is clearly not very frequent. |
I use: depends_on:
- gluetun after all of the dependent containers in my Portainer Stack -- and it seems to do the trick. The only time I need to stop and restart the entire stack is when I do an on demand update of all running containers using Watchtower. |
See #2154 there is some interesting information, especially
Closing this due to inactivity 😉 |
Closed issues are NOT monitored, so commenting here is likely to be not seen. This is an automated comment setup because @qdm12 is the sole maintainer of this project |
Is this urgent?
No
Host OS
Debian Bullseye
CPU arch
x86_64
VPN service provider
Surfshark
What are you using to run the container
docker-compose
What is the version of Gluetun
Running version latest built on 2022-06-06T18:13:11.996Z (commit 5359257)
What's the problem 🤔
Sequence complete,
Healthy,
then Unhealthy,
Restarting VPN,
Sequence complete,
and afterwards Healthy again
Share your logs
Share your configuration
The text was updated successfully, but these errors were encountered: