Jobs stuck at 100% #1095
Comments
|
|
We need a bit more information. |
|
also, change your logging level to DEBUG |
|
Apologies, I was away a few days. Opensuse 42.3 with Python 2.7.13 |
|
Could you possibly switch back to |
|
I see similar issue with SABnzbd 2.3.2 on OpenBSD/amd64 6.2-current (Feb 2 18:24:53 MST 2018) on Python 2.7.14 and SABYenc module 3.3.2 (without sabyenc also had this problem). |
|
Please verify that all your servers are working correctly by doing a server test. |
I belive they are working as problem started after upgrade of SABnzbd. I took the failed nzb-file and used very simple Perl script which talks NNTP and fetches articles from a server and I have no issues downloading entire set. Then I verified archive with par2 cli and all is good. Each failed nzb-file from SABnzbd I verified like that and all works, but not for SABnzbd. |
|
Oke but please perform the server test within Sabnzbd just to be sure. |
|
This is from memory as I don't have problem at hand:
Yes, there were 2 files at 99% or 98%. On main view of the download page says 100% and all is green. Download was progressing as I could see space used on the disk and I could see network traffic from SABnzbd. I will do test server when I will have problem again. To do what you asked (test server and files not finished) I need some time. |
|
I've tested this today and when download is stuck going to settings and testing connection for two servers which I have defined is successful ( For the file today (which is small, only 1.6GB) all files in Web UI in under the NZB details (the folder icon) are at 100% and the whole nzb-set is also at 100% (main view, the queue), however from logs you can see which file(s) from the set is problematic: Then after a couple of minutes with the job at 100% logs which this: |
Directory |
|
Could you send me the whole debug log at safihre@sabnzbd.org? |
|
Do you mean |
|
Click in the interface on Status and Interface settings window and click Show Logging, that should include all. |
|
@kucharskim Could you go into Status and Interface settings window and there change the logging from |
|
Very strange, the log you send is the whole log right? No changes? |
|
It's current OpenBSD/amd64 VM running on qemu-kvm under Linux. |
|
Doing the same for me ;) Large queue about 2000 items, and it downloads and just stuck at 100% and nothing more ... Have sab 2.3.2 and ubuntu 16 |
|
What if you pause the queue, does it eventually continue? Because so far I've only seen this if the system just can't keep up with the writing to disk. |
|
paused and cannnot unpause hmm i also tried one single file in queue and it stuck at 100%, tried different settings at Switches but nothing helps also i cleaned with -c removed .sabnzbd files, did apt purge, installed again, still 100% stuck occurs |
|
Do you have any servers that are less reliable or unavailable? |
|
Closing until there are more logs to analyze. |
|
This is still present with 2.3.5RC1 and it seems it's related to |
|
Tested with SABnzbd.py-2.3.5 and problem is still there. I can reproduce this with attached 998-nzb-testing.nzb.gz each time disk space is below 40GB (see download_free setting) even when I use priority -> forced in web UI. |
|
to make sure I'm understanding this correctly, you set a download min space limit and sab pauses when you have less than that. |
This is expected behavior and it's not what is reported in this GitHub issue.
I know how to workaround the problem. However it's a bug as when priority is set to In version of sabnzbd 1.2.1 this worked as intended and was intuitive as I leveraged that feature a lot. It allows me to go through download queue which is paused because it's below 40GB of free space and hand pick items which are small enough and can be downloaded. |
|
Also, what is confusing, SABnzbd reports after idle download timeout, that nzb file failed and one can think download is damaged, but it's not. Using different nzb downloader fetches data successfully. |
|
Ah, now I understand it better. I could reproduce this probably.
What timeout do you mean? |
I didn't know how to best express this, but I was referring to above scenario in logs. When idle job finally gets removed, as it reached a timeout, didn't finish in time and in web UI is reporting the job as failed. |
|
so from your limited logs, you can see that the logic is in looking at a blanket logic of knowing if something stalled is hard because the job could just be giant or the system specs could just be low.. so trying to catch both scenarios requires better logic than what we have currently (use cpumarks/job size/etc to alter the logic) |
|
As I jump from 1.2.1 to 2.3.x behavior change could be done not even recently. I would need to look deeper, but interesting change which caught my eye is 3d6dfec. Based on my testing behavior is driven by |
|
My repro steps with following diff: makes it work again, like it was with version 1.2.1. This reverts part of 3d6dfec commit. |
|
so what i think is going on is that the job is idle, while idle it gets placed to re-process.. but then due to it being idle it gets removed/re-added to be re-processed.. so endless loop. to verify if this is true, in your logs can you do |
|
Hmmm interesting. That's probably what is happening. |
|
Thank you! |
|
Just had this happen on Windows 7 (2.3.9 [03c10dc]) (running as a binary). Just loops over and over again at 100% for 20 minutes so far. Update: it appears to be making progress, periodically I'm getting a Update 2: It eventually finished so not really an issue other than the UI and the log did not really indicate what it was actually doing leading to 25 minutes of panic ;) |
|
If you have a large Article Queue, it can be stuck indeed writing to disk and decoding. Those queues usually are in balance and not too big.. But sometimes :O |
|
I know this was closed, but I want to drop some more debugging here because it's definitely still an issue for many. I noticed a pattern in a lot of the "stuck at 100%" posts I've seen on reddit and the forums, in that a lot of it occurs on systems with bottlenecked drive IO. In my case I'm storing everything over NFS on GbE links, both What I noticed really is the log churn is EXTREMELY slow during the For a single one of my downloads there were 653 "Deleting file" lines in the logs. The average delta between them was 3.6 seconds with a standard deviation of 0.9, for a total of 2349.043 seconds. I think this points to this being less "broken" and more "highly inefficient". I haven't had a chance to dig into this post-processing script yet, but I'm guessing it's in there... |
|
I re-ran a bunch of my "slow to post-process" NZBs again using local storage for the |
using github latest develop, while i did think i was on master.
switch back to master and rebuilding teh queue. will close if it goes away.
seeing this type of activity over and over but the 100% jobs never actually get stopped.
manually stopping the jobs is not working.
rebuilding the queue did not fix.
restarting did not fix.
The text was updated successfully, but these errors were encountered: