Docker-transmission-openvpn: Container restart on connection failure

[haugene]

There has been some discussions on the container not restarting when the connection drops. Creating this issue to see how many are affected and find a solution.

In #438 it was pointed out that the openvpn server can override settings at the client if pull option is enabled. So all configs that have this option should maybe be updated?

Or we could write a separate checker that kills openvpn when it looses connection or dns?

[himred]

I confirm, here when the remote server dies, the container does not restart.
I use custom healthcheck and the hcd daemon to restart it.

[richardtheb]

I seem to be having this issue. The Docker container keeps running, and I can access the GUI locally as normal. But all of the trackers have failed connections. It seems to happen after I have left it running for some time. The only way I can get around it is to stop the docker container and restart it. This is with PureVPN. Not sure what else I can do to pin this one down, but ask if you need log files, etc.

[AlexWootton]

I'm seeing this issue as well. Running v2.0 of this Docker image with Windscribe as the VPN provider. It runs fine for a few days and then OpenVPN fails reporting RESOLVE: Cannot resolve host address: uk.windscribe.com:1194 (Temporary failure in name resolution). This is an error that I have faced when running OpenVPN locally so the easiest solution may be to restart the container if the VPN tunnel drops.

I am running the container with the environment variable -e "OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60" but the container is not killed when the VPN tunnel drops.

Are there any useful logs that I can provide the next time this issue occurs?

[mbarany]

Yes, this would be a nice addition. I currently have a cron on the host that just restarts the container on a daily basis, but that's more of a hack.

[IBNobody]

I am running the docker on a Synology NAS, and I use Mullvad. The OPENVPN_OPTS with the pull-filter is not restarting (same SIGUSR1 issue that kicked off this initiative). Having a second process as a kill switch would be ideal.

For reference, this is what I was setting OPENVPN_OPTS to...

-e "OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60 --pull-filter ignore \"ping\"" \

(And I've tried all sorts of variants of --pull-filter ignore ping)

[mrjackyliang]

I'm also getting a ton of cannot resolve host addresses just like @AlexWootton. My old script used to just check if the port forwarding was communicating, if not, it would restart everything.

In the meantime, I'll just do what @mbarany is doing. Even though it doesn't really solve the issue aka hacky.

I also use PureVPN like @richardtheb

[mrjackyliang]

FIX FOR #454: CONTAINER RESTART ON CONNECTION FAILURE

I have written a script for detecting the IP addresses locally and externally in addition to checking if a defined port is open. Here is the link:

https://github.com/mrjackyliang/tunnelChecker

This script works well if you have a task scheduler that runs the helper file. This is a better solution to the OpenVPN pings because VPN services have put in checks so you don't take up the connection and continue using their bandwidth.

@haugene If you have time to go over the code in my repo, you can manually merge the changes specified. The main part of this script is to install nmap which is used to detect if the seeding port is open. Everything else is pretty default.

[fongd]

I have the same issue. If I have to restart my networking config for any reason, the OpenVPN tunnel goes down but the container doesn't restart. Here are the relevant entries in my container log:

Thu Nov 21 09:22:46 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Thu Nov 21 09:23:26 2019 RESOLVE: Cannot resolve host address: vpn.server:443 (Temporary failure in name resolution)
Thu Nov 21 09:24:06 2019 RESOLVE: Cannot resolve host address: vpn.server:443 (Temporary failure in name resolution)
Thu Nov 21 09:24:06 2019 Could not determine IPv4/IPv6 protocol
Thu Nov 21 09:24:06 2019 SIGUSR1[soft,init_instance] received, process restarting
Thu Nov 21 09:24:06 2019 Restart pause, 300 second(s)

(Server hostnames intentionally changed by me.)

Doesn't look like the container is trying to restart, just the OpenVPN tunnel, which is not useful to me since it looks like the container's networking is affected so restarting OpenVPN alone would not help. FWIW, I have DNS servers set to 1.1.1.1 and 1.0.0.1 but cannot ping anything outside my LAN from the container when this happens.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

Note: The stale bot was recently added to this project to help weed out outdated issues. This will help us to focus time and energy on issues that are important and move the others out of the way. There could however be many issues that are still relevant but have gotten old without ever being fixed. As this is the first round of cleaning it might have been too eager. Feel free to re-open this issue if you think it deserves another look.

[reconman]

I just experienced the same error after letting the container run for 5 days with Torguard as VPN provider.

Wed Sep 30 19:03:44 2020 RESOLVE: Cannot resolve host address: aus.torguard.com:1912 (Temporary failure in name resolution)

[reconman]

I suggest running a https://hub.docker.com/r/willfarrell/autoheal/ container alongside transmission. Recreate the docker container with -l autoheal=true, start autoheal with

docker run -d \
    --name autoheal \
    --restart=always \
    -v /var/run/docker.sock:/var/run/docker.sock \
    willfarrell/autoheal

and the problem is solved.

I personally would add a LABEL autoheal=true line to the Dockerfile so the label is set by default. My Synology NAS doesn't support labels in their JSON format, so I had to convert my JSON representation of the container settings to a docker run command using run-like.

[haugene]

Good suggestion @reconman :+1: I'll add it. We're working towards a common way of handling .ovpn files and maybe we can then get control over the whole ping-exit and restart business. Until then (which can be a while) I think this is a good solution. Keeping this issue open so I can remember to put it in the documentation at some point :smile: