Container seems to stop immediately

[purpleladydragons]

My container seems to stop running almost immediately, and I can't tell why from the logs. I'm running on an M1 macbook and checked out v4.3.2. Does anyone have any insight?

docker run --cap-add=NET_ADMIN -d \
              -v /Users/me/torrents/:/data \
              -v /Users/me/torrents/:/config \
              -e OPENVPN_PROVIDER=NORDVPN \
              -e OPENVPN_CONFIG=US \
              -e OPENVPN_USERNAME=xxx \
              -e OPENVPN_PASSWORD=xxx \
              -e LOCAL_NETWORK=192.168.0.0/24 \
              --log-driver json-file \
              --log-opt max-size=10m \
              --sysctl net.ipv6.conf.all.disable_ipv6=0 \
              -p 9091:9091 \
              haugene/transmission-openvpn

My logs just say

Starting container with revision: b33d0fe4c938259a0d4eb844e55468f387456121
Creating TUN device /dev/net/tun
Using OpenVPN provider: NORDVPN
Running with VPN_CONFIG_SOURCE auto
Provider NORDVPN has a bundled setup script. Defaulting to internal config
Executing setup script for NORDVPN
INFO: OVPN: Checking curl installation
INFO: OVPN: DNS resolution ok

[ilike2burnthing]

See if using the NordVPN-specific settings helps - https://haugene.github.io/docker-transmission-openvpn/provider-specific/#nordvpn

[purpleladydragons]

Thank you, unfortunately I'm not getting any different results with variations on the below

docker run --cap-add=NET_ADMIN -d \
              -v /Users/me/torrents/:/data \
              -v /Users/me/torrents/:/config \
              -e OPENVPN_PROVIDER=NORDVPN \
              -e OPENVPN_CONFIG=US \
              -e OPENVPN_USERNAME=xxx \
              -e OPENVPN_PASSWORD=xxx \
              -e NORDVPN_COUNTRY=US \
              -e NORDVPN_CATEGORY=legacy_p2p \
              -e NORDVPN_PROTOCOL=tcp \
              -e NORDVPN_TESTS=3 \
              -e LOCAL_NETWORK=192.168.0.0/24 \
              --log-driver json-file \
              --log-opt max-size=10m \
              --sysctl net.ipv6.conf.all.disable_ipv6=0 \
              -p 9091:9091 \
              haugene/transmission-openvpn

I've tried adding the test flag with each possible value, and still not getting anything else in the logs

[ilike2burnthing]

You can remove OPENVPN_CONFIG as well.

Add -e DEBUG=true \, see if you get any more clarity on what's happening.

[purpleladydragons]

Thanks again - I enabled debug and got the below logs. I think things are stopping at this line since I don't see any further output despite both branches of the if/else having log

+ [[ -n b33d0fe4c938259a0d4eb844e55468f387456121 ]]
+ echo 'Starting container with revision: b33d0fe4c938259a0d4eb844e55468f387456121'
+ [[ -x /scripts/openvpn-pre-start.sh ]]
Starting container with revision: b33d0fe4c938259a0d4eb844e55468f387456121
+ compgen -e
+ grep -q OVERRIDE_DNS
+ nslookup google.com
Creating TUN device /dev/net/tun
+ [[ true == \t\r\u\e ]]
+ echo 'Creating TUN device /dev/net/tun'
+ rm -f /dev/net/tun
+ mkdir -p /dev/net
+ mknod /dev/net/tun c 10 200
+ chmod 0666 /dev/net/tun
+ VPN_PROVIDER=NORDVPN
+ export VPN_PROVIDER=nordvpn
+ VPN_PROVIDER=nordvpn
+ export VPN_PROVIDER_HOME=/etc/openvpn/nordvpn
+ VPN_PROVIDER_HOME=/etc/openvpn/nordvpn
+ mkdir -p /etc/openvpn/nordvpn
+ [[ -z '' ]]
+ [[ NORDVPN == \*\*\N\o\n\e\*\* ]]
+ [[ -z NORDVPN ]]
+ echo 'Using OpenVPN provider: NORDVPN'
+ [[ nordvpn == \c\u\s\t\o\m ]]
+ [[ -n '' ]]
+ [[ -z '' ]]
+ VPN_CONFIG_SOURCE=auto
+ VPN_CONFIG_SOURCE=auto
+ echo 'Running with VPN_CONFIG_SOURCE auto'
+ [[ auto == \a\u\t\o ]]
+ [[ -x /etc/openvpn/nordvpn/configure-openvpn.sh ]]
+ echo 'Provider NORDVPN has a bundled setup script. Defaulting to internal config'
+ VPN_CONFIG_SOURCE=internal
+ [[ internal == \e\x\t\e\r\n\a\l ]]
+ [[ -x /etc/openvpn/nordvpn/configure-openvpn.sh ]]
+ echo 'Executing setup script for NORDVPN'
+ pushd -n /
+ . /etc/openvpn/nordvpn/configure-openvpn.sh
++ set -e -u -o pipefail
++ MAIN_DIR=/etc/openvpn/..
++ [[ -f /etc/openvpn/../utils.sh ]]
++ true
++ nordvpn_api=https://api.nordvpn.com
++ nordvpn_dl=downloads.nordcdn.com
++ nordvpn_cdn=https://downloads.nordcdn.com/configs/files
++ nordvpn_doc=https://haugene.github.io/docker-transmission-openvpn/provider-specific/#nordvpn
++ possible_protocol='tcp, udp'
++ VPN_PROVIDER_HOME=/etc/openvpn/nordvpn
++ NORDVPN_COUNTRY=US
++ NORDVPN_CATEGORY=legacy_p2p
++ NORDVPN_PROTOCOL=tcp
++ NORDVPN_SERVER=us9773.nordvpn.com
++ cd /etc/openvpn
++ script_init
Using OpenVPN provider: NORDVPN
Running with VPN_CONFIG_SOURCE auto
Provider NORDVPN has a bundled setup script. Defaulting to internal config
Executing setup script for NORDVPN
++ log 'INFO: OVPN: Checking curl installation'
++ printf '%b\n' 'INFO: OVPN: Checking curl installation'
INFO: OVPN: Checking curl installation
++ script_needs curl
++ command -v curl
++ checkDNS
+++ dig +short downloads.nordcdn.com
++ res='104.17.167.30
104.17.168.30'
++ '[' -z '104.17.167.30
104.17.168.30' ']'
++ log 'INFO: OVPN: DNS resolution ok'
++ printf '%b\n' 'INFO: OVPN: DNS resolution ok'
INFO: OVPN: DNS resolution ok
++ ping -c2 downloads.nordcdn.com

[ilike2burnthing]

@edgd1er @pkishino any ideas?

[purpleladydragons]

FWIW, I added a couple more prints just before and after the ping and built my own image, and confirmed that the log just before runs, but the one just after does not

EDIT: also FWIW, I'm assuming the container stops running because docker container ls is empty. I was thinking maybe the ping was hanging waiting for a connection, but that should mean the container should stick around I think

[purpleladydragons]

I think it was an issue with Docker. I tried restarting Docker, but it gave me problems (thread here). Once I was able to restart it properly, the container is now running appropriately

Thank you for the help!

[edgd1er]

TL;DR; ping output redirected to /dev/null, bash exits on error.

Sorry to come into the conversation after resolution, I think the issue (docker could not connect with internet) joined a part of the script that could be better written.
ping has an error with an exit code not being zero. redirections the output to dev/null hides the output. the set -e asks bash to exit whenever there is an error.

docker-transmission-openvpn/openvpn/nordvpn/configure-openvpn.sh

Lines 194 to 198 in fc003b0

	ping -c2 ${nordvpn_dl} 2>&1 >/dev/null
	ret=$?
	if [ $ret -eq 0 ]; then
	log "INFO: OVPN: ok, configurations download site reachable"
	else

set -e is better than nothing, but trap errors seems to be better.
http://mywiki.wooledge.org/BashFAQ/105

So-called strict mode

In the mid 2010s, some people decided that the combination of set -e, set -u and set -o pipefail should be used by default in all new shell scripts. They call this unofficial bash strict mode, and they claim that it "makes many classes of subtle bugs impossible" and that if you follow this policy, you will "spend much less time debugging, and also avoid having unexpected complications in production".

As we've already seen in the exercises above, these claims are dubious at best. The behavior of set -e is quite unpredictable. If you choose to use it, you will have to be hyper-aware of all the false positives that can cause it to trigger, and work around them by "marking" every line that's allowed to fail with something like ||true.

Conclusions

GreyCat's personal recommendation is simple: don't use set -e. Add your own error checking instead.

rking's personal recommendation is to go ahead and use set -e, but beware of possible gotchas. It has useful semantics, so to exclude it from the toolbox is to give into FUD.

geirha's personal recommendation is to handle errors properly and not rely on the unreliable set -e.