docker-transmission-openvpn Container receives SIGTERM and exits

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

Config used

{ "alt-speed-down": 3000, "alt-speed-enabled": true, "alt-speed-time-begin": 660, "alt-speed-time-day": 127, "alt-speed-time-enabled": true, "alt-speed-time-end": 1380, "alt-speed-up": 50, "bind-address-ipv4": "10.8.8.5", "bind-address-ipv6": "::", "blocklist-enabled": false, "blocklist-url": "http://www.example.com/blocklist", "cache-size-mb": 4, "dht-enabled": true, "download-dir": "/data/Downloads", "download-limit": 100, "download-limit-enabled": 0, "download-queue-enabled": false, "download-queue-size": 5, "encryption": 1, "idle-seeding-limit": 30, "idle-seeding-limit-enabled": false, "incomplete-dir": "/data/Downloads", "incomplete-dir-enabled": true, "lpd-enabled": false, "max-peers-global": 200, "message-level": 2, "peer-congestion-algorithm": "", "peer-id-ttl-hours": 6, "peer-limit-global": 750, "peer-limit-per-torrent": 50, "peer-port": 51413, "peer-port-random-high": 65535, "peer-port-random-low": 49152, "peer-port-random-on-start": false, "peer-socket-tos": "default", "pex-enabled": true, "port-forwarding-enabled": false, "preallocation": 1, "prefetch-enabled": true, "queue-stalled-enabled": true, "queue-stalled-minutes": 30, "ratio-limit": 3, "ratio-limit-enabled": true, "rename-partial-files": true, "rpc-authentication-required": false, "rpc-bind-address": "0.0.0.0", "rpc-enabled": true, "rpc-host-whitelist": "", "rpc-host-whitelist-enabled": false, "rpc-password": "PASSWORDHERE", "rpc-port": 9091, "rpc-url": "/transmission/", "rpc-username": "USERNAMEHERE", "rpc-whitelist": "127.0.0.1", "rpc-whitelist-enabled": false, "scrape-paused-torrents-enabled": true, "script-torrent-done-enabled": false, "script-torrent-done-filename": "/data/transmission-home/watcher.py", "seed-queue-enabled": false, "seed-queue-size": 10, "speed-limit-down": 1000000, "speed-limit-down-enabled": false, "speed-limit-up": 50, "speed-limit-up-enabled": false, "start-added-torrents": true, "trash-original-torrent-files": false, "umask": 2, "upload-slots-per-torrent": 14, "utp-enabled": false, "watch-dir": "/data/watch", "watch-dir-enabled": true, "watch-dir-force-generic": false }

Current Behavior

Containers stops at random times. Usually stays up from a few hours to a day. Log shows event_wait : Interrupted system call (code=4) and SIGTERM received, sending exit notification to peer . It doesn't restart after the error.

Expected Behavior

Container keeps running or at least restarts when there's an error

How have you tried to solve the problem?

Tried previous releases (2.x, 3.x)
Recreate container, volumes and network
tried different solutions given in issues #1435 #1447 #1462
Followed troubleshooting steps from documentation

Log output

