Admin console not accessable after 15-1 update

[brinka123]

I loaded the 9.0 conf file using the nzbget settings in 12.0. Conf file is in /usr/local/etc
Currenly I have user permission problems. so nzbget is not running well. I start nzbget as deamon using ssh using root. In nzbget settings I set a username known on the NAS. Previously this worked. The owner of the deamon process is this User.

I got errors that nzbget can't store files etc. Currently I solved this to use root. But other problems occur.....

So currenly I also run on 15-1 with nzbget 12.0... First nzbget has to run well, so it downloads, verfifies and repairs.


And you are right the swap space is never used.

Regards.

[brinka123]

Looks like it is running in deamon again with my username and permissions.

[fvdw]

how do you start nzbget ?

And how did you setup the folder were nzbegt puts its downloads ?

[fvdw]

I was running nzbget in idle and nothing special happened, now I downloaded a file and after a while it is hanging and indeed the web interface has becomen not responsive, so at least i can now reproduce your problem.
Now need to study why this happens and how to solve it

(I was using fvdw-sl-15-1, nzbget 12-0 and kernel 199)

[brinka123]

I got the following error:
warning Sun Mar 16 2014 20:40:09 Skipping unpack for ****** due to par-failure
warning Sun Mar 16 2014 20:40:09 No more par2-files found
warning Sun Mar 16 2014 20:40:09 Could not verify *******: par2-file could not be processed

When I repair on windows using quickpar it works fine....

I am sure the libpar2 is patched..

I start nzbget -D from the ssh. I login as root. In the nzbget settings I set DeamonUsername to Andre. This User name is also configured in the admin console of the NAS. Has full access.
So when I access the download directory using samba with login Andre, i have the correct rights to read and delete....

Everything works now. Except above issue (And the hanging thing we are working on)....

Nice and not nice that you found the issue... I hope you can track this down what is happening...

[fvdw]

I am using now the 164 kernel, that keeps running for the moment when downloading.
it is downloading a 1 gigabyte file on the moment. I will try the same file with using the 199 kernel

ps I am pretty sure it is not that the nas runs out of ram while downloading, most of the memory is used as cache

[brinka123]

ps I am pretty sure it is not that the nas runs out of ram while downloading, most of the memory is used as cache

I also not thinking of ram consumption.

Be aware that the same issue happened with nzbget 9.0 also. Looks like a deadlock in file io or something.....

I checked on the par2 thing of nzbget 12.0 there are lots of issues with it. Don't know where you want to go but for me nzbget 9.0 was fine. Prio 1 is get the NAS stable.

I discovered once (maybe a coincedence): I had quite much file io by samba. Was also downloading with nzbget and refreshing the nzbget gui. I got the same issue.

[fvdw]

I did not make any progress. I downloaded with nzbget the same file with the 164 kernel and it went ok
Then I downloaded it again with the 199 kernel and also this time it went ok. I also downloaded a 1 GB file and it went fine :scratch

If seems to be something that happens by a combination of factors
Recently we found that a 5big1 user had a problem with samba. We disabled the send-file function in samba to solve it.
send_file is a system function I don't know if it has to do with this because in the previous version of the firmware the 3.9.5 kernel was already used.

[fvdw]

did you get the problem with using the 164 kernel ?

your previous posts are not clear on that

[brinka123]

Hi thanks for the focus on this issue.

My test setup was not OK with the 164 kernel, because nzbget was not fully operational due to user right problems. It looks like I solved the rights problems now.

So I didn't test on 164 yet.

To confirm that it is a difficult problem:
Last night 15-1 with nzbget 12.0 downloaded without a problem, but it was not parchecking and repairing due to the parcheck problems, it only downloaded. Maybe the issue occurs faster when parcheck and repairing is executed, this requires a lot of disk access. I also watched a movie (samba read) during downloading.

Does parchecking and reparing work at your side with nzbget 12.0??

I download items of 5 - 25 GB.....

Any idea how to approach such a problem ? I think we have to be able to reproduce it, but the external files we are downloading are not the same, it probably also independant of the file. But (I agree) circumstances.

So according to me test setup:
- File IO from samba (read,write) (To much load will block the nas console, but it doesn't crash)
- Download using nzbget.
- Http access by continuosly request page updates.
- Torrent download using transmission.

Then it will crash....

The crash is visible by the fact that
- the nas webpage is accessable, but no respons from actions.
- Also login with ssh is possible but commands like ps -f stop.
- The disk can't be switched off using the power button.
- Using samba, all files are normally accessable.

Regards.

PS send-file is switched off now, but maybe the root cause of the problem is not found yet.....