Sonarr hanging a few minutes after startup

Help & Support
1

Sonarr version (exact version): 2.0.0.4645
Mono version (if Sonarr is not running on Windows): 4.8.0.520/8f6d0f6
OS: Ubuntu 16.10

((Debug logs))
Normal log
Debug log
Trace log

Description of issue:
Great application - when I’ve got it to work, it’s been fantastic, however, I’ve had a few problems, the latest of which I haven’t been able to solve via the forums or Google.

Essentially my current issue is that shortly after starting up Sonarr, the application hangs.

This has not always been the case, but it seems to be doing it every time now.

I upgraded NzbDrone and Mono to the latest versions today, but the problem still occurs.

The drive where the files are downloaded by uTorrent is a local drive, but the drive where the files are imported to by Sonarr is a network drive (MyBookLive) which is mounted using cifs - not sure if this is relevant as it seemed to work alright in the past, but thought it worth mentioning.

If I kill the mono process, it becomes defunct and I end up having to restart the machine in order to be able to start Sonarr again (the machine doesn’t want to shut down cleanly after Sonarr hangs either…).

Hoping there is something in the debug/trace logs which gives an indication of the problem?

Thanks
-Stu

2

The only thing that stands out at the moment is:

17-3-17 17:22:20.4|Debug|DiskProvider|Hardlink '/home/lounge/NCIS.S14E18.HDTV.x264-LOL[ettv]/ncis.1418.hdtv-lol[ettv].mkv' to '/media/shared_videos/Adults/TV Shows/NCIS (2003)/Season 14/NCIS - S14E18 - M.I.A.mkv' failed.

[v2.0.0.4645] Mono.Unix.UnixIOException: Invalid cross-device link [EXDEV].
  at Mono.Unix.UnixMarshal.ThrowExceptionForLastError () [0x00005] in <50ac655bbdec4042a8ff7c32f14cdbb1>:0 
  at Mono.Unix.UnixMarshal.ThrowExceptionForLastErrorIf (System.Int32 retval) [0x00007] in <50ac655bbdec4042a8ff7c32f14cdbb1>:0 
  at Mono.Unix.UnixFileSystemInfo.CreateLink (System.String path) [0x0000d] in <50ac655bbdec4042a8ff7c32f14cdbb1>:0 
  at NzbDrone.Mono.Disk.DiskProvider.TryCreateHardLink (System.String source, System.String destination) [0x00000] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Mono\Disk\DiskProvider.cs:120 

17-3-17 17:22:20.5|Trace|SymbolicLinkResolver|Checking path /media/shared_videos/Adults/TV Shows/NCIS (2003)/Season 14/NCIS - S14E18 - M.I.A.mkv for symlink returned error ENOENT, assuming it's not a symlink.

Start off by disabling hardlinking in Sonarr’s Media Management settings (it’s an advanced setting) and post logs again if you continue to see the issue (the trace logs were great for troubleshooting this).

1 Like
3

Thanks - I’ll give that a try and let you know.

4

OK - that seems to have done the trick!

Thanks for your help on this - much appreciated.

1 Like
5

Hard linking is really a good feature, though. You should run a fsck on your drive. I wouldn’t give up on hard linking just yet unless you are willing to 1). use twice as much hard drive space or 2) not seed your downloaded torrents.

6

Unfortunately, I still seem to be having troubles - for example, in the latest logs, you can see that Sonarr died at around 21:39 on March 27, which I didn’t discover until this morning. I restarted it at around 10:07 am (April 1), and the application ran (albeit quite sluggishly) until around 10:45 am, after which it seems to have died again.

Latest Logs - including standard,debug,trace and stdout

I don’t believe this is the same problem as before (if you want me to start a new post, please let me know), but the end result is still the same - the application hangs.

Any help would be greatly appreciated.

On a side note, whenever Sonarr dies I always end up having to restart my system - I cannot kill the mono/sonarr process (it simply becomes defunct when I try), and I cannot kill the parent process as it is my shell (and doing this doesn’t actually help anyway).

If I try and simply restart sonarr after killing the process (where it becomes defunct), it doesn’t work as the port (8989) is still being held by the previous process.

Further to this, the system does not reboot cleanly in this scenario, it actually hangs on shutdown so that I have to hold down the power button until it shuts down, then restart.

This is very frustrating as I have to perform these steps every time sonarr hangs - I have Googled the problem (specific to sonarr/mono, and generic as far as killing defunct processes), but I cannot find a solution - if you have any advice on how to get past this, that would be fantastic.

7

Is it freezing during a series refresh? Could be an issue with media info and a zero byte file causing it to crash.

8

I’m not sure - by the time I log on, the console won’t even load. Is it possible to tell what it’s doing from the logs?

Here are today’s logs - LOGS

These ones seem to show it hanging on a housecleaning task…

Any idea about killing the mono/sonarr process? It makes it so much more painful to debug the issue if I have to restart the machine every time. :disappointed:

9

Still having the same issues.

Here are the latest logs - LOGS

I restarted a few times today, and each time it seems to get stuck shortly after trying to move a file. I have tried removing the offending file, but it just seems to get stuck on the next one.

Still can’t restart sonarr after killing the mono process - based on what I’ve read, it seems that there’s no process left to kill when it’s defunct - it’s just waiting for the parent (my shell) to die. I don’t quite understand why the process won’t let go of port 8989 and let me start sonarr again?

I also noticed the following post when checking the forums - this seems like a similar problem to mine?
Random Hanging

Still holding out hope that I can fix this as I really like the application, just can’t seem to keep it running.

10

It just seems to die, nothing logged and nothing in the output.
Is the output capturing both output and error output? (mono --debug /path/to/NzbDrone.exe >file.log 2>&1)