STARTING TRANSMISSION Transmission startup script complete. Thu Dec 23 10:44:17 2021 /sbin/ip route add 66.115.147.77/32 via 10.5.0.1 Thu Dec 23 10:44:17 2021 /sbin/ip route add 0.0.0.0/1 via 10.8.8.1 Thu Dec 23 10:44:17 2021 /sbin/ip route add 128.0.0.0/1 via 10.8.8.1 Thu Dec 23 10:44:17 2021 Initialization Sequence Completed Thu Dec 23 11:40:23 2021 VERIFY OK: depth=2, C=VG, O=Surfshark, CN=Surfshark Root CA Thu Dec 23 11:40:23 2021 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA Thu Dec 23 11:40:23 2021 VERIFY KU OK Thu Dec 23 11:40:23 2021 Validating certificate extended key usage Thu Dec 23 11:40:23 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Thu Dec 23 11:40:23 2021 VERIFY EKU OK Thu Dec 23 11:40:23 2021 VERIFY OK: depth=0, CN=ca-van-v018.prod.surfshark.com Thu Dec 23 11:40:23 2021 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1581' Thu Dec 23 11:40:23 2021 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM' Thu Dec 23 11:40:23 2021 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]' Thu Dec 23 11:40:23 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 11:40:23 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 11:40:23 2021 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Thu Dec 23 12:36:46 2021 VERIFY OK: depth=2, C=VG, O=Surfshark, CN=Surfshark Root CA Thu Dec 23 12:36:46 2021 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA Thu Dec 23 12:36:46 2021 VERIFY KU OK Thu Dec 23 12:36:46 2021 Validating certificate extended key usage Thu Dec 23 12:36:46 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Thu Dec 23 12:36:46 2021 VERIFY EKU OK Thu Dec 23 12:36:46 2021 VERIFY OK: depth=0, CN=ca-van-v018.prod.surfshark.com Thu Dec 23 12:36:46 2021 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1581' Thu Dec 23 12:36:46 2021 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM' Thu Dec 23 12:36:46 2021 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]' Thu Dec 23 12:36:46 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 12:36:46 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 12:36:46 2021 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Thu Dec 23 13:33:09 2021 VERIFY OK: depth=2, C=VG, O=Surfshark, CN=Surfshark Root CA Thu Dec 23 13:33:09 2021 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA Thu Dec 23 13:33:09 2021 VERIFY KU OK Thu Dec 23 13:33:09 2021 Validating certificate extended key usage Thu Dec 23 13:33:09 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Thu Dec 23 13:33:09 2021 VERIFY EKU OK Thu Dec 23 13:33:09 2021 VERIFY OK: depth=0, CN=ca-van-v018.prod.surfshark.com Thu Dec 23 13:33:09 2021 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1581' Thu Dec 23 13:33:09 2021 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM' Thu Dec 23 13:33:09 2021 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]' Thu Dec 23 13:33:09 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 13:33:09 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 13:33:09 2021 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Thu Dec 23 14:29:32 2021 VERIFY OK: depth=2, C=VG, O=Surfshark, CN=Surfshark Root CA Thu Dec 23 14:29:32 2021 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA Thu Dec 23 14:29:32 2021 VERIFY KU OK Thu Dec 23 14:29:32 2021 Validating certificate extended key usage Thu Dec 23 14:29:32 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Thu Dec 23 14:29:32 2021 VERIFY EKU OK Thu Dec 23 14:29:32 2021 VERIFY OK: depth=0, CN=ca-van-v018.prod.surfshark.com Thu Dec 23 14:29:32 2021 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1581' Thu Dec 23 14:29:32 2021 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM' Thu Dec 23 14:29:32 2021 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]' Thu Dec 23 14:29:32 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 14:29:32 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 14:29:32 2021 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Thu Dec 23 15:25:55 2021 VERIFY OK: depth=2, C=VG, O=Surfshark, CN=Surfshark Root CA Thu Dec 23 15:25:55 2021 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA Thu Dec 23 15:25:55 2021 VERIFY KU OK Thu Dec 23 15:25:55 2021 Validating certificate extended key usage Thu Dec 23 15:25:55 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Thu Dec 23 15:25:55 2021 VERIFY EKU OK Thu Dec 23 15:25:55 2021 VERIFY OK: depth=0, CN=ca-van-v018.prod.surfshark.com Thu Dec 23 15:25:55 2021 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1581' Thu Dec 23 15:25:55 2021 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM' Thu Dec 23 15:25:55 2021 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]' Thu Dec 23 15:25:55 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 15:25:55 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 15:25:55 2021 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Thu Dec 23 16:22:18 2021 VERIFY OK: depth=2, C=VG, O=Surfshark, CN=Surfshark Root CA Thu Dec 23 16:22:18 2021 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA Thu Dec 23 16:22:18 2021 VERIFY KU OK Thu Dec 23 16:22:18 2021 Validating certificate extended key usage Thu Dec 23 16:22:18 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Thu Dec 23 16:22:18 2021 VERIFY EKU OK Thu Dec 23 16:22:18 2021 VERIFY OK: depth=0, CN=ca-van-v018.prod.surfshark.com Thu Dec 23 16:22:18 2021 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1581' Thu Dec 23 16:22:18 2021 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM' Thu Dec 23 16:22:18 2021 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]' Thu Dec 23 16:22:18 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 16:22:18 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 16:22:18 2021 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Thu Dec 23 17:18:41 2021 VERIFY OK: depth=2, C=VG, O=Surfshark, CN=Surfshark Root CA Thu Dec 23 17:18:41 2021 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA Thu Dec 23 17:18:41 2021 VERIFY KU OK Thu Dec 23 17:18:41 2021 Validating certificate extended key usage Thu Dec 23 17:18:41 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Thu Dec 23 17:18:41 2021 VERIFY EKU OK Thu Dec 23 17:18:41 2021 VERIFY OK: depth=0, CN=ca-van-v018.prod.surfshark.com Thu Dec 23 17:18:41 2021 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1581' Thu Dec 23 17:18:41 2021 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM' Thu Dec 23 17:18:41 2021 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]' Thu Dec 23 17:18:41 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 17:18:41 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 17:18:41 2021 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Thu Dec 23 18:15:04 2021 VERIFY OK: depth=2, C=VG, O=Surfshark, CN=Surfshark Root CA Thu Dec 23 18:15:04 2021 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA Thu Dec 23 18:15:04 2021 VERIFY KU OK Thu Dec 23 18:15:04 2021 Validating certificate extended key usage Thu Dec 23 18:15:04 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Thu Dec 23 18:15:04 2021 VERIFY EKU OK Thu Dec 23 18:15:04 2021 VERIFY OK: depth=0, CN=ca-van-v018.prod.surfshark.com Thu Dec 23 18:15:04 2021 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1581' Thu Dec 23 18:15:04 2021 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM' Thu Dec 23 18:15:04 2021 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]' Thu Dec 23 18:15:04 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 18:15:04 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 18:15:04 2021 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Thu Dec 23 19:11:27 2021 VERIFY OK: depth=2, C=VG, O=Surfshark, CN=Surfshark Root CA Thu Dec 23 19:11:27 2021 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA Thu Dec 23 19:11:27 2021 VERIFY KU OK Thu Dec 23 19:11:27 2021 Validating certificate extended key usage Thu Dec 23 19:11:27 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Thu Dec 23 19:11:27 2021 VERIFY EKU OK Thu Dec 23 19:11:27 2021 VERIFY OK: depth=0, CN=ca-van-v018.prod.surfshark.com Thu Dec 23 19:11:27 2021 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1581' Thu Dec 23 19:11:27 2021 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM' Thu Dec 23 19:11:27 2021 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]' Thu Dec 23 19:11:27 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 19:11:27 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 19:11:27 2021 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Thu Dec 23 20:07:50 2021 VERIFY OK: depth=2, C=VG, O=Surfshark, CN=Surfshark Root CA Thu Dec 23 20:07:50 2021 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA Thu Dec 23 20:07:50 2021 VERIFY KU OK Thu Dec 23 20:07:50 2021 Validating certificate extended key usage Thu Dec 23 20:07:50 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Thu Dec 23 20:07:50 2021 VERIFY EKU OK Thu Dec 23 20:07:50 2021 VERIFY OK: depth=0, CN=ca-van-v018.prod.surfshark.com Thu Dec 23 20:07:50 2021 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1581' Thu Dec 23 20:07:50 2021 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM' Thu Dec 23 20:07:50 2021 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]' Thu Dec 23 20:07:50 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 20:07:50 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 20:07:50 2021 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Thu Dec 23 21:04:13 2021 VERIFY OK: depth=2, C=VG, O=Surfshark, CN=Surfshark Root CA Thu Dec 23 21:04:13 2021 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA Thu Dec 23 21:04:13 2021 VERIFY KU OK Thu Dec 23 21:04:13 2021 Validating certificate extended key usage Thu Dec 23 21:04:13 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Thu Dec 23 21:04:13 2021 VERIFY EKU OK Thu Dec 23 21:04:13 2021 VERIFY OK: depth=0, CN=ca-van-v018.prod.surfshark.com Thu Dec 23 21:04:13 2021 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1581' Thu Dec 23 21:04:13 2021 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM' Thu Dec 23 21:04:13 2021 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]' Thu Dec 23 21:04:13 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 21:04:13 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 21:04:13 2021 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Thu Dec 23 22:00:36 2021 VERIFY OK: depth=2, C=VG, O=Surfshark, CN=Surfshark Root CA Thu Dec 23 22:00:36 2021 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA Thu Dec 23 22:00:36 2021 VERIFY KU OK Thu Dec 23 22:00:36 2021 Validating certificate extended key usage Thu Dec 23 22:00:36 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Thu Dec 23 22:00:36 2021 VERIFY EKU OK Thu Dec 23 22:00:36 2021 VERIFY OK: depth=0, CN=ca-van-v018.prod.surfshark.com Thu Dec 23 22:00:36 2021 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1581' Thu Dec 23 22:00:36 2021 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM' Thu Dec 23 22:00:36 2021 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]' Thu Dec 23 22:00:36 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 22:00:36 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 22:00:36 2021 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Thu Dec 23 22:56:59 2021 VERIFY OK: depth=2, C=VG, O=Surfshark, CN=Surfshark Root CA Thu Dec 23 22:56:59 2021 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA Thu Dec 23 22:56:59 2021 VERIFY KU OK Thu Dec 23 22:56:59 2021 Validating certificate extended key usage Thu Dec 23 22:56:59 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Thu Dec 23 22:56:59 2021 VERIFY EKU OK Thu Dec 23 22:56:59 2021 VERIFY OK: depth=0, CN=ca-van-v018.prod.surfshark.com Thu Dec 23 22:56:59 2021 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1581' Thu Dec 23 22:56:59 2021 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM' Thu Dec 23 22:56:59 2021 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]' Thu Dec 23 22:56:59 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 22:56:59 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 22:56:59 2021 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Thu Dec 23 23:53:22 2021 VERIFY OK: depth=2, C=VG, O=Surfshark, CN=Surfshark Root CA Thu Dec 23 23:53:22 2021 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA Thu Dec 23 23:53:22 2021 VERIFY KU OK Thu Dec 23 23:53:22 2021 Validating certificate extended key usage Thu Dec 23 23:53:22 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Thu Dec 23 23:53:22 2021 VERIFY EKU OK Thu Dec 23 23:53:22 2021 VERIFY OK: depth=0, CN=ca-van-v018.prod.surfshark.com Thu Dec 23 23:53:22 2021 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1581' Thu Dec 23 23:53:22 2021 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM' Thu Dec 23 23:53:22 2021 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]' Thu Dec 23 23:53:22 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 23:53:22 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Thu Dec 23 23:53:22 2021 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Fri Dec 24 00:00:03 2021 event_wait : Interrupted system call (code=4) Fri Dec 24 00:00:03 2021 SIGTERM received, sending exit notification to peer Fri Dec 24 00:00:04 2021 /etc/openvpn/tunnelDown.sh tun0 1500 1584 10.8.8.4 255.255.255.0 init resolv.conf was restored Sending kill signal to transmission-daemon Waiting 5s for transmission-daemon to die Successfuly closed transmission-daemon Fri Dec 24 00:00:08 2021 /sbin/ip route del 66.115.147.77/32 Fri Dec 24 00:00:08 2021 /sbin/ip route del 0.0.0.0/1 Fri Dec 24 00:00:08 2021 /sbin/ip route del 128.0.0.0/1 Fri Dec 24 00:00:08 2021 Closing TUN/TAP interface Fri Dec 24 00:00:08 2021 /sbin/ip addr del dev tun0 10.8.8.4/24 Fri Dec 24 00:00:08 2021 SIGTERM[soft,exit-with-notification] received, process exiting

