Open Firestorm7893 opened 1 month ago
github-actions[bot]
commented
1 month ago @qdm12 is more or less the only maintainer of this project and works on it in his free time. Please:
qdm12
commented
1 month ago If you restart the Gluetun container only (do you have auto-updates like watchtower?), connected containers lose their connection and won't be reachable. Maybe this is what happens here?
Firestorm7893
commented
1 month ago I don't have a watchtower or anything similar but the container does restart itself in case of crashes. Maybe I'll check in the logs if the container gets restarted for any reason.
Firestorm7893
commented
1 month ago I tried looking for restarts with docker system events but nothing came up. Instead just logging the container's events let me see that these two events kept happening every 2/3 seconds
2024-07-28T18:23:39.501819784+02:00 container exec_start: /bin/sh -c /gluetun-entrypoint healthcheck
0aa1cb468c8def9ded0a82d1fc35f5fbfd2590b3022ecbb324eac372e29b2f1d (com.docker.compose.config-
hash=8e07dc888fbd33ef6f2a0d5f3a8e8695704ec265a37e5b629d5908942d151901, com.docker.compose.container-number=1,
com.docker.compose.depends_on=,
com.docker.compose.image=sha256:bd31c8cbe0ba219e7fb86d0f5e6725d774aa5a45b00a4baa397b2f5ac8de9e29,
com.docker.compose.oneoff=False, com.docker.compose.project=internal, com.docker.compose.project.config_files=/data/
compose/43/docker-compose.yml, com.docker.compose.project.working_dir=/data/compose/43,
com.docker.compose.replace=d6e0c60986400806053f733578debbb539676d23387109b9c9b8ed70a04abb63,
com.docker.compose.service=gluetun, com.docker.compose.version=2.24.6,
execID=7e541bed1fcc930360f9704a2033d71e83a9da7c088154753081d18a1f5b9103, image=qmcgaw/gluetun, name=gluetun,
org.opencontainers.image.authors=quentin.mcgaw@gmail.com, org.opencontainers.image.created=2024-07-12T19:57:02.146Z,
org.opencontainers.image.description=VPN client in a thin Docker container for multiple VPN providers, written in Go, and using
OpenVPN or Wireguard, DNS over TLS, with a few proxy servers built-in., org.opencontainers.image.documentation=https://
github.com/qdm12/gluetun, org.opencontainers.image.licenses=MIT,
org.opencontainers.image.revision=9d50c2353204a6d497b94fbfa96423c8bda5f529,
org.opencontainers.image.source=https://github.com/qdm12/gluetun, org.opencontainers.image.title=gluetun,
org.opencontainers.image.url=https://github.com/qdm12/gluetun, org.opencontainers.image.version=latest, traefik.docker.network=newNetwork, traefik.enable=true,
traefik.http.middlewares.qb-headers.headers.customrequestheaders.Origin=,
traefik.http.middlewares.qb-headers.headers.customrequestheaders.Referer=,
traefik.http.middlewares.qb-headers.headers.customrequestheaders.X-Frame-Options=SAMEORIGIN, traefik.http.routers.qb.middlewares=qb-headers, traefik.http.routers.qb.rule=Host(`#######`),
traefik.http.routers.qb.service=qb, traefik.http.routers.qb.tls=true, traefik.http.routers.qb.tls.certresolver=lets-encrypt, traefik.http.services.qb.loadbalancer.passhostheader=false,
traefik.http.services.qb.loadbalancer.server.port=54444)
2024-07-28T18:23:39.600776235+02:00 container exec_die
0aa1cb468c8def9ded0a82d1fc35f5fbfd2590b3022ecbb324eac372e29b2f1d
(com.docker.compose.config-hash=8e07dc888fbd33ef6f2a0d5f3a8e8695704ec265a37e5b629d5908942d151901,
com.docker.compose.container-number=1, com.docker.compose.depends_on=, com.docker.compose.image=sha256:bd31c8cbe0ba219e7fb86d0f5e6725d774aa5a45b00a4baa397b2f5ac8de9e29,
com.docker.compose.oneoff=False, com.docker.compose.project=internal,
com.docker.compose.project.config_files=/data/compose/43/docker-compose.yml,
com.docker.compose.project.working_dir=/data/compose/43, com.docker.compose.replace=d6e0c60986400806053f733578debbb539676d23387109b9c9b8ed70a04abb63,
com.docker.compose.service=gluetun, com.docker.compose.version=2.24.6, execID=7e541bed1fcc930360f9704a2033d71e83a9da7c088154753081d18a1f5b9103, exitCode=0, image=qmcgaw/gluetun,
name=gluetun, org.opencontainers.image.authors=quentin.mcgaw@gmail.com, org.opencontainers.image.created=2024-07-12T19:57:02.146Z,
org.opencontainers.image.description=VPN client in a thin Docker container for multiple VPN providers, written in Go, and using OpenVPN or Wireguard, DNS over TLS, with a few proxy servers built-in.,
org.opencontainers.image.documentation=https://github.com/qdm12/gluetun, org.opencontainers.image.licenses=MIT,
org.opencontainers.image.revision=9d50c2353204a6d497b94fbfa96423c8bda5f529,
org.opencontainers.image.source=https://github.com/qdm12/gluetun, org.opencontainers.image.title=gluetun,
org.opencontainers.image.url=https://github.com/qdm12/gluetun, org.opencontainers.image.version=latest,
traefik.docker.network=newNetwork, traefik.enable=true,
traefik.http.middlewares.qb-headers.headers.customrequestheaders.Origin=,
traefik.http.middlewares.qb-headers.headers.customrequestheaders.Referer=,
traefik.http.middlewares.qb-headers.headers.customrequestheaders.X-Frame-Options=SAMEORIGIN,
traefik.http.routers.qb.middlewares=qb-headers,
traefik.http.routers.qb.rule=Host(`########`), traefik.http.routers.qb.service=qb, traefik.http.routers.qb.tls=true,
traefik.http.routers.qb.tls.certresolver=lets-encrypt, traefik.http.services.qb.loadbalancer.passhostheader=false,
traefik.http.services.qb.loadbalancer.server.port=54444)
I never really used the healtcheck system provided by docker, but could it be that after some time it decides the container is unealty? I ask this because of the container exec_start: /bin/sh -c /gluetun-entrypoint healthcheck event immediately followed by the container exec_die event
knaku
commented
1 month ago I have also had these issues, thought I had changed something which created thae issue but I have tried debug my config a bit. I have not verified it but my impression is that the passed through container becomes unavailable after a restart of the gluetun container. I've had some issues with the gluetun container being unhealthy, I thought that was because of a non-updated servers.json but that has been updated for some time now and the issue has persisted.
I changed the hardware and host in april, but I think the issues started in may-june but I am not sure.
As a side note, for my part the health check might fail because of an old slow spinning disk on the host machine, which runs a VM with Gluetun and a couple of other containers - horrible IOPS.
Silversurfer79
commented
3 weeks ago Just wondering it there is a way to mark a container as dependent on another and if there is an issue with a container to force a restart of them in sequence of priority? Due to the frequent releases of Gluetun, it’s been updated a few times (no issue I’m glad on the development and thanks) this week and I always run the latest and use watchtower top check every night at 2am. This means that Gluetun pulls the new container and then Transmission fails to "reconnect". Wondering how we could eliminate this? I know I could make watchtower only check once a week, but it doesn’t fix Transmission dependency on Gluetun.
epd5
commented
2 weeks ago Just wondering it there is a way to mark a container as dependent on another and if there is an issue with a container to force a restart of them in sequence of priority? Due to the frequent releases of Gluetun, it’s been updated a few times (no issue I’m glad on the development and thanks) this week and I always run the latest and use watchtower top check every night at 2am. This means that Gluetun pulls the new container and then Transmission fails to "reconnect". Wondering how we could eliminate this? I know I could make watchtower only check once a week, but it doesn’t fix Transmission dependency on Gluetun.
To force a dependency for my P2P client I run this under my P2P client:
healthcheck: test: ["CMD-SHELL", "nc -z -v localhost 9999 || exit 1"] interval: 30s timeout: 10s retries: 3 start_period: 10s
found here: https://github.com/qdm12/gluetun/issues/641#issuecomment-2090688743
P2P Client healthchecks open port check of Gluetun, if it fails marks unhealthy, then willfarrell/autoheal container restarts it. Works well for me with minimal downtime.
Silversurfer79
commented
2 weeks ago Just wondering it there is a way to mark a container as dependent on another and if there is an issue with a container to force a restart of them in sequence of priority? Due to the frequent releases of Gluetun, it’s been updated a few times (no issue I’m glad on the development and thanks) this week and I always run the latest and use watchtower top check every night at 2am. This means that Gluetun pulls the new container and then Transmission fails to "reconnect". Wondering how we could eliminate this? I know I could make watchtower only check once a week, but it doesn’t fix Transmission dependency on Gluetun.
To force a dependency for my P2P client I run this under my P2P client:
healthcheck: test: ["CMD-SHELL", "nc -z -v localhost 9999 || exit 1"] interval: 30s timeout: 10s retries: 3 start_period: 10sfound here: #641 (comment)
P2P Client healthchecks open port check of Gluetun, if it fails marks unhealthy, then willfarrell/autoheal container restarts it. Works well for me with minimal downtime.
Thats very helpful thanks, Ill give it a try and get back to yhe thread.
nrgbistro
commented
1 week ago Tried this, it didn't work for me. When I restart my gluetun container I can no longer access my container behind gluetun. The container is still marked healthy even though it cannot be reached. I instead used ping -c 1 1.1.1.1 || exit 1 as my healthcheck command, which seems to work.
Is this urgent?
No
Host OS
Fedora 40
CPU arch
x86_64
VPN service provider
ProtonVPN
What are you using to run the container
docker-compose
What is the version of Gluetun
Running version latest built on 2024-07-12T19:57:02.146Z (commit 9d50c23)
What's the problem 🤔
For some months I have been battling with an issue regarding the pass through gluetun does to the containers it protects trough the vpn. After an undefined amount of time (could be days, could be hours) any container that publishes a port through Gluetun becomes unreachable giving always a bad gateway error.
Eg. qbittorrent:54444 -> gluetun:54444 -> Bad Gateway.
Weirdly enough, Gluetuns api (the one at port 8000) is always reachable. I think there is an issue with gluetun since this issue, when it happens, it also happens to the flaresolverr container at the same time, which also uses the vpn.
Even weirder, the only fix is rebooting qbittorrent and flarsolverr, rebooting gluetun doesn't fix it.
I searched github for a similar issue but nothing else came up (unless I searched with the wrong terms) Traefik is not the issue, since even by going trough local host still results in a gateway error.
Maybe I am missing something, in my config?
Thanks in advance for any help. I can move this to the discussion if it's not a bug.
Share your logs (at least 10 lines)
Share your configuration