Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Container receives SIGTERM and exits #2130

Open
8 tasks done
Kaisbn opened this issue Dec 29, 2021 · 46 comments
Open
8 tasks done

Container receives SIGTERM and exits #2130

Kaisbn opened this issue Dec 29, 2021 · 46 comments

Comments

@Kaisbn
Copy link

Kaisbn commented Dec 29, 2021

Is there a pinned issue for this?

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

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

  • I have searched the existing issues
  • I have searched the existing discussions

Is there any comment in the documentation for this?

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

Is this related to a provider?

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

Are you using the latest release?

  • I am using the latest release

Have you tried using the dev branch latest?

  • 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?

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
@pkishino
Copy link
Collaborator

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

@jester-xbmc
Copy link

jester-xbmc commented Jan 16, 2022 •
edited
Loading

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

@tim0901 tim0901 mentioned this issue Jan 30, 2022
Closed
8 tasks
@Hebusing
Copy link

Hebusing commented Feb 2, 2022

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!

@pkishino
Copy link
Collaborator

pkishino commented Feb 3, 2022

@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

@Hebusing
Copy link

Hebusing commented Feb 3, 2022

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

@RapidRabbit-11485
Copy link

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.

@stale
Copy link

stale bot commented Apr 19, 2022

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 stale bot added the inactivity Used by Stale bot to mark issues that will be closed label Apr 19, 2022
@stale
Copy link

stale bot commented Apr 27, 2022

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

@stale stale bot closed this as completed Apr 27, 2022
@francis-io
Copy link

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.

@ryancurrah
Copy link

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

@Inalkar
Copy link

Inalkar commented Jan 7, 2023

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.

@delusive
Copy link

delusive commented Jan 9, 2023

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

@Bogey
Copy link

Bogey commented May 31, 2023

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

@willhoag
Copy link

willhoag commented Jun 4, 2023 •
edited
Loading

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

@pkishino pkishino reopened this Jun 5, 2023
@stale stale bot removed the inactivity Used by Stale bot to mark issues that will be closed label Jun 5, 2023
@Bogey
Copy link

Bogey commented Jun 23, 2023

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

@edgd1er
Copy link
Contributor

edgd1er commented Jun 23, 2023 •
edited
Loading

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

what to do: contact your vpn provider.

@Bogey
Copy link

Bogey commented Jul 28, 2023

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.

@pkishino
Copy link
Collaborator

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

@Bogey
Copy link

Bogey commented Aug 8, 2023

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

@pkishino pkishino mentioned this issue Sep 10, 2023
Closed
8 tasks
@stale
Copy link

stale bot commented Oct 15, 2023

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 stale bot added the inactivity Used by Stale bot to mark issues that will be closed label Oct 15, 2023
@jakubauskas
Copy link

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

@stale stale bot removed the inactivity Used by Stale bot to mark issues that will be closed label Dec 7, 2023
@StormPooper
Copy link

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.

@Silversurfer79
Copy link

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

@Silversurfer79
Copy link

I also noticed my blocklist works again on version 4.3.2
image

@edgd1er
Copy link
Contributor

edgd1er commented Dec 12, 2023

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.

@edgd1er
Copy link
Contributor

edgd1er commented Dec 12, 2023

I also noticed my blocklist works again on version 4.3.2 image

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: #1162

@Silversurfer79
Copy link

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.

@Silversurfer79
Copy link

Silversurfer79 commented Dec 13, 2023 •
edited
Loading

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?

@skrenes
Copy link

skrenes commented Dec 30, 2023

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.

@pkishino
Copy link
Collaborator

pkishino commented Dec 30, 2023 via email

@skrenes
Copy link

skrenes commented Dec 30, 2023

Thanks @pkishino. You lead me down the path of some more code sleuthing and after days of struggling with this on and off, I decided to define the NORDVPN_COUNTRY value that was being complained about in the logs and it worked!

So my suggestion for everyone is to read your logs carefully and define anything that the logs are complaining about. In my case this was NORDVPN_CATEGORY and NORDVPN_COUNTRY. This wasn't a problem before but something I'll keep in mind if things break again.