Environment

- OS: Arch Linux (kernel ARM 5.10.73)
- Docker: 20.10.9

Anything else?

No response

Dec 29 '21 00:12 Kaisbn

Well,
I don't know what your docker container config as I only see the transmissions config above. What is your restart-policy set to? If you have it set to restart-always then it seems your docker is not responding to the process exit signal. This looks like platform dependent or provider issue that triggers the event_wait

Dec 29 '21 02:12 pkishino

had the same issue here, it's on a synology running the latest DSM 7, something changed with the last 2 DSM security patches as it started acting up after that. log entry was indeed: SIGTERM[soft,exit-with-notification] received, process exiting was running with --restart=unless-stopped, have changed that now into --restart=always to see if it at least restarts now P.S. had to toggle the high privilege setting in the docker GUI to get it to work (we have seen issues with this before) while with previous DSM (pre 2 latest patches) this was not needed anyway more testing on-going...

current test config: sudo docker run -d --restart=always \ --cap-add=NET_ADMIN \ --privileged \ --dns 1.1.1.1 \ --dns 1.0.0.1 \ --dns 8.8.8.8 \ -v /volume1/blablalbla/:/data \ -e "CREATE_TUN_DEVICE=true" \ -e "OPENVPN_PROVIDER=something" \ -e "OPENVPN_CONFIG=something" \ -e "OPENVPN_USERNAME=username" \ -e "OPENVPN_PASSWORD=password" \ -e "LOCAL_NETWORK=IPGOESHERE/24" \ -e "OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60" \ -e "PGID=100" \ -e "PUID=1024" \ -e "WEBPROXY_ENABLED=true" \ -e "WEBPROXY_PORT=8888" \ -e "ENABLE_UFW=true" \ -e "UFW_DISABLE_IPTABLES_REJECT=true" \ -e "TRANSMISSION_HOME=/datablabla" \ -e "TRANSMISSION_DOWNLOAD_DIR=/data/completed" \ -e "TRANSMISSION_INCOMPLETE_DIR=/data/incomplete" \ -e "TRANSMISSION_WATCH_DIR=/data/watch" \ -e "TRANSMISSION_UTP_ENABLED=true" \ -e "TZ=somewhere" \ --log-driver json-file \ --log-opt max-size=10m \ -p 9091:9091 \ -p 8888:8888 \ --name "transmission-openvpn-syno" \ haugene/transmission-openvpn:latest

