Sonarr not starting in Docker

[tizio]

I’m having the same problem with the same version of Sonarr running in Docker (LinuxServer edition).
Looking into it, the app will launch then die after about 5 minutes when it starts to send shows to the downloader.

The crash is pretty hard–it actually hangs Docker and the container cannot be killed under any circumstances, even with a SIGKILL (kill -9) from within or outside the container because it is permanently disk locked (D status on the process). When running in docker, the system blocker is s6-sync, but that’s just a symptom of the software taking out a disk lock and then dying before releasing it.

I’ll rebuild my database, but the software shouldn’t crash this hard even with a corrupted DB. At the very least, it would be helpful to add a catch that releases disk locks as it dies.

I just wiped everything out and started from scratch. After re-adding all of my shows, it crashed in the same way as before. The problem seems to be something other than a corrupted DB. I’m guessing a specific show or file is causing it to barf, but I’m not seeing any smoking guns in the logs.

[markus101]

Move as it was unrelated to the last thread (different OS and hanging).

We’re going to need more information.

Sonarr version (exact version):
Mono version (if Sonarr is not running on Windows):
OS:
Debug logs:
Description of issue:

For the logs you’ll need the standard output/error, which I believe the linuxserver image captures already (you’ll need to fetch them through docker).

I’ll rebuild my database, but the software shouldn’t crash this hard even with a corrupted DB.

What are you basing DB corruption on? In the last thread I didn’t see any evidence of a corrupt DB.

At the very least, it would be helpful to add a catch that releases disk locks as it dies.

If something crashes mono there is no chance we can catch it as it’s going down, everything is already gone at that point. Even logging the cause to a log file often doesn’t happen due to this.

I’m guessing a specific show or file is causing it to barf, but I’m not seeing any smoking guns in the logs.

Trace logs with standard output/error should give you the smoking gun, often crashes like these are related to a file mediainfo explodes on, trace logs will show the file and the redirected logs should show the error if that’s the case.