crashende sabnzbd

[zeroday]

Al tijden draai ik sabnzbd op een plugdevice (0.6.10), geinstalleerd via apt-get werkte dit voormidabel, ook de updates, de 0.6.10 is niet zoveel gebruikt en ik heb deze plugdevice uitgefaseerd en overgegaan naar een opvolger waar een HDD ingezet kan worden. De plugdevice draaid onder squeeze linux, aangezien daar de apt-get alleen tot versie 0.5.x heeft en ik toch naar versie 0.6.x over wil gaan heb ik de tar.gz versie voor python gepakt.
So far so good. Par2 gecompileerd: die gaf op de een of andere manier toch problemen en die heb ik kunnen hergebruiken op deze nieuwe device en toen leek sabnzbd beter te kunnen parren.

Het probleem echter: de 0.6.14 die ik in gebruik had crashte elke keer op grote nzbs die wel gedownload konden worden maar nadat het gedownload was grote problemen heeft met het parren en het checken van deze bestanden. (zo kon het zijn dat sabnzbd, die normaliter alleen TV series download, 6 dagen zonder problemen draaien, maar gisteren bij zeer grote (+15GB / 30GB sessies) bij het controleren van de bestanden crashed. Het gaat x keer goed en daarna stort sabnzbd ineen en is zonder een waarschuwing in mijn log en proceslijst verdwenen. Herstarten lijkt te werken maar sabnzbd komt als proces niet meer up. de load blijft hoog en ik moet de plugdevice resetten/herstarten. Ik heb geen flauw idee hoe ik in de shell de debug kan zien de /root/.sabnzbd/logs/sabnzbd.log geeft niet zoveel info waarom deze crashed.

Ik werd er zo moe van gisteren dat ik een oudere versie heb gepakt: 0.6.5 en ik heb een berg grote nzb bestanden erin gegooid ook deze moesten op bepaalde plekken gerepareerd worden en tadaa.. geen probleem met het repareren of het crashen van sabnzbd. Ik zou het eigenlijk nog een keer moeten testen met een nzb die zoveel problemen gaf, maar dat doe ik even niet...

Wellicht een heads up voor gebruikers dat ik na lang testen versie 0.6.14 dusdanig niet stabiel vind werken en een oudere versie mij een beter en stabieler gevoel geeft.
(update: 0.6.5 kan ook crashen, echter deze kan weer gestart worden na de crash), ook hier weer ergens bij het parren en/of verifieren ..

Mocht er mogelijkheden zijn om eea te debuggen en hoe, dan hoor ik dat graag.

de plugdevice heeft 512MB flash, 512MB SDRAM, een HDD met 320GB en een NFS verbinding naar een NAS met 8TB opslag, sabnzbd hoeft alleen te downloaden op de 320GB en stuurt nadat ie klaar is het bestand naar de NFS share.
Tuurlijk weet ik dat ik veel verlang van sabnzbd en het beestje, maar ik zou meer een aanwijsbare reden hebben waarom het mis gaat .. ;-)

[shypike]

De hardware houdt niet over, maar zou genoeg moeten zijn.
Het vreemde is dat juist bij de oudere versies een aantal mensen klaagden
over crashes bij jobs boven 20G.
Dit had te maken met een geheugenlek in een van de Python functies.
Dat is verholpen vanaf 0.6.10.

Het is me niet duidelijk wat je bedoeld met "0.6.5 kan ook crashen, echter deze kan weer gestart worden na de crash".
Wat is er dan anders geworden v.w.b. het herstarten?

SABnzbd doet niets zelf aan verificatie/reparatie/uitpakken, dat is 100% par2 en unrar/unzip.
Als die tools niet stabiel zijn, kan SABnzbd daar niets aan verbeteren.
Overigens het kan zijn dat de latere SABnzbd wat meer geheugen gebruiken waardoor
een par2 en/of unrar sessie net over het randje gaat.
Heb je een swap file?
Overigens kun je bij krap geheugen beter geen artikel cache gebruiken. Heb je die?

[zeroday]

De hardware houdt niet over, maar zou genoeg moeten zijn.
Het vreemde is dat juist bij de oudere versies een aantal mensen klaagden
over crashes bij jobs boven 20G.
Dit had te maken met een geheugenlek in een van de Python functies.
Dat is verholpen vanaf 0.6.10.

Het is me niet duidelijk wat je bedoeld met "0.6.5 kan ook crashen, echter deze kan weer gestart worden na de crash".
Wat is er dan anders geworden v.w.b. het herstarten?

SABnzbd doet niets zelf aan verificatie/reparatie/uitpakken, dat is 100% par2 en unrar/unzip.
Als die tools niet stabiel zijn, kan SABnzbd daar niets aan verbeteren.
Overigens het kan zijn dat de latere SABnzbd wat meer geheugen gebruiken waardoor
een par2 en/of unrar sessie net over het randje gaat.
Heb je een swap file?
Overigens kun je bij krap geheugen beter geen artikel cache gebruiken. Heb je die?

het verschil, maar ik ga me er nog wat meer in verdiepen is dat ik de 0.6.14, na een crash niet meer in mijn 'top' overzicht zag komen, ervanuitgaande dat deze dus crashed en niets meer doet. wanneer ik een ps -aux uitvoerde kreeg ik nimmer mijn shellprompt meer te zien, iets wat me heel vreemd lijkt en is.
Nu ik naar de 0.6.5 wat dieper heb gekeken zou het kunnen zijn dat het inladen van de cache dusdanig lang duurt dat dit een 'beperkende factor is, iets wat ik nog verder wil bekijken
ik lees dus dat ik beter 0.6.10 kan gebruiken ivm het geheugenlek, gaan we dan ook even 'doen ..
wat ik bedoel met 0.6.5 is dat ik na x tijd geen sabnzbd meer had lopen maar vanuit de shell kon ik sabnzbd weer starten en bleef deze ook beschikbaar, de UI was bereikbaar etc.

