Docker-transmission-openvpn: Jackett no longer accessible after transmission restart

[JTT-JustTheTip]

Describe the problem

Now this may be a lack of knowledge on my part so apologies for any ignorance on my end. I have a watchtower container configured to update all my deployed containers as and when required. Now this means my Transmission container is restarted at least once a day-ish from what I can see. When the transmission is restarted the attached jackett container is no restarted and becomes inaccessible from that point on wards.

I am assuming this is to do with the the recreation of the transmission container kills that containers network and therefore leaves jackett connected to a non existent network making it inaccessible.

Is there a way to force jackett to be restarted simultaneously when the transmission container goes down, or a to keep jackett and transmission connected through container restarts and recreations.

Compose

transmission-openvpn:
    image: haugene/transmission-openvpn
    hostname: transmission-openvpn
    cap_add:
      - NET_ADMIN
    devices:
      - "/dev/net/tun"
    container_name: transmission-openvpn
    restart: always
    ports:
      - "9091:9091"
      - "8888:8888"
      - "9117:9117"
    dns:
      - 192.168.2.5
      - 8.8.4.4
    environment:
      PGID: '1001'
      PUID: '1001'
      OPENVPN_PROVIDER: PIA
      OPENVPN_CONFIG: CA Vancouver
      OPENVPN_USERNAME: 
      OPENVPN_PASSWORD: 
      OPENVPN_OPTS: --inactive 3600 --ping 10 --ping-exit 60 --mute-replay-warnings
      LOCAL_NETWORK: 192.168.2.0/24
      TRANSMISSION_RPC_USERNAME: "admin"
      TRANSMISSION_RPC_PASSWORD: ""
      TRANSMISSION_RPC_AUTHENTICATION_REQUIRED: "true"
      TRANSMISSION_SPEED_LIMIT_DOWN: 7000
      TRANSMISSION_SPEED_LIMIT_UP: 100
      TRANSMISSION_SPEED_LIMIT_DOWN_ENABLED: "true"
      TRANSMISSION_SPEED_LIMIT_UP_ENABLED: "true"
      TRANSMISSION_PEER_LIMIT_GLOBAL: 500
      TRANSMISSION_PEER_LIMIT_PER_TORRENT: 100
      TRANSMISSION_DOWNLOAD_QUEUE_SIZE: 200
      TRANSMISSION_RATIO_LIMIT: 0
      TRANSMISSION_IDLE_SEEDING_LIMIT: 0
      TRANSMISSION_IDLE_SEEDING_LIMIT_ENABLED: "true"
      TRANSMISSION_RATIO_LIMIT_ENABLED: "true"  
      TRANSMISSION_DOWNLOAD_DIR: "/downloads/complete"
      TRANSMISSION_INCOMPLETE_DIR: "/downloads/incomplete"
    volumes:
      - /media/VMRoot/VMMedia/:/downloads
      - /media/VMRoot/VMMedia/Config:/data
      - /Docker_Configs/transmission-vpn/config:/config
      - /media/VMRoot/VMMedia/watch:/watch
      - /etc/localtime:/etc/localtime:ro



#Now uses transmission-openvpn web proxy to go through vpn
  Jackett:
    image: linuxserver/jackett
    container_name: jackett
    environment:
      PUID: '1001'
      PGID: '1001'
      TZ: GB
    network_mode: "service:transmission-openvpn"
    volumes:
    - /Docker_Configs/Jackett/config:/config
    - /media/VMRoot/VMMedia/:/downloads
    tty: true
    restart: unless-stopped
    depends_on:
      - "transmission-openvpn"

[ilike2burnthing]

Not in Watchtower yet, https://github.com/containrrr/watchtower/issues/453, although you could alternatively just switch to monitor only and then run the updates manually.

You could try using healthcheck in Jackett's compose, see if that works for you.

[JTT-JustTheTip]

I have had a play about, for now I have used the monitor only option for watchtoiwer; as portainers implementation of docker composes in the form of stacks doesn't allow for the use of the health check function as I think its only present in compose 3 and beyond.

Ill update and close in a couple days after some testing.

Thanks for the help!

[JTT-JustTheTip]

Just an update to this, previously noted I have placed both transmission and jackett as monitor only, this has solved the problem for now. Thanks!

