Describe the problem
I have been running this container for more than a year without issue. However recently, the container has started exited shortly after booting.
Add your docker run command
See above, however, I am using the following docker-compose.yml:
version: '3.5'
services:
transmission:
image: haugene/transmission-openvpn:latest
container_name: transmission
hostname: transmission
privileged: true
env_file:
- ./.env
dns:
- 8.8.8.8
- 8.8.4.4
volumes:
- ${DIR_MOUNT}/config:/config
- ${DIR_MOUNT}:/data
restart: unless-stopped
networks:
default:
external:
name: homeserver
Logs
$ docker-compose up --build --force-recreate
Recreating transmission ... done
Attaching to transmission
transmission | Using OpenVPN provider: PIA
transmission | Starting OpenVPN using config US Seattle.ovpn
transmission | Setting OPENVPN credentials...
transmission | adding route to local network 192.168.1.0/24 via 172.18.0.1 dev eth0
transmission | Fri Jul 17 10:18:00 2020 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 5 2019
transmission | Fri Jul 17 10:18:00 2020 library versions: OpenSSL 1.1.1c 28 May 2019, LZO 2.10
transmission | Fri Jul 17 10:18:00 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
transmission | Fri Jul 17 10:18:00 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]104.200.154.22:1198
transmission | Fri Jul 17 10:18:00 2020 UDP link local: (not bound)
transmission | Fri Jul 17 10:18:00 2020 UDP link remote: [AF_INET]104.200.154.22:1198
transmission | Fri Jul 17 10:19:01 2020 [UNDEF] Inactivity timeout (--ping-exit), exiting
transmission | Fri Jul 17 10:19:01 2020 SIGTERM[soft,ping-exit] received, process exiting
Host system:
MacOS 10.13.16 (High Sierra)
Upon further investigation, this looks to be specifically tied to the US Seattle region provided by PIA. Im able to connect from my host system, but for whatever reason, it times out thru the container.
I have swapped regions and added a couple more to the list. Hopefully this will resolve.
Thanks!
Upon further investigation, this looks to be specifically tied to the US Seattle region provided by PIA. Im able to connect from my host system, but for whatever reason, it times out thru the container.
I have swapped regions and added a couple more to the list. Hopefully this will resolve.
Thanks!
Aaron, was this behavior simply the container crashing after failing/succeeding in getting a port from PIA?
I've been having terrible luck with the ARM variant trying to get it running, with it exiting and rarely giving an exit code.
That's correct. I had only a single VPN server specified, it would crash majority of the time, reboot, and crash again.
I log output I provided in my original post is the entirety of the output from start to exit.
Changing VPN server regions, and adding a couple more did the trick. I'm assuming it's something with the Seattle US server specifically - what that might be however is anyone's guess.
That's very odd. I've tried all three of canada and a different provider entirely (used both PIA and IPVANISH) and it just seems unable to sort itself out. It's crashing sometimes at initialization sequence complete, sometimes at Checking Port, sometimes it doesn't get a port.
I'm running the ARMHF version and having extreme troubles getting this to stay running.
Scratch it all, qnap has a service running that scans and kills openvpn connections (it literally searches processes for "openvpn" and kills them) following a guide to disable it worked.
For those interested or seeing a similar issue, the fix (for qnap NAS's) is at the bottom of this reddit post:
https://www.reddit.com/r/qnap/comments/e2nmxl/guide_torrent_downloading_behind_vpn_using/
@haugene is it possible to add a FAQ entry stating "Some QNAP... Automatically Killing Anything with a process name Openvpn, etc?" I can probably write a blurb just in case others come across this.
Sure, I think the wiki is editable by anyone. Would be good to add as you said ;) thanks
Hi @Go2ClassPoorYorick @pkishino - I couldn’t find anything on the wiki around QNAP, although there is a dedicated section for Synology. Is there a QNAP section being worked on ? Seems there has been comments/issues raised before , but nothing definitive- https://github.com/haugene/docker-transmission-openvpn/issues/172
Hi @Go2ClassPoorYorick @pkishino - I couldn’t find anything on the wiki around QNAP, although there is a dedicated section for Synology. Is there a QNAP section being worked on ? Seems there has been comments/issues raised before , but nothing definitive- #172
Sorry, I've been a tad busy and hadn't revisited this project this week to write the detailed explanation. The solution to my described problem is detailed in the site linked above.
Scratch it all, qnap has a service running that scans and kills openvpn connections (it literally searches processes for "openvpn" and kills them) following a guide to disable it worked.
For those interested or seeing a similar issue, the fix (for qnap NAS's) is at the bottom of this reddit post:
https://www.reddit.com/r/qnap/comments/e2nmxl/guide_torrent_downloading_behind_vpn_using/
@haugene is it possible to add a FAQ entry stating "Some QNAP... Automatically Killing Anything with a process name Openvpn, etc?" I can probably write a blurb just in case others come across this.
This has literally resolved an issue for me that I've been struggling with for months with my QNAP, both with NordVPN and Giganews/VyprVPN. I did notice a very interesting detail... As I modified the config file to remove the script that kills off OpenVPN connections, and uninstalled QNAP's QVPN service app, two things happened after I rebooted the NAS:
1. The path to docker executable disappeared, and after some searching I figured out where docker is buried within QNAP's container station, and added it to the PATH.
2. QNAP's QVPN service+app automatically were reinstalled upon reboot. Very odd behavior. I did check the config file to make sure that the service is not started anymore to hunt down my OpenVPN tunnels in the system, and now my container is very happy and chugging along.
In short, a quick little FAQ entry pointing to the reddit post here helped me tremendously. Hoping that this is a permanent fix.
Hi @webnetwiz
Just to be absolutely sure, is this what you mean ?
Q13. I can see from the '/config/supervisord.log' file that the openvpn process keeps getting killed every 30 seconds on my QNAP appliance, what could be the cause of this?
A13. For some reason (unknown at this time) QNAP decided to kill any openvpn process running on the host by adding in a line to the 'daemon_mgr.conf' file. In order to prevent this you need to delete the following line from the 'daemon_mgr.conf':-
DAEMONxx = openvpn, stop, /usr/sbin/openvpn
Where xx will be 2 random digits.‘
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.
Feel free to re-open this issue if you think it deserves another look.
Most helpful comment
Scratch it all, qnap has a service running that scans and kills openvpn connections (it literally searches processes for "openvpn" and kills them) following a guide to disable it worked.
For those interested or seeing a similar issue, the fix (for qnap NAS's) is at the bottom of this reddit post:
https://www.reddit.com/r/qnap/comments/e2nmxl/guide_torrent_downloading_behind_vpn_using/
@haugene is it possible to add a FAQ entry stating "Some QNAP... Automatically Killing Anything with a process name Openvpn, etc?" I can probably write a blurb just in case others come across this.