Jan 16 '22 08:01 jester-xbmc

Hi team,

I'm facing the exact same issue on a Synology DS1019+. I have 2 dockers running in parallel and they both stops time to time. Funny enough they stop at a couple of hours apart from each other (from 1 to 6 hours max from what I've noticed). They both restart fine. I'm running the latest version of docker-transmission-openvpn and latest version of the Synology DSM.

The biggest issue for me is that once the container restart, Transmission automatically rescan ALL my torrent and it takes days (a couple of TB here)!!! I guess maybe the container is stopped abruptly causing some I/O errors in some files... Is there a way to correct it so Transmission doesn't rescan all my torrent please?

Am I missing something?

Here are my logs:

Tue Feb  1 00:50:11 2022 VERIFY OK: depth=2, C=VG, O=Surfshark, CN=Surfshark Root CA
Tue Feb  1 00:50:11 2022 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA
Tue Feb  1 00:50:11 2022 VERIFY KU OK
Tue Feb  1 00:50:11 2022 Validating certificate extended key usage
Tue Feb  1 00:50:11 2022 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Tue Feb  1 00:50:11 2022 VERIFY EKU OK
Tue Feb  1 00:50:11 2022 VERIFY OK: depth=0, CN=sg-sng-v046.prod.surfshark.com
Tue Feb  1 00:50:12 2022 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1635', remote='link-mtu 1583'
Tue Feb  1 00:50:12 2022 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM'
Tue Feb  1 00:50:12 2022 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]'
Tue Feb  1 00:50:12 2022 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Feb  1 00:50:12 2022 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Feb  1 00:50:12 2022 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Tue Feb  1 00:57:10 2022 Connection reset, restarting [0]
Tue Feb  1 00:57:10 2022 /etc/openvpn/tunnelDown.sh tun0 1500 1586 10.7.7.6 255.255.255.0 init
resolv.conf was restored
Sending kill signal to transmission-daemon
Successfuly closed transmission-daemon
Tue Feb  1 00:57:12 2022 /sbin/ip route del 89.187.163.210/32
Tue Feb  1 00:57:12 2022 /sbin/ip route del 0.0.0.0/1
Tue Feb  1 00:57:12 2022 /sbin/ip route del 128.0.0.0/1
Tue Feb  1 00:57:12 2022 Closing TUN/TAP interface
Tue Feb  1 00:57:12 2022 /sbin/ip addr del dev tun0 10.7.7.6/24
Tue Feb  1 00:57:12 2022 SIGTERM[soft,connection-reset] received, process exiting