@StormPooper
Copy link

Unfortunately @skrenes's suggestion of setting the additional NORDVPN variables didn't help me as they were already set. However, their previous comment mentioning Autoheal solved it for me - the health check was failing, so Autoheal was restarting the container - this is why there was nothing in the container logs before the SIGTERM, as it was Autoheal triggering it. Now the container is running and downloading, just as an unhealthy container.

@ilike2burnthing
Copy link
Contributor

ilike2burnthing commented Jan 12, 2024 •
edited
Loading

haugene/vpn-configs-contrib#258 (comment)

Some others have found 1.1.1.1 to work as well.

@StormPooper
Copy link

Looking good so far, thanks @ilike2burnthing.

@Bogey
Copy link

Bogey commented Jan 12, 2024 •
edited
Loading

This is working for me on a Synology NAS, do note that I it’s not the latest release (because 5.1.0 just works).

version: "3.9"
services:
transmission-openvpn-service:
image: haugene/transmission-openvpn:5.1.0
container_name: transmission-openvpn
hostname: transmission
cap_add:
- NET_ADMIN
dns:
- 9.9.9.9
- 149.112.112.112
environment:
- CREATE_TUN_DEVICE=true
- ENABLE_UFW=false
- OPENVPN_PROVIDER=CUSTOM
- OPENVPN_CONFIG=AirVPN
- OPENVPN_USERNAME=dummy
- OPENVPN_PASSWORD=dummy
- OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60
- PUID=${PUID}
- PGID=${PGID}
- TZ=${TZ}
- LOCAL_NETWORK=192.168.1.0/24
- TRANSMISSION_PEER_PORT=24567
- TRANSMISSION_RPC_AUTHENTICATION_REQUIRED=true
- TRANSMISSION_RPC_ENABLED=true
- TRANSMISSION_RPC_PASSWORD=password
- TRANSMISSION_RPC_USERNAME=username
- HEALTH_CHECK_HOST=google.com
networks:
- transmission-nw
ports:
- "9091:9091" # transmission
restart:
always
volumes:
- "/volume1/docker/transmission-openvpn/resolv.conf:/etc/resolv.conf"
- "/volume1/docker/transmission-openvpn/config:/config"
- "/volume1/docker/transmission-openvpn/data:/data"
- "/volume1/docker/transmission-openvpn/airvpn/:/etc/openvpn/custom/"

@StormPooper
Copy link

Update: it hasn't helped, been restarting a lot today with both github.com and 1.1.1.1 for the health check endpoint and Auto heal running.

@ilike2burnthing
Copy link
Contributor

What do the health check logs show?

@StormPooper
Copy link

Typically, it's working at the moment, so nothing but healthy pings. Will update here next time I see it is unhealthy.

@Silversurfer79
Copy link

Still failing for me to, with in 30 seconds or so.

@Silversurfer79
Copy link

Working all of a sudden after the last Synology patch.

@reprz
Copy link

reprz commented Mar 25, 2024

I have to comment to this issue. I had lots of issues previously with container failing. I had to manually start it sometimes 1-2 times in a day or longest time was maybe 2 days without container exiting. I upgraded to newest [v5.3.1] version on 22.3 and my container is still up without issues. I didn´t change any vpn configurations. Looks promising, needs more time to give the final verdict though. And I´m using PIA vpn as a provider.

@Silversurfer79
Copy link

Unfortunately @skrenes's suggestion of setting the additional NORDVPN variables didn't help me as they were already set. However, their previous comment mentioning Autoheal solved it for me - the health check was failing, so Autoheal was restarting the container - this is why there was nothing in the container logs before the SIGTERM, as it was Autoheal triggering it. Now the container is running and downloading, just as an unhealthy container.

Can you elaborate on how you turn off autoheal pls?

@StormPooper
Copy link

Can you elaborate on how you turn off autoheal pls?

Sorry, I should have been clearer, I'm referring to the Autoheal container, which monitors for containers that are failing health checks and restarts them. I just stopped the container whilst debugging the issue.

@Silversurfer79
Copy link