ik heb een swap op de HDD en ja ook artikel cache. (die laatste zal ik eens uitzetten).
persoonlijk vind ik het niet erg als unrar of par2 dingen doet wat niet kan en ik dan een issue zie met het gedownloade, maar het zou niet zo moeten zijn dat sabnzbd dan niet meer werkt. ;-)

[shypike]

IK ben inmiddels in gesprek met een andere embedded Linux gebruiker
die er achter gekomen is dat hij de Python module cPickle moet vervangen door Pickle
om de zaak stabiel te krijgen. Mogelijk speelt dit bij jouw situatie ook een rol.
http://forums.sabnzbd.org/viewtopic.php?f=3&t=9708

Hij heeft deze verandering aangebracht:
sabnzbd/__init__.py
regel met:

Code: Select all

import cPickle

veranderen in:

Code: Select all

import pickle as cPickle

Kun je dat eens proberen met 0.6.14?

[zeroday]

ik heb net weer een crash gehad .. (even wat dingen explicitiet geprobeert)

012-01-01 17:16:07,459::DEBUG::[newsunpack:531] Running unrar ['/usr/bin/unrar', 'x', '-idp', '-o-', '-or', '-p-', '/home/Downloads/incomplete/xxxxx/XXXX.rar', '/media/usenet/Unsorted/_UNPACK_XXXXX/']

dit was de laatst statement die ik in mijn log terug vond, en toen was sab weg
ik heb daarna eea weer proberen te starten. dat ging, maar de .ini was 'veranderd .. . Ineens port85 actief .. ipv80

ik zag ook een regel, waar je aan refereert voorbij vliegen
2012-01-01 18:59:46,431::ERROR::[__init__:815] Loading /home/Downloads/incomplete/xxxxx/__ADMIN__/SABnzbd_nzo_Gtl5Tk failed
2012-01-01 18:59:46,434::INFO::[__init__:816] Traceback:
Traceback (most recent call last):
File "/usr/local/src/sabnzbd/sabnzbd/__init__.py", line 807, in load_data
data = cPickle.load(_f)
EOFError

echter dit was nadat ik eea weer herstart had.

ik heb zojuist de code aangepast en kijk wat er gebeurd met het vervolg, er staat nog wat dingen in de queue ;-)

[shypike]

Tot nu toe klopt het aardig met wat de andere persoon rapporteert.

[zeroday]

Tot nu toe klopt het aardig met wat de andere persoon rapporteert.

gisteren 100GB in de queue en na de wijziging nog weer een crash en weer de unrar als laatste in de log.
ga nu eens proberen of ik hem weer kan resetten en dan sab niet laten downloaden als tie bezig is met de unrar ..


grappig: als tie gecrashed is en ik start sab weer dan is de port 80 weer teruggezet naar port 85, vandaar dat ik elke keer denk dat de UI crashed/killed is ..

[shypike]

als tie gecrashed is en ik start sab weer dan is de port 80 weer teruggezet naar port 85, vandaar dat ik elke keer denk dat de UI crashed/killed is ..

Blijkbaar houdt iets nog poort 80 bezet, waardoor een andere poort wordt gezocht.

[zeroday]

Weer op de unrar positie een crash, nu heb ik de optie aangezet dat sab dan maar even niet moet gaan downloaden, wellicht zal dat ergens wat schelen ..

update: de queue is nu helemaal weggewerkt, nadat ik sab de opdracht heb gegeven niet meer te downloaden als hij met een postprocessing job bezig is (verify/par/unpack)
het waren een stuk of tig pakketten van +5GB en 10GB .. (in totaal 100GB). Heb hem nu moeten herstarten omdat mijn sickbeard niet meer wilde lullen met sab ivm port 85, dus ik heb sab weer even terug op port 80 gezet.

We gaan het nu even in de gaten houden of het blijft draaien.

[zeroday]

Zo,
we zijn weer een paar dagen verder en we hebben weer wat informatie.

Ik heb sabnzbd 0.6.14 nog niet weer kunnen laten crashen .. ondanks een berg aan hele grote nzb's en downloads.
Mijn truuk is enerzijds de 'patch' toepassen, wat het probleem trouwens niet oplost en tegen sab vertellen dat hij niet mag downloaden als er een par of unrar sessie (postprocessing) aan de gang is.

iets zegt me dat sab geen gebruik kan/mag maken van de swap (HDD) (die blijft ongebruikt) waarbij de actieve memory wellicht te weinig wordt waardoor sab afsterft, vooral wanneer er een unrar sessie bezig is.

Het is jammer dat er gewacht moet worden, maar goed, geen onoverkomelijk probleem. Effectief duurt het dan wat uurtjes langer voordat iets beschikbaar is.. tsja..

[shypike]

Het lijkt me eerder dat het totale geheugengebruik van een downloadende SABnzbd
en een actieve par2/unrar te veel is voor het systeem.
Het is niet zo dat SABnzbd geen gebruik kan maken van de swap partitie.
Dat is de taak van de virtual memory manager van het operating system,
applicaties weten daar niets van.

[zeroday]

Het lijkt me eerder dat het totale geheugengebruik van een downloadende SABnzbd
en een actieve par2/unrar te veel is voor het systeem.
Het is niet zo dat SABnzbd geen gebruik kan maken van de swap partitie.
Dat is de taak van de virtual memory manager van het operating system,
applicaties weten daar niets van.

Helder... Wellicht is dit een help richting anderen met een low memory device