Thank you for your support!

Feb 02 '22 15:02 Hebusing

@Hebusing are you using two of the same container using the same transmission-home? either your permissions are not correct or, if you are using two instances, they are invalidating the hashes etc..thats why it will re-scan. also, read the Discussion around the 4.0 update.. torrents that were used in the previous 3.7 will need to be deleted and re-added in 4.0 as the transmission version changed.rest is in the discussion topic on how to fix/work around

Feb 03 '22 00:02 pkishino

@pkishino, Thank you for your reply. Not sure I understand your question, sorry. I have created 2 containers from the same image (haugene/transmission-openvpn:latest): one is used to "download" and the other one only to "seed". They are using different ports and parameters but are sharing the same OPENVPN_USERNAME, OPENVPN_PASSWORD and OPENVPN_PROVIDER. Both containers could run for a couple of days. For the "seed" one, all torrents have been fully scanned and seeding is happening. For the "download" one, it is usually empty as soon as the download ends. I will check in details the conversation on 4.0 update, but as the "download" one also crashes and as the "seed" one works for a couple of days I am not sure if that is the issue.

Feb 03 '22 02:02 Hebusing

I am also experiencing this issue since the latest Synology DSM update. Something seems to have broken in compatibility with Synology completely. This is not an auto-restart problem, if you turn that off it just stops, period. There is something that is causing the container to exit improperly because something won't execute when it goes to execute some code and it crashes out. Even running the container with the highest privileges does not correct this issue. Synology broke something here.

Feb 18 '22 02:02 RapidRabbit-11485

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

Apr 19 '22 07:04 stale[bot]

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

Apr 27 '22 10:04 stale[bot]

I've been having this issue for a while and I can't track down the cause.

Reserved Port: 23737  Thu Jun  2 09:17:28 UTC 2022
Reserved Port: 23737  Thu Jun  2 09:32:28 UTC 2022
Reserved Port: 23737  Thu Jun  2 09:47:28 UTC 2022
Reserved Port: 23737  Thu Jun  2 10:02:29 UTC 2022
Reserved Port: 23737  Thu Jun  2 10:17:29 UTC 2022
Reserved Port: 23737  Thu Jun  2 10:32:29 UTC 2022
Reserved Port: 23737  Thu Jun  2 10:47:29 UTC 2022
Thu Jun  2 10:49:16 2022 event_wait : Interrupted system call (code=4)
Thu Jun  2 10:49:16 2022 /etc/openvpn/tunnelDown.sh tun0 1500 1553 10.4.112.154 255.255.255.0 init
resolv.conf was restored
Sending kill signal to transmission-daemon
Waiting 5s for transmission-daemon to die
Successfuly closed transmission-daemon
Thu Jun  2 10:49:19 2022 /sbin/ip route del 143.244.52.5/32
Thu Jun  2 10:49:19 2022 /sbin/ip route del 0.0.0.0/1

From what I can tell, it's when I download at full speed (12 MB/s). It's almost like something is getting overwhelmed. This might also be because the only time I notice the issue is when I'm using it. It does also fail my docker healthcheck.

version: "3.8"

