[mav2010]

Hallo zusammen,

ich habe das Problem, dass das Entpacken von einem gesplitteten Archiv (.rar, .r00, ..., r99, s00, s01, ..., s68) mit mehr als 99 Einzeldateien (in diesem Fall waren es 170) zu einem Fehler bei dem Entpacken führt. Das Log des Extractors (siehe Anhang) zeigt einen Java Fehler (too many open files). Ist das ein bekanntes Problem? Ich habe leider nichts dazu im Forum gefunden.

Meine Umgebung: Headless jDownloader auf Synology x64 NAS, neueste Version. Das RAR5 Beta Plugin ist installiert.

Ergänzung: habe gerade auf dem Mac mit der neuesten JDownloader Version getestet, gleiches Problem. Ebenso ohne RAR5 Beta Plugin - gleiches Problem. Es handelt sich in meinem Fall bei dem gesplitteten Archiv aber eh um ein RAR4 File. Klingt nach einem grundsätzlichen Problem in der Entpackungsroutine.

Übrigens ist mir in der Mac Version noch ein Fehler aufgefallen, evtl. hängt das zusammen: wenn man die Archiv überprüfen Funktionalität ausführt (auf Ordnerebene), zeigt er in der Übersicht aller zugehörigen Dateien nur die 101 Dateien, die mit .r* enden, nicht die .s* Dateien.

Danke und viele Grüße,
mav2010

[Jiaz]

Die Anzahl der geöffneten Dateien wird seitens des OS limitiert und dann knallt das Öffnen weiterer Dateien
java.io.FileNotFoundException: xxxx (Too many open files)
Unter Linux kannst du das Limit mittel ulimit erhöhen. Unter MAC musst mal Googlen.


Geb mal auf der NAS
ulimit -aH
ein und poste die Ausgabe hier

[mav2010]

Originally Posted by Jiaz

Geb mal auf der NAS
ulimit -aH
ein und poste die Ausgabe hier

Hi Jiaz,

das ist das Ergebnis, klingt erstmal nicht nach einem Problem:

admin@NAS:~$ ulimit -aH
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 22951
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 4096
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) 22951
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Viele Grüße,
mav2010

[Jiaz]

Ich kenne Rxx und Rxxx als gültige/unterstützte Endung für Multipart Archive von RAR

Sxx höre ich heute zum ersten mal und habe noch nie ein solches Archiv gesehen. Entsprechend kann der JDownloader das nicht.
Kannst du mir die Links zu einem solchen Archiv geben?

[oEFLKQzikCqw]

Originally Posted by Jiaz

Ich kenne Rxx und Rxxx als gültige/unterstützte Endung für Multipart Archive von RAR

Letzteres kenne ich nicht. Das verwendet WinRAR hier nicht. da gehts wenn nötig mit sxx und gegebenenfalls auch noch mit txx weiter.

[Jiaz]

Okay, nach r99 geht es mit s weiter usw. Kannte ich bis dahin nicht und sehe ich jetzt zum ersten Mal. Werde ich bei Zeiten einbauen.
Ein BspArchiv brauch ich nicht mehr, da ich das selbst erstellen kann.

Danke für den Hinweis!

[Jiaz]

@oEFLKQzikCqw: Korrekt. Ich dachte das einfach mehr Stellen genutzt werden, aber habe nun herausgefunden das es mit weiteren Buchstaben weitergeht

[Jiaz]

@mav2010: 4096 filedeskriptoren, ich hab hier 65k
du kannst ja mal schauen wieviel JD offen hat
lsof -p PID | wc -l
die PID findest du in der JDownloader.pid Datei im JDownloader Ordner

Kann aber auch gut sein, dass aufgrund des Fehlers die Dateien nicht mehr geschlossen werden. Werd ich sehen wenn ich mir das genauer anschaue

[mav2010]

Originally Posted by Jiaz

@mav2010: 4096 filedeskriptoren, ich hab hier 65k
du kannst ja mal schauen wieviel JD offen hat
lsof -p PID | wc -l
die PID findest du in der JDownloader.pid Datei im JDownloader Ordner

Kann aber auch gut sein, dass aufgrund des Fehlers die Dateien nicht mehr geschlossen werden. Werd ich sehen wenn ich mir das genauer anschaue

Habe den Befehl ausgeführt, es sind nur 5 File Handler offen. Dies steigt übrigens auch nicht an, wenn ich das Entpacken nochmal starte...

admin@NAS:~$ cat /volume1/\@appstore/JDownloader/JDownloader.pid 
31575
admin@NAS:~$ lsof -p 31575 | wc -l
5

Ich habe zur Sicherheit nochmal ohne PID Einschränkung gemessen. Der Wert auf dem gesamten NAS steigt von 2162 vor Start des Entpackungsvorgangs auf max. 2194 während des Entpackungsversuchs an und senkt sich dann wieder. Also nimmt auch kein anderer Prozess massiv File Handler in Anspruch.

[Jiaz]

mach mal ein sudo lsof -p ....
JDownloader läuft als root Nutzer und daher erst sudo su
dann ulimit -aH
und den lsof Befehl nochmal. Denn JDownloader MUSS mehr als 5 Dateien haben VIEL VIEL mehr!

[mav2010]

Originally Posted by Jiaz

mach mal ein sudo lsof -p ....
JDownloader läuft als root Nutzer und daher erst sudo su
dann ulimit -aH
und den lsof Befehl nochmal. Denn JDownloader MUSS mehr als 5 Dateien haben VIEL VIEL mehr!

Guter Punkt... ich vergesse immer wieder, dass auf dem Synology NAS alle Programme unter root laufen.

Also, ulimit ist gleich und im Ruhezustand sind es dann 199 File Handler:

ash-4.3# 
ash-4.3# ulimit -aH
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 22951
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 4096
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) 22951
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
ash-4.3# 
ash-4.3# lsof -p 31575 | wc -l
199

Während des Entpackungsvorgangs steigen die File Handler dann auf über 4.100 an.

Ich habe testweise das ulimit für open files auf 64.000 hochgesetzt und dann das Entpacken nochmal gestartet. Es bricht aber trotzdem quasi sofort ab und es werden auch jetzt nicht mehr als gut 4.100 File Handler geöffnet. Die Fehlermeldung im Extraction Log bleibt ebenso die gleiche ("Too many open files").

[Jiaz]

Danke für die Info! Ich werd mir das anschauen, wenn ich Unterstützung für diese Endungen einbaue. Sehr wahrscheinlich werden die Dateien nicht korrekt geschlossen und daher kommt es zu dem Überlauf der offenen Dateien

[Jiaz]

Mit dem nächsten Core Update sollte es gehen. Hab jetzt für 901 Parts Unterstützung drin (rar + r00+s00+t...+z99)
Auch das Problem mit den *zuvielen offenen* Dateien ist gelöst. Ursache war eine fehlende Abbruchbedingung.

[mav2010]

Update auf Rev #40389 kam gerade und was soll ich sagen: es läuft tadellos! Vielen vielen Dank für den schnellen Fix!

[Jiaz]

Danke fürs Feedback!