My container suddenly report a unhealthy status and after a while it stopped

[wiebereu]

Is there a pinned issue for this?

• [X] I have read the pinned issues and could not find my issue

Is there an existing or similar issue/discussion for this?

• [X] I have searched the existing issues
• [X] I have searched the existing discussions

Is there any comment in the documentation for this?

• [X] I have read the documentation, especially the FAQ and Troubleshooting parts

Is this related to a provider?

• [X] I have checked the provider repo for issues
• [X] My issue is NOT related to a provider

Are you using the latest release?

• [X] I am using the latest release

Have you tried using the dev branch latest?

• [X] I have tried using dev branch

Docker run config used

version: '2.4' services:

transmission-openvpn:
    container_name: transmission-openvpn
    image: haugene/transmission-openvpn:latest
    cap_add:
        - NET_ADMIN
    volumes:
        - /volume2/docker/transmission_ovpn/config:/config
        - /volume2/my_downloads:/downloads
        - /volume2/docker/transmission_ovpn/watch:/data/watch
        - /volume2/docker/transmission_ovpn/incomplete:/data/incomplete
        - /volume2/docker/transmission_ovpn:/data/transmission-home
    environment:
        - OPENVPN_PROVIDER=XXXXX
        - NORDVPN_COUNTRY=XXX
        - OPENVPN_USERNAME=XXXXXXXXX
        - OPENVPN_PASSWORD=XXXXXXXXX
        - LOCAL_NETWORK=192.168.X.X/24
        - OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60
        - PUID=100
        - PGID=100
        - TZ=My Timezone
    logging:
        driver: json-file
        options:
            max-size: 10m
    ports:
        - 9091:9091
        - 51413:51413
        - 51413:51413/udp
    restart: unless-stopped

Current Behavior

Since a couple of days my container is behaving very strange. It reports a unhealthy status. After a while it stopped.

I am afraid that something was changes with the last upgrade

Expected Behavior

It has a healthcheck which worked fine until a couple of days. I didn't change anything.

How have you tried to solve the problem?

I recreate the container and still the problem exist

Log output

Log is fine

Thu Jul 7 23:29:38 2022 OPTIONS IMPORT: timers and/or timeouts modified Thu Jul 7 23:29:38 2022 OPTIONS IMPORT: explicit notify parm(s) modified Thu Jul 7 23:29:38 2022 OPTIONS IMPORT: compression parms modified Thu Jul 7 23:29:38 2022 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified Thu Jul 7 23:29:38 2022 Socket Buffers: R=[212992->425984] S=[212992->425984] Thu Jul 7 23:29:38 2022 OPTIONS IMPORT: --ifconfig/up options modified Thu Jul 7 23:29:38 2022 OPTIONS IMPORT: route options modified Thu Jul 7 23:29:38 2022 OPTIONS IMPORT: route-related options modified Thu Jul 7 23:29:38 2022 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Thu Jul 7 23:29:38 2022 OPTIONS IMPORT: peer-id set Thu Jul 7 23:29:38 2022 OPTIONS IMPORT: adjusting link_mtu to 1657 Thu Jul 7 23:29:38 2022 OPTIONS IMPORT: data channel crypto options modified Thu Jul 7 23:29:38 2022 Data Channel: using negotiated cipher 'AES-256-GCM' Thu Jul 7 23:29:38 2022 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Jul 7 23:29:38 2022 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Jul 7 23:29:38 2022 ROUTE_GATEWAY 192.168.32.1/255.255.240.0 IFACE=eth0 HWADDR=02:42:c0:a8:20:02 Thu Jul 7 23:29:38 2022 TUN/TAP device tun0 opened Thu Jul 7 23:29:38 2022 TUN/TAP TX queue length set to 100 Thu Jul 7 23:29:38 2022 /sbin/ip link set dev tun0 up mtu 1500 Thu Jul 7 23:29:38 2022 /sbin/ip addr add dev tun0 10.8.1.224/16 broadcast 10.8.255.255 Thu Jul 7 23:29:38 2022 /etc/openvpn/tunnelUp.sh tun0 1500 1585 10.8.1.224 255.255.0.0 init Up script executed with tun0 1500 1585 10.8.1.224 255.255.0.0 init Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : 10.8.1.224 Updating Transmission settings.json with values from env variables Using existing settings.json for Transmission /data/transmission-home/settings.json Overriding bind-address-ipv4 because TRANSMISSION_BIND_ADDRESS_IPV4 is set to 10.8.1.224 Overriding download-dir because TRANSMISSION_DOWNLOAD_DIR is set to /downloads Overriding incomplete-dir because TRANSMISSION_INCOMPLETE_DIR is set to /data/incomplete Overriding rpc-port because TRANSMISSION_RPC_PORT is set to 9091 Overriding watch-dir because TRANSMISSION_WATCH_DIR is set to /data/watch sed'ing True to true Enforcing ownership on transmission config directories Applying permissions to transmission config directories Setting owner for transmission paths to 1026:100 Setting permissions for download and incomplete directories 2 Directories: 775 Files: 664 Setting permission for watch directory (775) and its files (664)

---

Transmission will run as

User name: abc User uid: 1026 User gid: 100

STARTING TRANSMISSION Transmission startup script complete. Thu Jul 7 23:29:38 2022 /sbin/ip route add XXXXXXXXXXXXXXXXXXXXXXX Thu Jul 7 23:29:38 2022 /sbin/ip route add 0.0.0.0/1 via 10.8.0.1 Thu Jul 7 23:29:38 2022 /sbin/ip route add 128.0.0.0/1 via 10.8.0.1 Thu Jul 7 23:29:38 2022 Initialization Sequence Completed

HW/SW Environment

- OS:
- Docker:
Docker running on my Synology NAS

Anything else?

No

[louisgrasset]

Hello @wiebereu, as written in the documentation page, you can read the following:

Set the ping-exit option for OpenVPN and restart-flag in Docker¶ Most provider configs have a ping-restart option set. So if the tunnel fails, OpenVPN will restart and re-connect. That works well on regular systems. The problem is that if the container has lost internet connection restarting OpenVPN will not fix anything. What you can do though is to set/override this option using OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60. This will tell OpenVPN to exit when it cannot ping the server for 1 minute. When OpenVPN exits, the container will exit. And if you've then set restart=always or restart=unless-stopped in your Docker config then Docker will restart the container and that could/should restore connectivity. VPN providers sometime push options to their clients after they connect. This is visible in the logs if they do. If they push ping-restart that can override your settings.

👀

So you could consider adding --pull-filter ignore ping to the options (OPENVPN_OPTS) above.

[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.

[stale[bot]]

Feel free to re-open this issue if you think it deserves another look.