services:
  transmission-openvpn:
    image: haugene/transmission-openvpn:latest
    container_name: transmission-openvpn
    volumes:
      - /tempvol/service/transmission:/data
      - /tempvol/downloads:/downloads
    environment:
      - CREATE_TUN_DEVICE=true
      - HEALTH_CHECK_HOST=google.com
      - OPENVPN_PROVIDER=PIA
      - OPENVPN_CONFIG=netherlands,switzerland,romania
      - PIA_OPENVPN_CONFIG_BUNDLE=openvpn  # https://github.com/haugene/docker-transmission-openvpn/issues/1548
      - OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60 --pull-filter ignore ping
      - OPENVPN_USERNAME=${TRANSMISSION_OPENVPN_USERNAME}
      - OPENVPN_PASSWORD=${TRANSMISSION_OPENVPN_PASSWORD}
      - WEBPROXY_ENABLED=true  # allow other containers to use openvpn
      - WEBPROXY_PORT=8888
      - LOCAL_NETWORK=192.168.0.0/16
      - TRANSMISSION_RPC_HOST_WHITELIST="127.0.0.1,192.168.*.*"
      - TRANSMISSION_DOWNLOAD_DIR=/downloads/complete
      - TRANSMISSION_INCOMPLETE_DIR=/downloads/incomplete
      - TRANSMISSION_INCOMPLETE_DIR_ENABLED=true
      - TRANSMISSION_IDLE_SEEDING_LIMIT=60
      - TRANSMISSION_IDLE_SEEDING_LIMIT_ENABLED=true
      - TRANSMISSION_RATIO_LIMIT=10
      - TRANSMISSION_RATIO_LIMIT_ENABLED=true
      - TRANSMISSION_ALT_SPEED_ENABLED=true
      - TRANSMISSION_ALT_SPEED_TIME_ENABLED=true
      - TRANSMISSION_ALT_SPEED_DOWN=4096
      - TRANSMISSION_ALT_SPEED_UP=1024
      - TRANSMISSION_ALT_SPEED_TIME_BEGIN=710
      - TRANSMISSION_ALT_SPEED_TIME_END=60
      - TRANSMISSION_BLOCKLIST_ENABLED=true
      # - TRANSMISSION_BLOCKLIST_URL="https://github.com/ttgapers/transmission-blocklist/releases/latest/download/blocklist.gz"
      - TRANSMISSION_DHT_ENABLED=true
      - TRANSMISSION_PEX_ENABLED=true
      - TRANSMISSION_LDP_ENABLED=false #Local broadcast
      - TRANSMISSION_ENCRYPTION=0 #Who cares if anon over a vpn
      #- TRANSMISSION_MAX_PEERS_GLOBAL=100
      #- TRANSMISSION_PEER_LIMIT_GLOBAL=20
      #- TRANSMISSION_PEER_LIMIT_PER_TORRENT=500
      - TRANSMISSION_DOWNLOAD_QUEUE_ENABLED=true
      - TRANSMISSION_DOWNLOAD_QUEUE_SIZE=10
    cap_add:
      - NET_ADMIN
    dns:
      - 1.1.1.1
      - 1.0.0.1
    healthcheck:
      test: ["CMD", "curl", "-fL", "http://127.0.0.1:9091"]
      interval: 2s
      timeout: 3s
      retries: 3
      start_period: 10s
    security_opt:
      - no-new-privileges:true
    ulimits:
      nofile:
        soft: 65536
        hard: 65536 # Fixes too many open files error
    depends_on:
      - traefik
    labels:
      - "traefik.enable=true"
      # HTTP Routers
      - "traefik.http.routers.torrent.rule=Host(`transmission.${DOMAIN}`)"
      - "traefik.http.services.torrent.loadbalancer.server.port=9091"
      - "traefik.http.routers.torrent.entrypoints=https"
    restart: always

I'm not sure how else I can troubleshoot it.

Jun 02 '22 11:06 francis-io

I've been having the same issue for a while now as well. It just keeps dieing.

Jun 04 '22 23:06 ryancurrah

I have the same issue. Seeding works just fine, but once I turn on any download whole docker engine just stops almost immediately. I am on macOS.

Jan 07 '23 06:01 Inalkar

I have this issue as well. I am using HIDEME, and I have been trying to troubleshoot this. Docker version 4.15.0 (93002)

Jan 09 '23 18:01 delusive

This issue is still relevant on Synology NAS:

2023-05-30 11:53:59 [Xuange] Inactivity timeout (--ping-restart), restarting
2023-05-30 11:53:59 SIGTERM received, sending exit notification to peer
2023-05-30 11:54:04 /etc/openvpn/tunnelDown.sh tun0 1500 1553 10.9.232.194 255.255.255.0 init
resolv.conf was restored
Sending kill signal to transmission-daemon
Successfuly closed transmission-daemon
2023-05-30 11:54:05 net_route_v4_del: 79.142.69.159/32 via 172.21.0.1 dev [NULL] table 0 metric -1
2023-05-30 11:54:05 net_route_v4_del: 0.0.0.0/1 via 10.9.232.1 dev [NULL] table 0 metric -1
2023-05-30 11:54:05 net_route_v4_del: 128.0.0.0/1 via 10.9.232.1 dev [NULL] table 0 metric -1
2023-05-30 11:54:05 Closing TUN/TAP interface
2023-05-30 11:54:05 net_addr_v4_del: 10.9.232.194 dev tun0
2023-05-30 11:54:05 SIGTERM[soft,exit-with-notification] received, process exiting

May 31 '23 07:05 Bogey

I have the same issue as well (Synology Nas). I'd suggest reopening the issue. Thanks 👍

Jun 04 '23 19:06 willhoag

Any news or hints/suggestions to fix or help fixing this? Latest image 5.0.2 still shuts down (exits after SIGTERM).

Jun 23 '23 05:06 Bogey

possible causes: https://www.sparklabs.com/support/kb/article/error-inactivity-timeout-ping-restart/

what to do: contact your vpn provider.

Jun 23 '23 06:06 edgd1er

I found that whenever internet connection is lost, the transmission container stops. It doesn’t matter if it’s a brief interruption caused by modem, router or cable in/out. This didn’t happen with v4.

Jul 28 '23 07:07 Bogey

I found that whenever internet connection is lost, the transmission container stops. It doesn’t matter if it’s a brief interruption caused by modem, router or cable in/out. This didn’t happen with v4.

Please collect logs then from v4 and v5 to compare

Jul 28 '23 10:07 pkishino

All fixed: changed restart: 5 to always. My apologies.

Aug 08 '23 20:08 Bogey

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

Oct 15 '23 15:10 stale[bot]

Same for me, set up kubernetes pod, after removing pod, but keeping PVC, transmission shows 0 torrents, thus there are plenty in download dirl.

Dec 07 '23 19:12 jakubauskas