Upgrading/downgrading mono might be help, but knowing what is failing would be a good first step.

That thread may be related, but the lack of information we requested means we don’t know if the setup is similar.

The port is registered via http.sys under Windows and under mono it uses whatever implementation mono has for that which seems to keep holding on to it. Does the OS actually show something listening on that port after it becomes defunct?

11

New files here: LOGs

Yes - both the stdout and stderr are captured in the sonarr.out file. I have attached my startup script (sonarr.sh) for your reference.

I have also included a text file (sonarr_kill.txt) which shows what happens when I kill the mono process.

I had higher hopes for things working last night as I had removed all .partial~ files from the file system, and cleared all torrents from the download directory (where uTorrent puts them before sonarr moves them) in the hope that one or more of these files was actually causing a problem, but unfortunately I still only got a few hours out of the app before it froze again.

I’m inclined to think that this might all be due to my use of a basic network drive (WD MYBOOKLIVE) to store my files, but if this is the cause, I’m not sure how to address the problem.

Over the weekend I might try setting the app up to use hard links again instead of copying the files - I’ll let you know how I go, but if you have any further suggestions in the meantime, please post and I’ll try them out.

Edit: Just checked the port status 3 hours after I posted this, and the defunct mono process is still holding 8989 as per the sonarr_kill.txt file I provided…

12

Found the problem!!

I’ve also been having performance issues with a couple of WD Live TV boxes I have around the house which are fed from the same WD MYBOOKLIVE network drive, so I started trying to diagnose this problem. What I found was that there were a bunch of SMDB processes (like about 10) running on the MYBOOKLIVE that were each using a good chunk of CPU, and when I killed these, it not only solved my WD Live TV performance issues, but totally fixed the Sonarr problem as well.

I believe these SMDB processes were orphaned, but I’m not sure why they were hanging around and didn’t just die. Since killing them, I have been monitoring the processes on the MYBOOKLIVE, and while an occasional SMDB process appears (like when I update the KODI library, or connect to the MYBOOKLIVE using Nautilus file explorer on Linux), it is short lived and disappears soon after - it does not seem normal to have SMDB processes running on the MYBOOKLIVE for an extended period of time.

I have not a had a single problem with Sonarr since killing these processes - such a relief to go back to having an application this brilliant that is working perfectly.

Thanks for your assistance on this issue.

1 Like
15

Ok, so a correction here… the processes were smbd processes - not smdb. And it seems that sonarr is responsible for initiating these processes?

After having a good few days where everything worked perfectly, I am currently experiencing an issue where when sonarr is running, it appears to initiate multiple smbd processes on the MYBOOKLIVE with one of these processes consuming 90-100% of the CPU on the MYBOOKLIVE.

If I kill sonarr, then kill the smbd processes on the MYBOOKLIVE they stay dead, but if I don’t kill sonarr first, the smbd processes keep reappearing on the MYBOOKLIVE, and one of them keeps jumping straight to 90-100% CPU.

Latest logs here - LOGS.

Any thoughts/suggestions regarding this development would be greatly appreciated.

On a side note, if I kill the mono process it goes defunct (as noted previously), however, once I kill the smbd processes on the MYBOOKLIVE the mono process disappears soon after - obviously it’s the smbd processes on the MYBOOKLIVE that are causing the mono process to hang around, and by extension cause mono to hold onto port 8989.

It seems there were a couple of failed imports by sonarr which left *partial~ files on the MYBOOKLIVE file server, which samba then seemed to have a problem with.

After removing both *partial~ files and killing the process identified by the smbstatus command as locking one of these files, everything seems to have gone back to normal.

Will continue to monitor.

It seems there were *partial~ files because there was “Not enough free space(0) to import: …” a number of downloaded files.

Selection_005.png883×247 37.3 KB

Where I get confused about this is, that there is suppposedly 596G free on the target drive:

MyBookLive:/shares# df -h .
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda4             2.8T  2.2T  569G  80% /DataVolume

Will continue to investigate.

16

They’re created because you’re accessing a share over SMB/CIFS.

Are you able to use NFS instead of SMB? Copying files over SMB has been unreliable in the past due to some edge case issues with mono and SMB shares. Sonarr creates the ~partial files in attempt to workaround the issues (copying instead of moving and only renaming to remove ~partial after it has verified that the copy was successful and nothing was truncated.

Enable Skip Free Space Check in Media Management settings so Sonarr skips the freespace check as it may be unable to get the freespace for a SMB share under mono.

17

I’ve enabled Skip Free Space Check - I will look into whether I can use NFS instead of SMB.

Thanks again.

18

I’ve switched to using NFS - I will continue to monitor and see how things go.

19

Looking good. No further problems in the last few days. :slight_smile:

1 Like
20

Just posting to share that I’ve been tearing my hear out with exactly the same problem. Sonarr starts these processes and just hangs with the web console going unresponsive. I’ve tested this using the latest version of Sonarr inside Docker and also directly on a fresh Ubuntu 16.04 install. My files are located on a QNAP and when using SMB the QNAP gets busy with either one 99% or two 49% smbd processes that churn until I end them manually.

Great to see that I’m not the only one and that someone has reported a potential resolution.

I’ll be configuring NFS instead to see if that resolves the issue. I really hope so.

21

Glad to hear this post might help - I haven’t had a single problem since switching to NFS. Good luck!

22

I don’t have much experience with NFS so it took a while to set up, but now that the permissions are working it appears that Sonarr is grabbing and importing to the file share more reliably (already) than it was over SMB.

I’m cautiously optimistic that this is the resolution for me. Will update if I run into further issues.

Thanks again for sharing your solution!