JDownloader Community - Appwork GmbH
 

Reply
 
Thread Tools Display Modes
  #1  
Old 17.02.2019, 08:17
mav2010 mav2010 is online now
Baby Loader
 
Join Date: Feb 2019
Posts: 5
Default Entpacken von gesplitteten Archiven mit mehr als 99 Dateien

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

Last edited by mav2010; 17.02.2019 at 12:58.
Reply With Quote
  #2  
Old 18.02.2019, 14:26
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 60,436
Default

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
__________________
JD-Dev & Server-Admin
Reply With Quote
  #3  
Old 18.02.2019, 14:32
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 60,436
Default

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?
__________________
JD-Dev & Server-Admin
Reply With Quote
  #4  
Old 18.02.2019, 14:37
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 60,436
Default


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!
__________________
JD-Dev & Server-Admin
Reply With Quote
  #5  
Old 18.02.2019, 14:46
oEFLKQzikCqw oEFLKQzikCqw is offline
JD Legend
 
Join Date: Mar 2012
Posts: 1,496
Default

Quote:
Originally Posted by Jiaz View Post
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.
Reply With Quote
  #6  
Old 18.02.2019, 14:48
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 60,436
Default

@oEFLKQzikCqw: Korrekt. Ich dachte das einfach mehr Stellen genutzt werden, aber habe nun herausgefunden das es mit weiteren Buchstaben weitergeht
__________________
JD-Dev & Server-Admin
Reply With Quote
  #7  
Old 18.02.2019, 17:42
mav2010 mav2010 is online now
Baby Loader
 
Join Date: Feb 2019
Posts: 5
Default

Quote:
Originally Posted by Jiaz View Post
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:

Code:
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
Reply With Quote
  #8  
Old 18.02.2019, 18:19
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 60,436
Default

@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
__________________
JD-Dev & Server-Admin
Reply With Quote
  #9  
Old 18.02.2019, 19:27
mav2010 mav2010 is online now
Baby Loader
 
Join Date: Feb 2019
Posts: 5
Default

Quote:
Originally Posted by Jiaz View Post
@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...

Code:
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.

Last edited by mav2010; 18.02.2019 at 19:31.
Reply With Quote
  #10  
Old 18.02.2019, 19:37
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 60,436
Default

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!
__________________
JD-Dev & Server-Admin
Reply With Quote
  #11  
Old 18.02.2019, 19:56
mav2010 mav2010 is online now
Baby Loader
 
Join Date: Feb 2019
Posts: 5
Default

Quote:
Originally Posted by Jiaz View Post
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:

Code:
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").
Reply With Quote
  #12  
Old 19.02.2019, 10:43
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 60,436
Default

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
__________________
JD-Dev & Server-Admin
Reply With Quote
  #13  
Old 20.02.2019, 20:57
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 60,436
Default

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.
__________________
JD-Dev & Server-Admin
Reply With Quote
  #14  
Old 20.02.2019, 22:53
mav2010 mav2010 is online now
Baby Loader
 
Join Date: Feb 2019
Posts: 5
Default

Update auf Rev #40389 kam gerade und was soll ich sagen: es läuft tadellos! Vielen vielen Dank für den schnellen Fix!
Reply With Quote
  #15  
Old 21.02.2019, 10:14
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 60,436
Default

Danke fürs Feedback!
__________________
JD-Dev & Server-Admin
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT +2. The time now is 22:06.
Provided By AppWork GmbH | Privacy | Imprint
Parts of the Design are used from Kirsch designed by Andrew & Austin
Powered by vBulletin® Version 3.8.10 Beta 1
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.