Sonarr becomes unresponsive

[Curtman]

I'm not sure where this problem is coming from, but it seems like everything else in the stack works great. I'm using Plex, jackett, sonarr, ombi, radarr, tautulli, portainer, delugevpn, and watchtower. Most of the time sonarr works great too, but every once in a while it becomes very unresponsive. The web interface wont respond, when it does eventually it says all indexers have failed, and communication to Deluge is failed. Sometimes I can go into settings hit the test button for each, and everything starts working again. Other times nothing seems to help. I try restarting the container and rebooting the server, sometimes it helps, other times not.

Does anyone recognize this problem? I've captured two logs from sonarr on two separate occasions, about two months between and it worked fine for long periods between. It seems like it just stops responding to its network sockets. I find it very strange that I've never seen this problem with radarr.

[v2.0.0.5228] System.AggregateException: A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread. ---> System.Net.WebException: The request was aborted: The request was canceled., at System.Net.HttpWebRequest+<MyGetResponseAsync>d__246.MoveNext () [0x003d5] in <a360a10e096b4659a9142a244ddaea3e>:0 , --- End of inner exception stack trace ---, ---> (Inner Exception #0) System.Net.WebException: The request was aborted: The request was canceled., at System.Net.HttpWebRequest+<MyGetResponseAsync>d__246.MoveNext () [0x003d5] in <a360a10e096b4659a9142a244ddaea3e>:0 <---, , , [Warn] DownloadMonitoringService: Unable to retrieve queue and history items from NZBGet , , [v2.0.0.5228] NzbDrone.Core.Download.Clients.DownloadClientUnavailableException: Unable to connect to NzbGet. The operation has timed out.: 'http://192.168.1.10:6789/jsonrpc' ---> System.Net.WebException: The operation has timed out.: 'http://192.168.1.10:6789/jsonrpc' ---> System.Net.WebException: The operation has timed out., at System.Net.HttpWebRequest+<RunWithTimeoutWorker>d__2441[T].MoveNext () [0x000ba] in :0 , --- End of stack trace from previous location where exception was thrown ---,`

... etc..

August 8, 2018 Oct 11, 2018

[tom472]

There seems to be a lot of reference to NzbGet in those logs - but you mention using Delugevpn in your post.

Is Deluge the only download client you have active in Sonarr?

I have a Sonarr instance running (only 3 days currently) but searching its log via Portainer only shows 1 single reference to nzb* and that was just a reference to nzbdrone.exe right when the container started.

In comparison your log capture from 10/11/2018 has: 271 - references of nzb* 112 - of them being specifically NzbGet

Also a look at your posted data there is this: [Warn] DownloadMonitoringService: Unable to retrieve queue and history items from NZBGet , , [v2.0.0.5228] NzbDrone.Core.Download.Clients.DownloadClientUnavailableException: Unable to connect to NzbGet.

You didn't possibly use/test/try NzbGet at one point and leave it "turned on" in the download client section by any chance?

[Curtman]

I'm using NZBGet as well.. I use delugevpn and nzbget in both sonarr and radarr. With the exact same Indexers, torrents via jacket and two usenet indexers. Ive never seen radarr complain about anything including NZBGet, even once.

I'm going to try starting over with the script and re-importing everything to sonarr db.

[tom472]

OK keep me posted on how it goes.

[Curtman]

So I wiped my server, installed Ubuntu 18.04 (server), and then docker etc.. I started with Sonarr and 'Import existing Series on Disk'.. At some point it went haywire again. I've installed it native on Ubuntu and it's working fine. I'll see if I can find some reason, or something in my media that is making it choke but it seems odd that it works outside of docker.

[tom472]

Hey @Curtman I might have stumbled on something that could help with your issue - you mention Sonarr - the title of this fix mentions Radarr but says other mono apps too. Are you storing your media on the same disk or are you possibly using an SMB share?

(via: https://redd.it/9tagso)

PSA: Radarr freezing on Linux or docker, using an SMB share for storage? Turn off OPLOCK for fix.

This drove me nuts for over a month and it seems like tons of people are having the same problem.

ISSUE: Radarr (or any mono based app) becomes unresponsive when called to move or read a file on an SMB share. CPU% (IOWAIT) jumps to between 30-50%. No way to kill process.

SOLUTION: The problem deals with SMB permissions and mono. Go into your SMB settings and turn off OPLOCK.