Fresh Ubuntu, Latest Mono, Latest Sonarr : Fatal Errors

Help & Support
#1

Sonarr version (exact version): 2.0.0.5163
Mono version: 5.10.0.160
OS: Ubuntu 16.04 Xenial (Linux Container on Proxmox)
Trace logs: https://pastebin.com/L9eBAinu But here is perhaps the most pertinent part:

Native stacktrace:

        mono() [0x4b5a39]
        mono() [0x545936]
        mono() [0x47debf]
        [0x40919764]

Debug info from gdb:

mono_gdb_render_native_backtraces not supported on this platform, unable to find gdb or lldb
[0x7fbf0e96e700: 487.68388 5] ENTER: NLog.Internal.Fakeables.AppDomainWrapper:OnProcessExit (object,System.EventArgs)(this:0x7fbf17c54d10[NLog.Internal.Fakeables.AppDomainWrapper NzbDrone.exe],
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

[0x7fbf0e96e700: 487.68388 5] ENTER: NLog.Internal.Fakeables.AppDomainWrapper:OnProcessExit (object,System.EventArgs)(this:0x7fbf17c54d10[NLog.Internal.Fakeables.AppDomainWrapper NzbDrone.exe], Aborted

Description of issue: I’ve been trying for over a week now to get Sonarr working again, but it continues to lock-up and fail no matter how many fresh ubuntu containers I throw at it. I can’t even use pkill -s <process_#_of_nzbdrone> to get it to stop. I posted this already and didn’t receive much feedback, but I’m starting to notice others posting similar problems. Is there a known bug with the latest mono?

#2

I just rolled another fresh new ubuntu container, and tried the same thing again but with mono v5.8.0.127 instead. Same result.

Native stacktrace:

        mono() [0x4b33f9]
        mono() [0x51ea16]
        mono() [0x47d38f]
        [0x413aed44]

Debug info from gdb:

mono_gdb_render_native_backtraces not supported on this platform, unable to find gdb or lldb
[0x7fae26a0e700: 66.06156 5] ENTER: NLog.Internal.Fakeables.AppDomainWrapper:OnProcessExit (object,System.EventArgs)(this:0x7fae2e402c28[NLog.Internal.Fakeables.AppDomainWrapper NzbDrone.exe],
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

[0x7fae26a0e700: 66.06156 5] ENTER: NLog.Internal.Fakeables.AppDomainWrapper:OnProcessExit (object,System.EventArgs)(this:0x7fae2e402c28[NLog.Internal.Fakeables.AppDomainWrapper NzbDrone.exe], Aborted
#3

I just rolled a new Debian Stretch container this time, with a slightly more recent version of mono (I guess Debian gets releases before Ubuntu?)

Still locked up. I don’t think it’s a corrupt database issue either, because it’s locking up in a different place every time. With trace logging, these were some of the last entries (doesn’t tell me much).

18-4-3 22:57:35.7|Trace|EventAggregator|SeriesUpdatedEvent <- SeriesModule
18-4-3 22:57:35.7|Trace|ShouldRefreshSeries|Series Saturday Night Live is continuing, should refresh.
18-4-3 22:57:35.7|Trace|EventAggregator|SeriesUpdatedEvent ~> MediaCoverService
18-4-3 22:57:35.7|Info|RefreshSeriesService|Updating Info for Saturday Night Live
18-4-3 22:57:35.7|Trace|EventAggregator|Publishing CommandUpdatedEvent
18-4-3 22:57:35.7|Info|MediaCoverService|Downloading Fanart for [275274][Rick and Morty] https://www.thetvdb.com/banners/fanart/original/275274-10.jpg
18-4-3 22:57:35.7|Trace|EventAggregator|CommandUpdatedEvent -> CommandModule
18-4-3 22:57:35.7|Trace|EventAggregator|CommandUpdatedEvent <- CommandModule
18-4-3 22:57:35.7|Debug|HttpClient|Downloading [https://www.thetvdb.com/banners/fanart/original/275274-10.jpg] to [/root/.config/NzbDrone/MediaCover/52/fanart.jpg]
18-4-3 22:57:35.7|Trace|HttpClient|Req: [GET] http://skyhook.sonarr.tv/v1/tvdb/shows/en/76177
18-4-3 22:57:35.7|Trace|ConfigService|Using default config value for 'proxyenabled' defaultValue:'False'
18-4-3 22:57:35.7|Debug|ParsingService|No matching series Robot Chicken
#4

could it be a issue because you’re using containers ?

I’m using Debian 9.x
with the following
Version
2.0.0.5169
Mono Version
4.6.2

BTW: I don’t use containers I got it running on a VMWare with some other stuff

#5

It’s been running great in a Linux Container on proxmox for the past 9 months. Radarr is still working great too (also in its own Linux Container).

I just stood up a 7th instance (it’s been a long week) in a full blown Ubuntu VM though, and now it seems to be much happier. It kind defeats the point of my setup and strikes me as unnecessary, but at least it works for now.

I’m anxious to try v3 and would be willing to part with a small portion of my retirement account for someone to rewrite Sonarr in .NET instead of relying on mono.

#6

ummm… mono is .net (well, the open source implementation of the .net framework)…

1 Like
#7

Sorry, .NET Core 2.x is what I meant. Anything to avoid having to use mono, really.

Even after running it in a VM for a while, I still can’t access my proxmox host instance of plexdrive that leverages google drive. Only linux containers can access bind mounts, not VMs. And you can’t smb or nfs share a bind mount. So for the time being, all of my TV media is being stored on a local NAS box via smb share.

So after trying 3 different versions of mono and 3 different operating systems across 2 different architectures, I think I’m just going to have to bank on v3 of sonarr coming out in the next month or two. In the interim, I’m left with no choice but to:

  1. Manually migrate data from NAS to gsuite
  2. Delete each completed/finished series from sonarr after they are migrated
  3. Await v3 of Sonarr and pray that it works again in a Linux Container
  4. Bulk Series Import on the new sonarr once it has access to the bind-mounted gsuite folders again
#8

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.