I’ve been running this for months with no problems (on Ubuntu 14.04). Recently, however, I’ll go to use the app and find its not running. I have to “sudo start nzbdrone” and then its working again.
I think that I’ve noticed that it seems to stop when there is an update. If I run apt-get to check for updates, I’ll see one for nabdrone. So I think what might be happening is that the self-update is seeing there’s something to do but all it does is shut off my nzbdrone and doesn’t update it or turn it back on.
I’m really not sure where to even begin.
You could disable automatic updates (General Settings), but that doesn’t solve the issue.
Are you starting Sonarr (nzbdrone) with init.d? or Upstart? (There were a number of issues with Upstart and its respawn flag).
Upstart. And I saw the note about respawn so I followed those instructions. Come to think about it, its quite possible that’s when the issues started (when I “fixed” the respawn flag… previously it had always been on).
The update isn’t working, no. When this happens (symptom: service isn’t running when it should be, presumably after auto-update) and I start the service, its the old version. Then I run apt-get upgrade and stop and start the service and its the new one.
Logs: my logs are a mess and I think they were corrupt. I have 49 files all with today’s date and zero byte size. I’ve deleted them and restarted the service and now I have what looks to be a good clean log. So I’ll wait until the next update and see what I get. Should I turn on debugging (if there’s such a thing)?
Yeah, debug logging (set in general settings would be good). Respawn should keep the service running, spawn off the update and restart Sonarr. It stopping is odd, usually it just corrupts the install and its a mess.
Alright, I’ll set it to debug and wait for an update.
Hey, just a side note: OK, I get that we’re switching the name to Sonarr and I see you’re using it exclusively. But the service is still called “nzbdrone”. So for the sake of clarity, shouldn’t the service name be changed? Or is that something that would be the case if I did a fresh install??
bcsteeve:
OK, I get that we’re switching the name to Sonarr and I see you’re using it exclusively. But the service is still called “nzbdrone”. So for the sake of clarity, shouldn’t the service name be changed? Or is that something that would be the case if I did a fresh install??
You can name the service on your system however you want (its not something that comes from the deb package). As for NzbDrone.exe it will be renamed, but its not trivial, there are thousands of installations and dozens of possible configurations, we need to be very sure that we’re not going to break anything. We may end up deferring the executable name change to a major release which would be a manual update, we’ll see how testing goes.
OK, it happened again. This is the update log: http://pastebin.com/VFJrfR5x
After the failed update was Sonarr running?
Based on the logs its permissions or the file was locked for some reason.
No, after the failed update it wasn’t running. I started it and it was on the old version. I updated (via apt-get) and started and then it was running with the new version.
Can you try another chmod/chown/whatever you did before to make sure the user running Sonarr had permissions on the files? Wondering if the permissions aren’t enough on one or more of the files and its bombing out.
OK, well I can certainly confirm that the log is correct… the user running Sonarr (which is me) doesn’t have permission to access the /opt directory it is trying to use. Why is it trying to use that directory?? /opt is in root’s domain. Sure I could chmod/chown it to loosen it up, but I’m not sure that’s a good idea. Why not contain those files somewhere that already has permission (based on the install instructions, or by storing them in the users’ home directory).
I’m not sure why you said “whatever [I] did before”… did “before” what?
You should be getting health check warning about the folder being write protected, the whatever you did before is nothing in this case (or you did something and don’t recall).
You can either move Sonarr to a new location of give your user write access to /opt/NzbDrone - it needs permissions to update otherwise its going to continue to fail.
I’m not sure what a health check warning is, but I haven’t seen any (I vaguely remember one about my version of mono not being up to snuff, but that was before I updated to Ubuntu 14.04).
I changed the ownership of the folder. Problem should be resolved now, but I’ll have to wait for another update to know.
Thanks for your help.
OK, problem isn’t resolved. I’d like to get this fixed.
The last entries in my log are this:
14-12-30 16:01:20.5|Info|InstallUpdateService|Downloading update 2.0.0.2549
But it doesn’t restart… or whatever it does do results in a non-working Sonarr. When I manually try to start the service:
sudo start nzbdrone
I get the following response:
nzbdrone stop/waiting
If I try to STOP it, I get:
stop: Unknown instance:
My resolution seems to be to update using apt-get and then rebooting.
What does the update log show (System -> Logs -> Updates), that part of the log just shows the updater starting.
I suspect its an issue with deleting either the UI or Update folder within /opt/NzbDrone, due to permissions issues (apt-get re-add the update folder with different permissions and messes things up).
We need to fix the apt-get issue with having that folder, but a chown/chmod should fix it up.
upstart isn’t starting the service because NzbDrone.exe was deleted and the rollback to restore it failed (another issue) and its not stoppable because its not actually running.
This is the latest update log:
14-12-31 15:40:27.4|Info|UpdateApp|Updating NzbDrone to version 2.0.0.2556
System.UnauthorizedAccessException: Access to the path “/opt/NzbDrone/NzbDrone.Update/ICSharpCode.SharpZipLib.dll” is denied.
I swear I changed the permissions on that folder before but now I see /opt/NzbDrone/NzbDrone.Update is root:root again. I guess that’s what you meant about apt-get messing it up. OK, I’ll apt-get update it again and check/change the folder permissions after and hopefully the next update will work.
Thanks.
This is fixed in the latest versions of the debian packages (develop and master).
Sorry to come back to this…
So now if I leave everything alone, it works (yay!). But (!!!) when I go to apply updates to my server, it will show nzbdrone needing updating even though the auto update did its thing (successfully). When I go ahead and run the updates (including nzbdrone), I guess it re-overwrites the permissions on those files and I’m hooped all over again.
So I wonder, do I need to somehow take nzbdrone out of my system’s updating? How do I do that?
Sorry, I just saw this other post after I hit submit (Ruh roh. NzbDrone.exe missing ) and see that maybe I just need to do this one more time
Remove the repo from /etc/apt/sources.list.d/sonarr.list
The reverse of what you did when [installing] (https://github.com/Sonarr/Sonarr/wiki/Installation#debianubuntu )
