NZBGet 14.2-15 won't start anymore

[ghost]

Hi,

i use NZBGet Community Package since V11 on my Synology DS413 and it works flawless. Today i updated to the newest Version 14.2-15 the normal way and i also updated to Phyton to 2.7.9-13.

NZBGet won't start any more ... just showing status as stopped - even after i tried to make it run again.

Can anyone confirm this behavior and please - can anyone fix it.

Thanx in advance.
Efty

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Dr-Bean]

Have you manually changed files/settings/permissions with the previous package? Maybe to run it as a different user, or to put log files in a different location?

You can log in as root to Putty/Terminal, and run /var/packages/nzbget/scripts/start-stop-status start. That output might be helpful. Also, checking the contents of /var/log/messages might give a hint.

Other than that, you could always do a clean install of the package: take note of the settings in NZBGet, remove it, and install it again.

[ghost]

@Dr-Bean

Thanx for the quick reply. Please believe me, i change nothing at my configuration except the updates of NZBGet and Python to the latest non beta releases. If i start the nzbget via terminal i receive nothing.

DiskStation> /var/packages/nzbget/scripts/start-stop-status start
Starting NZBGet ...
DiskStation> 

If i check the messages log i can't see nothing unusual. No new entries from NZBGet since November 2013!

After this i deinstalled NZBGet via the Package Manager. Then i rebooted the DS and installed it again. I receive the same behavior. If i start NZBGet it doesn't, the status is still stopped. If i use the command line to start it i only see the same as above.

DiskStation> /var/packages/nzbget/scripts/start-stop-status start
Starting NZBGet ...
DiskStation> 

I don't think it's a problem of NZBGet because some SABnzbd Users have the same Problem since the updated to the latest Python version. But i'm not a certificate specialist so i'm not a little bit helpless.

Maybe you have another idea!?

Efty

[Dr-Bean]

NZBGet and Python have nothing to do with each other. SABnzbd is Python based, NZBGet is not.

If you see Starting NZBGet without any errors, it would seem to me that it should be running. Note that if you start a package via the command line, that information is not passed on to Package Center: it will still say the package is stopped.

You can check if NZBget is running via the command line with /var/packages/nzbget/scripts/start-stop-status status.
Along with that, check if the file /usr/local/nzbget/var/nzbget.pid exists after you've started the package, and while you're there, check the content of /usr/local/nzbget/var/nzbget.log

[ghost]

@Dr-Bean

Wow, this reply was really quick - thanx for that.

I've done as told, here is the result.