[JTT-JustTheTip]

To follow up on this thread, I previously fixed the Watchtower and Jackett update issue and this has majorly helped in reducing the number of crashes.

But I have still be suffering from crashes every few days. Here is the log from portainer after Jackett 502's.

09-02 19:50:20 Info Checking for updates... Jackett variant: CoreLinuxAmdx64 
09-02 19:50:22 Error Error checking for updates. System.Net.Http.HttpRequestException: Resource temporarily unavailable
 ---> System.Net.Sockets.SocketException (11): Resource temporarily unavailable
   at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean allowHttp2, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.GetHttpConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
   at System.Net.Http.DecompressionHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at CloudflareSolverRe.ClearanceHandler.SendRequestAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at CloudflareSolverRe.ClearanceHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
   at Jackett.Common.Utils.Clients.HttpWebClient2NetCore.Run(WebRequest webRequest) in /home/vsts/work/1/s/src/Jackett.Common/Utils/Clients/HttpWebClient2NetCore.cs:line 229
   at Jackett.Common.Utils.Clients.WebClient.GetString(WebRequest request) in /home/vsts/work/1/s/src/Jackett.Common/Utils/Clients/WebClient.cs:line 164
   at Jackett.Common.Services.UpdateService.CheckForUpdates() in /home/vsts/work/1/s/src/Jackett.Common/Services/UpdateService.cs:line 117

There is nothing obvious that causes concern in the transmission logs which I found unusual. I am going to see if anything is obvious in the logs the next time around to see if there is a pattern of course.

In the meantime, does the log above help much at all?

Thanks

[ilike2burnthing]

Have you disabled Jackett's auto-update feature (in the configuration section at the bottom)? If not, try that.

[JTT-JustTheTip]

This is the Jackett ServerConfig.json file

{
  "Port": 9117,
  "AllowExternal": true,
  "APIKey": "XXXX",
  "AdminPassword": "XXXX",
  "InstanceId": "9dc80hbpdm4kezccl4f8k9r4tu86upc98fk563qeyytw1kpqdywsjr18rtr2bo86",
  "BlackholeDir": "",
  "UpdateDisabled": false,
  "UpdatePrerelease": false,
  "BasePathOverride": "/jackett",
  "OmdbApiKey": "",
  "OmdbApiUrl": "",
  "ProxyUrl": "",
  "ProxyType": 0,
  "ProxyPort": null,
  "ProxyUsername": "",
  "ProxyPassword": "",
  "ProxyIsAnonymous": true
}

So as far as I can see that indicates that it isnt auto-updating

[ilike2burnthing]

UpdateDisabled needs to be changed to true (so it is true that they're disabled)

[JTT-JustTheTip]

Ahh yes I see, I have had a blind man moment again. I have changed that, I shall observe the container over the next few weeks and re-open the issue if it persists.

Once again, thanks for the help bud!

[JTT-JustTheTip]

I am re-opening the issue again, disabling the auto-updates doesnt seem to have solved the issue.

Here is the Jackett logs -

09-11 22:44:45 Error On attempt 1 checking for results from Internet Archive: No route to host 
,09-11 22:44:46 Error On attempt 2 checking for results from Internet Archive: No route to host 
,09-11 22:44:46 Error On attempt 3 checking for results from Internet Archive: No route to host 
,09-11 22:44:50 Error On attempt 1 checking for results from RARBG: Resource temporarily unavailable 
,09-11 22:44:51 Error On attempt 2 checking for results from RARBG: Resource temporarily unavailable 
,09-11 22:44:52 Error On attempt 3 checking for results from RARBG: Resource temporarily unavailable 
,09-11 22:45:25 Info Found 0 releases from AggregateSearch for: Jamie Oliver The Naked Chef Takes Off 
,09-11 22:45:45 Error On attempt 1 checking for results from Internet Archive: The operation was canceled. 
,09-11 22:45:45 Error On attempt 1 checking for results from RARBG: The operation was canceled. 
,09-11 22:45:45 Error On attempt 2 checking for results from Internet Archive: Resource temporarily unavailable 
,09-11 22:45:45 Error On attempt 2 checking for results from RARBG: Resource temporarily unavailable 
,09-11 22:45:46 Error On attempt 3 checking for results from Internet Archive: Resource temporarily unavailable 
,09-11 22:45:46 Error On attempt 3 checking for results from RARBG: Resource temporarily unavailable 
,09-11 22:46:25 Error On attempt 1 checking for results from ShowRSS: The operation was canceled. 
,09-11 22:46:25 Error On attempt 2 checking for results from ShowRSS: Resource temporarily unavailable 
,09-11 22:46:26 Error On attempt 3 checking for results from ShowRSS: Resource temporarily unavailable 
,09-12 11:35:54 Info Checking for updates... Jackett variant: CoreLinuxAmdx64 
,09-12 11:35:54 Info Skipping update check as it is disabled. 

It looks like transmission crashed in this case, here are the logs -

2020-09-11T21:44:44.411337719Z Fri Sep 11 22:44:44 2020 [d1de8a1683f2f65c18040e36e68dbe0f] Inactivity timeout (--ping-exit), exiting,
2020-09-11T21:44:45.206690202Z Fri Sep 11 22:44:45 2020 /sbin/ip addr del dev tun0 local 10.75.15.6 peer 10.75.15.5,
2020-09-11T21:44:45.254045619Z Fri Sep 11 22:44:45 2020 /etc/openvpn/tunnelDown.sh tun0 1500 1558 10.75.15.6 10.75.15.5 init,
2020-09-11T21:44:47.301052457Z Fri Sep 11 22:44:47 2020 SIGTERM[soft,ping-exit] received, process exiting,
2020-09-11T21:45:02.470323559Z Using OpenVPN provider: PIA,
2020-09-11T21:45:02.592321787Z Starting OpenVPN using config CA Vancouver.ovpn,
2020-09-11T21:45:02.592353258Z Setting OPENVPN credentials...,
2020-09-11T21:45:03.534137435Z adding route to local network 192.168.2.0/24 via 172.20.0.1 dev eth0,
2020-09-11T21:45:03.944548850Z Fri Sep 11 22:45:03 2020 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 27 2020,
2020-09-11T21:45:03.944580560Z Fri Sep 11 22:45:03 2020 library versions: OpenSSL 1.1.1c  28 May 2019, LZO 2.10,
2020-09-11T21:45:03.944594329Z Fri Sep 11 22:45:03 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts,
2020-09-11T21:45:04.048361424Z Fri Sep 11 22:45:04 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]162.216.47.66:1198,
2020-09-11T21:45:04.048384848Z Fri Sep 11 22:45:04 2020 UDP link local: (not bound),
2020-09-11T21:45:04.048480216Z Fri Sep 11 22:45:04 2020 UDP link remote: [AF_INET]162.216.47.66:1198,
2020-09-11T21:45:04.226353620Z Fri Sep 11 22:45:04 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this,
2020-09-11T21:45:04.778459058Z Fri Sep 11 22:45:04 2020 [5bfc2d0506e1f255439316467f2037ff] Peer Connection Initiated with [AF_INET]162.216.47.66:1198,
2020-09-11T21:45:05.988765244Z Fri Sep 11 22:45:05 2020 AUTH: Received control message: AUTH_FAILED,
2020-09-11T21:45:05.988821511Z Fri Sep 11 22:45:05 2020 SIGTERM[soft,auth-failure] received, process exiting,
2020-09-11T21:45:20.424989268Z Using OpenVPN provider: PIA,
2020-09-11T21:45:20.430071870Z Starting OpenVPN using config CA Vancouver.ovpn,
2020-09-11T21:45:20.430099466Z Setting OPENVPN credentials...,
2020-09-11T21:45:20.591385692Z adding route to local network 192.168.2.0/24 via 172.20.0.1 dev eth0,
2020-09-11T21:45:20.605000808Z Fri Sep 11 22:45:20 2020 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 27 2020,
2020-09-11T21:45:20.605058028Z Fri Sep 11 22:45:20 2020 library versions: OpenSSL 1.1.1c  28 May 2019, LZO 2.10,
2020-09-11T21:45:20.605072870Z Fri Sep 11 22:45:20 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts,
2020-09-11T21:45:20.614923956Z Fri Sep 11 22:45:20 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]172.98.89.194:1198,
2020-09-11T21:45:20.614983799Z Fri Sep 11 22:45:20 2020 UDP link local: (not bound),
2020-09-11T21:45:20.614997091Z Fri Sep 11 22:45:20 2020 UDP link remote: [AF_INET]172.98.89.194:1198,
2020-09-11T21:45:20.754104454Z Fri Sep 11 22:45:20 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this,
2020-09-11T21:45:21.213853319Z Fri Sep 11 22:45:21 2020 [c83b3105a09648051d5988250060766f] Peer Connection Initiated with [AF_INET]172.98.89.194:1198,
2020-09-11T21:45:22.589981046Z Fri Sep 11 22:45:22 2020 TUN/TAP device tun0 opened,
2020-09-11T21:45:22.590019133Z Fri Sep 11 22:45:22 2020 /sbin/ip link set dev tun0 up mtu 1500,
2020-09-11T21:45:22.594197056Z Fri Sep 11 22:45:22 2020 /sbin/ip addr add dev tun0 local 10.48.12.6 peer 10.48.12.5,
2020-09-11T21:45:22.602802288Z Fri Sep 11 22:45:22 2020 /etc/openvpn/tunnelUp.sh tun0 1500 1558 10.48.12.6 10.48.12.5 init,
2020-09-11T21:45:22.619127504Z Up script executed with tun0 1500 1558 10.48.12.6 10.48.12.5 init,
2020-09-11T21:45:22.619164459Z Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : 10.48.12.6,
2020-09-11T21:45:22.619181208Z Generating transmission settings.json from env variables,
2020-09-11T21:45:22.661947789Z sed'ing True to true,
2020-09-11T21:45:22.930315661Z Enforcing ownership on transmission config directories,
2020-09-11T21:45:23.521154061Z Applying permissions to transmission config directories,
2020-09-11T21:45:23.597065375Z Setting owner for transmission paths to 1001:1001,
2020-09-11T21:45:38.662481641Z Setting permission for files (644) and directories (755),
2020-09-11T21:45:39.497849243Z Setting permission for watch directory (775) and its files (664),
2020-09-11T21:45:39.510864856Z ,
2020-09-11T21:45:39.510896268Z -------------------------------------,
2020-09-11T21:45:39.510909261Z Transmission will run as,
2020-09-11T21:45:39.510921719Z -------------------------------------,
2020-09-11T21:45:39.510933640Z User name:   abc,
2020-09-11T21:45:39.510945680Z User uid:    1001,
2020-09-11T21:45:39.510957601Z User gid:    1001,
2020-09-11T21:45:39.510979297Z -------------------------------------,
2020-09-11T21:45:39.510989251Z ,
2020-09-11T21:45:39.511002125Z STARTING TRANSMISSION,
2020-09-11T21:45:39.511296870Z CONFIGURING PORT FORWARDING,
2020-09-11T21:45:39.511842073Z Transmission startup script complete.,
2020-09-11T21:45:39.522483874Z Wait for tunnel to be fully initialized and PIA is ready to give us a port,
2020-09-11T21:45:39.550792948Z Fri Sep 11 22:45:39 2020 Initialization Sequence Completed,
2020-09-11T21:45:54.885953857Z Port forwarding is already activated on this connection, has expired, or you are not connected to a PIA region that supports port forwarding,
2020-09-11T21:45:54.885998501Z curl encountered an error looking up new port: 56

It looks to be some kind of issue surrounding transmission closing down due to inactivity, correct me if I am wrong?

[ilike2burnthing]

Yea, you're losing connection to your VPN, and the container is correctly restarting. Unfortunately this then means that Jackett would also have to be restarted, and so you're back to your original issue - https://haugene.github.io/docker-transmission-openvpn/known-issues/#restart_container_if_connection_is_lost

The latest estimate for Compose v3 support in Portainer is Oct/Nov - https://www.portainer.io/2020/06/portainer-2-0-and-the-development-balancing-act/

[JTT-JustTheTip]

For now I have migrated over to using dperson's ovpn client container for the Jackett container and will leave the transmission container as a standalone container. Hopefully this will help with stability in the meantime.

Again thanks for the help!

I shall close the issue for now.