Also found that downgrading to v4 stops it from happening Unfortunately I can't see much different in the logs other than it doesn't get a SIGTERM and it doesn't restart, so nothing that would be useful for diagnosing issues. I'm using NordVPN, for reference.

Dec 11 '23 13:12 StormPooper

This issue is still relevant on Synology NAS:

2023-05-30 11:53:59 [Xuange] Inactivity timeout (--ping-restart), restarting
2023-05-30 11:53:59 SIGTERM received, sending exit notification to peer
2023-05-30 11:54:04 /etc/openvpn/tunnelDown.sh tun0 1500 1553 10.9.232.194 255.255.255.0 init
resolv.conf was restored
Sending kill signal to transmission-daemon
Successfuly closed transmission-daemon
2023-05-30 11:54:05 net_route_v4_del: 79.142.69.159/32 via 172.21.0.1 dev [NULL] table 0 metric -1
2023-05-30 11:54:05 net_route_v4_del: 0.0.0.0/1 via 10.9.232.1 dev [NULL] table 0 metric -1
2023-05-30 11:54:05 net_route_v4_del: 128.0.0.0/1 via 10.9.232.1 dev [NULL] table 0 metric -1
2023-05-30 11:54:05 Closing TUN/TAP interface
2023-05-30 11:54:05 net_addr_v4_del: 10.9.232.194 dev tun0
2023-05-30 11:54:05 SIGTERM[soft,exit-with-notification] received, process exiting

Same for me all of a sudden,

2023-12-12 09:48:02 [PrivateVPN] Inactivity timeout (--ping-exit), exiting
2023-12-12 09:48:02 SIGTERM received, sending exit notification to peer
2023-12-12 09:48:04 /etc/openvpn/tunnelDown.sh tun0 1500 1553 10.35.14.69 255.255.254.0 init
resolv.conf was restored
Sending kill signal to transmission-daemon
Waiting 5s for transmission-daemon to die
Sending kill signal (SIGKILL) to transmission-daemon

Dec 12 '23 07:12 Silversurfer79

I also noticed my blocklist works again on version 4.3.2

Dec 12 '23 08:12 Silversurfer79

This issue is still relevant on Synology NAS:

2023-05-30 11:53:59 [Xuange] Inactivity timeout (--ping-restart), restarting
2023-05-30 11:53:59 SIGTERM received, sending exit notification to peer
2023-05-30 11:54:04 /etc/openvpn/tunnelDown.sh tun0 1500 1553 10.9.232.194 255.255.255.0 init
resolv.conf was restored
Sending kill signal to transmission-daemon
Successfuly closed transmission-daemon
2023-05-30 11:54:05 net_route_v4_del: 79.142.69.159/32 via 172.21.0.1 dev [NULL] table 0 metric -1
2023-05-30 11:54:05 net_route_v4_del: 0.0.0.0/1 via 10.9.232.1 dev [NULL] table 0 metric -1
2023-05-30 11:54:05 net_route_v4_del: 128.0.0.0/1 via 10.9.232.1 dev [NULL] table 0 metric -1
2023-05-30 11:54:05 Closing TUN/TAP interface
2023-05-30 11:54:05 net_addr_v4_del: 10.9.232.194 dev tun0
2023-05-30 11:54:05 SIGTERM[soft,exit-with-notification] received, process exiting

Same for me all of a sudden,

2023-12-12 09:48:02 [PrivateVPN] Inactivity timeout (--ping-exit), exiting
2023-12-12 09:48:02 SIGTERM received, sending exit notification to peer
2023-12-12 09:48:04 /etc/openvpn/tunnelDown.sh tun0 1500 1553 10.35.14.69 255.255.254.0 init
resolv.conf was restored
Sending kill signal to transmission-daemon
Waiting 5s for transmission-daemon to die
Sending kill signal (SIGKILL) to transmission-daemon

expected behaviour of the container when openvpn has lat connection, transmission is stopped, and so is the container. Ask your provider to provide a stable connection or filter out timeout options and end up with a staled container.

Dec 12 '23 20:12 edgd1er

I also noticed my blocklist works again on version 4.3.2

image v4 has transmission v3, image v5 has transmission v4, 3 years between the two transmission versions, many things may have been changed.

as stated in docs: https://github.com/transmission/transmission/blob/main/docs/Blocklists.md

What blocklist does Transmission use?

Transmission supports the P2P plaintext format, which is used by PeerGuardian, Bluetack, Vuze, ProtoWall, and KTorrent, and the DAT format, which was originally made popular by eMule.

an issue already opened for that subject: https://github.com/haugene/docker-transmission-openvpn/issues/1162

Dec 12 '23 20:12 edgd1er

I am also experiencing this issue since the latest Synology DSM update. Something seems to have broken in compatibility with Synology completely. This is not an auto-restart problem, if you turn that off it just stops, period. There is something that is causing the container to exit improperly because something won't execute when it goes to execute some code and it crashes out. Even running the container with the highest privileges does not correct this issue. Synology broke something here.

Same for me, runs few seconds gets slower and then stops. Container crashes, starts up after a few and the same thing.

Dec 12 '23 21:12 Silversurfer79

How do we move forward from here? How do we fix this? Its clear its a Synology Nas update casuing the issue. Do we start login tickets with Synology?

Dec 13 '23 19:12 Silversurfer79

I'm also having the same issue and I'm not using a Synology NAS. It's a custom x86 setup running Debian. Here's my log snippet:

STARTING TRANSMISSION
Transmission startup script complete.
2023-12-29 18:45:41 Initialization Sequence Completed

2023-12-29 18:48:38 event_wait : Interrupted system call (code=4)
2023-12-29 18:48:38 /etc/openvpn/tunnelDown.sh tun0 1500 1659 10.7.2.12 255.255.255.0 init
resolv.conf was restored
Sending kill signal to transmission-daemon
Waiting 5s for transmission-daemon to die
Sending kill signal (SIGKILL) to transmission-daemon
2023-12-29 18:48:43 net_route_v4_del: 185.153.179.128/32 via 172.18.0.1 dev [NULL] table 0 metric -1
2023-12-29 18:48:43 net_route_v4_del: 0.0.0.0/1 via 10.7.2.1 dev [NULL] table 0 metric -1
2023-12-29 18:48:43 net_route_v4_del: 128.0.0.0/1 via 10.7.2.1 dev [NULL] table 0 metric -1
2023-12-29 18:48:43 Closing TUN/TAP interface
2023-12-29 18:48:43 net_addr_v4_del: 10.7.2.12 dev tun0
2023-12-29 18:48:43 SIGTERM[hard,] received, process exiting

It's always just shy of 3 minutes. I even disabled AutoHeal, because I noticed that the container becomes unhealthy for a moment before it exits. So my question is does anyone have any idea how to determine what systemcall is failing? I tried the debug flag and it didn't help.

I've also ensure that my VPN credentials are good (NordVPN) and even sanity checked by entering the wrong password and the container failed right away. I also bashed into the container and checked connectivity and it's definitely going through the VPN since it has a different IP. For good measure, I also manually assigned the DNS 1.1.1.1 and it made no difference.

I'm out of ideas and thinking of having a separate VPN container and using the regular Transmission instance.

Dec 30 '23 01:12 skrenes

I’d suggest trying with a different provider (just get a trial amount or such) for a bit and see if that makes a difference. Otherwise I suspect some underlying fault in the openvpn library or such used..

On Sat, 30 Dec 2023 at 10:55, Arsham Skrenes @.***> wrote:

I'm also having the same issue and I'm not using a Synology NAS. It's a custom x86 setup running Debian. Here's my log snippet:

STARTING TRANSMISSION Transmission startup script complete. 2023-12-29 18:45:41 Initialization Sequence Completed

2023-12-29 18:48:38 event_wait : Interrupted system call (code=4) 2023-12-29 18:48:38 /etc/openvpn/tunnelDown.sh tun0 1500 1659 10.7.2.12 255.255.255.0 init resolv.conf was restored Sending kill signal to transmission-daemon Waiting 5s for transmission-daemon to die Sending kill signal (SIGKILL) to transmission-daemon 2023-12-29 18:48:43 net_route_v4_del: 185.153.179.128/32 via 172.18.0.1 dev [NULL] table 0 metric -1 2023-12-29 18:48:43 net_route_v4_del: 0.0.0.0/1 via 10.7.2.1 dev [NULL] table 0 metric -1 2023-12-29 18:48:43 net_route_v4_del: 128.0.0.0/1 via 10.7.2.1 dev [NULL] table 0 metric -1 2023-12-29 18:48:43 Closing TUN/TAP interface 2023-12-29 18:48:43 net_addr_v4_del: 10.7.2.12 dev tun0 2023-12-29 18:48:43 SIGTERM[hard,] received, process exiting

It's always just shy of 3 minutes. I even disabled AutoHeal, because I noticed that the container becomes unhealthy for a moment before it exits. So my question is does anyone have any idea how to determine what systemcall is failing? I tried the debug flag and it didn't help.

I've also ensure that my VPN credentials are good (NordVPN) and even sanity checked by entering the wrong password and the container failed right away. I also bashed into the container and checked connectivity and it's definitely going through the VPN since it has a different IP. For good measure, I also manually assigned the DNS 1.1.1.1 and it made no difference.

I'm out of ideas and thinking of having a separate VPN container and using the regular Transmission instance.

— Reply to this email directly, view it on GitHub https://github.com/haugene/docker-transmission-openvpn/issues/2130#issuecomment-1872424576, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7OFYTM6UPHTTNZJ7RND73YL5YAFAVCNFSM5K466LN2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBXGI2DENBVG43A . You are receiving this because you modified the open/close state.Message ID: @.*** com>

Dec 30 '23 01:12 pkishino

docker-transmission-openvpn docker-transmission-openvpn copied to clipboard

Container receives SIGTERM and exits

Is there a pinned issue for this?

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

Is there any comment in the documentation for this?

Is this related to a provider?

Are you using the latest release?

Have you tried using the dev branch latest?

Config used

Current Behavior

Expected Behavior

How have you tried to solve the problem?

Log output

Environment

Anything else?

docker-transmission-openvpn
docker-transmission-openvpn copied to clipboard