Silversurfer79 commented Jun 4, 2024 •
edited
Loading

Not sure, but its working at the moment, only changed the version from 3.0 to 3.3

version: '3.3'

services:
  transmission:
    image: haugene/transmission-openvpn:latest
    container_name: Transmission-OpenVPN
    cap_add:
     - NET_ADMIN
    ports:
      - 9091:9091 # http://nas-ip:9091 to access ui
      - 8888:8888 # web-proxy
    environment:
    - LOCAL_NETWORK=192.168.0.0/24
    - ./openvpn-credentials.txt:/config/openvpn-credentials.txt
    - OPENVPN_USERNAME=**None**
    - OPENVPN_PASSWORD=**None**
    - OPENVPN_PROVIDER=PRIVATEVPN # PIA or etc
    - CREATE_TUN_DEVICE=true
    - HEALTH_CHECK_HOST=ui.com
    - OPENVPN_OPTS=--inactive 3600 --ping 20 --ping-exit 120
    - TRANSMISSION_WEB_UI=transmission-web-control
    - PUID=****
    - PGID=******
    - TRANSMISSION_BLOCKLIST_ENABLED=true
    - TRANSMISSION_BLOCKLIST_URL="http://list.iblocklist.com/?list=ydxerpxkpcfqjaybcssw&fileformat=p2p&archiveformat=gz"
    - TRANSMISSION_DOWNLOAD_QUEUE_ENABLED=true
    - TRANSMISSION_DOWNLOAD_QUEUE_SIZE=5
    - TRANSMISSION_ENCRYPTION=2
    - TRANSMISSION_PEX_ENABLED=false
    - TRANSMISSION_DHT_ENABLED=false
    - TRANSMISSION_LPD_ENABLED=false
    - TRANSMISSION_ALT_SPEED_DOWN=10240
    - TRANSMISSION_ALT_SPEED_ENABLED=true
    - TRANSMISSION_ALT_SPEED_TIME_BEGIN=420
    - TRANSMISSION_ALT_SPEED_TIME_DAY=127
    - TRANSMISSION_ALT_SPEED_TIME_ENABLED=true
    - TRANSMISSION_ALT_SPEED_TIME_END=1439
    - TRANSMISSION_ALT_SPEED_UP=1024
    - TRANSMISSION_MAX_PEERS_GLOBAL=250
    - TRANSMISSION_PEER_ID_TTL_HOURS=6
    - TRANSMISSION_PEER_LIMIT_GLOBAL=250
    - TRANSMISSION_PEER_LIMIT_PER_TORRENT=50
    - TRANSMISSION_RATIO_LIMIT=1
    - TRANSMISSION_RATIO_LIMIT_ENABLED=true
    - TRANSMISSION_allow_compression=false
    volumes:
    - /volume1/docker/transmission-openvpn/config:/config
    - /volume1/docker/transmission-openvpn/data:/data
    - /volume1/Media/Downloads/completed:/downloads
    - /volume1/Media/Downloads/incomplete:/incomplete
    - /volume1/Media/Downloads/watch:/watch
    - /etc/localtime:/etc/localtime
    dns:
    - 1.1.1.1
    - 9.9.9.9
    restart: unless-stopped

Good luck

@reprz
Copy link

reprz commented Jul 19, 2024

I have to comment to this issue. I had lots of issues previously with container failing. I had to manually start it sometimes 1-2 times in a day or longest time was maybe 2 days without container exiting. I upgraded to newest [v5.3.1] version on 22.3 and my container is still up without issues. I didn´t change any vpn configurations. Looks promising, needs more time to give the final verdict though. And I´m using PIA vpn as a provider.

Unfortunately container still fails after some time. Yesterday I tried @Silversurfer79 settings as I also have PIA. No luck with them(container failed couple hours later) but I noticed that you changed the version. Are these version numbers same as in release versions? I use docker run so I haven't tried specifying version numbers at all. I'm running latest image.

@Silversurfer79
Copy link

So no dice still crashes randomly, but alot more recenelty than it has previously.

Anyone using any other solution, the dev seems to have stopped with this container.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests