Sonarr stuck a "Starting webserver"

Sonarr version (exact version): 2.0.0.4753
Mono version (if Sonarr is not running on Windows): 4.6.2
OS: Debian 8
((Debug logs)): https://pastebin.com/raw/u4zJbjb6

Description of issue:
This night Sonarr stopped working for some reason, I tried to view the log but nothing seemed to happend (or at least logged). When I stopped the NzbDrone service this morning and tried to start it again It would stay stuck at NancyBootstrapper|Starting Web Server , after this nothing happens and the WebUI doesn’t show up.

Things I tried:

  • Changing the port number, same issue.
  • Restoring back-up, same issue.
  • Upgrade to newest mono/nzbdrone available from the repo’s, no luck either.

I can’t seem to get it working again or even find a log which will tell me more than the log I’m seeing right now. Hope someone can help me!

Thanks in advance,

Tim

1 Like

I’ve got the same behavior. Fresh install on a Debian 8 server, Sonarr 2.0.0.4753 & Mono 4.2.3.4. Worked fine for a few days, UI was non responsive this morning (possibly my fault, I had a non responsive mount and ls & df were both hanging). I fixed the mount, Sonarr was still nonresponsive. Restarted it, and now my logs stop at Starting Web Server like yours, and nothing responds.

I followed the advice in this thread - installing mono-devel and mono-addins-utils and rebooted, and my log did progress to the next steps, looking for releases… But the web UI still timed out, and the next restart halted at starting web server again.

Attempted to update to Mono 5, installed mono-complete – no change.

My issue may not be entirely related - it seems it does move past “Starting web server” eventually, though my web UI remains nonresponsive (ERR_CONNECTION_TIMED_OUT).

saiboogu@bebop:~$ tail -f /home/plex/.config/NzbDrone/logs/sonarr.txt
17-5-18 15:49:52.4|Info|Bootstrap|Starting Sonarr - /opt/NzbDrone/NzbDrone.exe - Version 2.0.0.4753
17-5-18 15:49:55.0|Info|MigrationLogger|*** Migrating data source=/home/plex/.config/NzbDrone/nzbdrone.db;cache size=-10485760;datetimekind=Utc;journal mode=Wal;pooling=True;version=3 ***
17-5-18 15:49:55.2|Info|MigrationLogger|*** Migrating data source=/home/plex/.config/NzbDrone/logs.db;cache size=-10485760;datetimekind=Utc;journal mode=Wal;pooling=True;version=3 ***
17-5-18 15:49:55.3|Info|Router|Application mode: Interactive
17-5-18 15:49:55.3|Info|OwinHostController|Listening on the following URLs:
17-5-18 15:49:55.3|Info|OwinHostController|  http://*:8989/
17-5-18 15:49:55.6|Info|NancyBootstrapper|Starting Web Server
17-5-18 15:55:28.4|Info|RssSyncService|Starting RSS Sync
17-5-18 15:55:32.1|Info|DownloadDecisionMaker|Processing 200 releases
17-5-18 15:55:33.2|Info|RssSyncService|RSS Sync Completed. Reports found: 200, Reports grabbed: 0

Are you also on acd_cli or rclone mounts of ACD? I’ve just noticed that they both have issues with Amazon at the moment and I think it might have something to do with this as well (maybe because Sonarr can’t read/write to the mount), would be strange considering that there are no errors but it might be possible…?

Yes, via some layers. Sonarr’s destination folder is a unionfs mount that includes encfs mounts of rclone mounts on ACD. No errors that I’ve seen anywhere in that chain, but yes - that is suspicious.

I’m finding errors now in my rclone mount process… Definitely seems like that is a potential root cause, going to pursue rclone/ACD problems and correct that before I worry about Sonarr further.

Good to know that I’m not the only one in that case. It was indeed strange because there are no errors but looks like Amazon messed something up. Should probably pay a little bit more and transfer everything to G-Drive since that works with rclone as well. But for now we have to wait until ACD is fixed to transfer everything again :’(

Starting webserver just happens to be the last line logged when the logging level is set to info until the job queue starts processing.

The best thing to do would be manually set the LogLevel to Debug or Trace in config.xml see: https://github.com/Sonarr/Sonarr/wiki/Log-Files for more information (updated a few minutes ago). At the Trace accessing the Sonarr UI will log all requests to the trace log file.

Thanks for the log explanations - makes sense.

As far as I can tell my UI issues came down to a ufw mis-configuration - realized after I noticed all my services on non-standard ports were nonresponsive.

I’m still having my ACD issues, but it looks like the timing is just a coincidence - Amazon issues at the same time that my firewall broke (on reboot, I simply had to enable it … and evidently figure out how to enable on boot).

I’ll make this my last post since it’s gone off-topic for Sonarr, but regarding our mutual ACD problems – I got this from Amazon support

I’ve contacted our technical team regarding the error you’re seeing and received the below information:

“At this time, the Amazon Drive ended the invitation period for new third party apps. You can use one of our Amazon Drive apps (available for PC/Mac/iOS/Android) to sync / upload / connect to Amazon Drive.”

And check recent remarks here - looks like Amazon is ending 3rd party clients. https://forum.rclone.org/t/acd-429-too-many-requests/1792/383

It had definitely something to do with the fact to the mount was not writeable for the sonarr test file, It eventually started up after almost a day and showed the “can’t write to drone factory folder” error.

So In my case it’s caused by the fact that acd_cli and rclone are suspended/banned from Amazon Cloud Drive… After migrating the data I will confirm if it works again just for conformation.

Well, issue was indeed caused by acd_cli/rclone Amazon mounts that went down. I’ve switched to G-Drive now and everything works smoothly again!

1 Like

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