BusyBox v1.16.1 (2015-01-07 14:54:54 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
DiskStation> /var/packages/nzbget/scripts/start-stop-status start
Starting NZBGet ...
DiskStation> /var/packages/nzbget/scripts/start-stop-status status
NZBGet is not running
DiskStation> /usr/local/nzbget/var/nzbget.pid
-ash: /usr/local/nzbget/var/nzbget.pid: not found
DiskStation> more /usr/local/nzbget/var/nzbget.log
Thu Mar 26 20:59:38 2015        ERROR        Error reading server info from disk
Thu Mar 26 20:59:38 2015        ERROR        Error reading diskstate for file /volume1/Multimedia/NZBGet/queue/stats
Thu Mar 26 20:59:50 2015        ERROR        Error reading server info from disk
Thu Mar 26 20:59:50 2015        ERROR        Error reading diskstate for file /volume1/Multimedia/NZBGet/queue/stats
Thu Mar 26 21:03:53 2015        ERROR        Error reading server info from disk
Thu Mar 26 21:03:53 2015        ERROR        Error reading diskstate for file /volume1/Multimedia/NZBGet/queue/stats
Thu Mar 26 21:19:47 2015        ERROR        Error reading server info from disk
Thu Mar 26 21:19:47 2015        ERROR        Error reading diskstate for file /volume1/Multimedia/NZBGet/queue/stats
Thu Mar 26 22:19:21 2015        ERROR        Error reading server info from disk
Thu Mar 26 22:19:21 2015        ERROR        Error reading diskstate for file /volume1/Multimedia/NZBGet/queue/stats
DiskStation>

If it's no Python Problem, the only other thing which was changed too is NZBGet itself. V14.1-xx works flawless. Is it possible to downgrade?

Efty

[Dr-Bean]

Well, that looks like there's an issue with the folders (contents) left behind after the previous package was removed. It might be an upgrade problem from within NZBGet, but that error is a bit obscure.

I'd suggest emptying the contents of those folders below /NZBGet. You don't need to remove the folders themselves.
Make sure NZBGet has access to those folders (on all levels, so on /Multimedia, /Multimedia/NZBGet, and so on, set read/write access for the users group in DSM)

With that done, try again.

[ghost]

@Dr-Bean

You are my Hero! Thanx you very much!!! The permissions are ok, but the 'queue' folder was the problem. I had to delete it, which was the solution.

Thanx you again for your help, advice and of course your time!

Efty

[SugarDesigns]

I can confirm that deleting the queue folder will solve any other problems relating the startup of the program.

[timwagg]

I can second that - been looking for days how to get my nzbget install working again. Multiple reinstalls, trying other software to no avail. Came across this post just before i was about to uninstall my whole automated setup.

Thanks for advise!

[Dr-Bean]

@hugbug, maybe you have an idea what's going on here? As you can see, this has popped up for some people after updating to nzbget 14.2 and now with 15.0, but I'm not sure what's causing it.

Apart from a couple posts on the nzbget forums, this isn't documented anywhere afaik. We can remove the queue dir on upgrade, but that probably has side effects...

[hugbug]

Although deleting of queue-directory helps it also means loosing the download history and statistics. Not good.

AFAIK in synocommunity each app has it's own user account.
Could it be that during update the old account was deleted and the new one (with the same name) was created? Although the user name is the same the internal id is different and the new account will not have permissions to the old directories. The files owner can be verified with

ls -l </path/to/queue/dir>

[Dr-Bean]

Accounts for packages are only created once, they aren't changed during a package upgrade.
To be clear, I wouldn't know how to cause or reproduce the issue, and I've never seen the issue myself (even though I've installed and upgraded the package a fair few times when testing the new versions)

/edit: as for deleting the queue dir: I figured as much. I'd rather not have to do it either :)

[Dr-Bean]

One addition to the above: The UID issue can happen when people remove and reinstall the package, (e.g. after running into the error the first time). Then the UID might be different from the original one and cause permission issues. We don't explicitly set permissions on the queue dir...that might be something to look at.

Other than that, a corrupt stats or queue file doesn't keep nzbget from starting (as you'd expect ;)).

[PP1979NL]

Hi Guys,

I think I have the same problem as is mentioned here above.
I tried the tips from above. Probably I'm doing something wrong.
Here is the output from putty:

DiskStation> /var/packages/nzbget/scripts/start-stop-status start
Starting NZBGet ...
su: must be suid to work properly
DiskStation> /var/log/messages
-sh: /var/log/messages: Permission denied
DiskStation> /var/packages/nzbget/scripts/start-stop-status status
NZBGet is not running
DiskStation> /usr/local/nzbget/var/nzbget.pid
-sh: /usr/local/nzbget/var/nzbget.pid: not found
DiskStation> /usr/local/nzbget/var/nzbget.log
-sh: /usr/local/nzbget/var/nzbget.log: Permission denied

Could someone pls help me out?

[Dr-Bean]

Re-closing: We can probably still count the cases reported for Synology on one hand, so I don't see how it's a package issue, but otoh, the issue isn't widely reported on the nzbget forums either...

I don't see a point in keeping this open though. The cause is unknown, and occurs very infrequently. We have a workaround/fix to apply for the individual cases if need be, and as a last resort, a reinstall of the package does the job.