auto UnRar auf Synology Ds411J

[djtifosi]

Kann es sein, dass du den Befehl

echo "unrar" | nc <hier die IP-Adresse deines NAS einsetzen> 4444

versehentlich in der Shell deines NAS ausgeführt hast? Denn genau das verursacht die Exeption

de.djtifosi.autounrar.exceptions.SoecketServerException: java.net.BindException: Address already in use

Bitte führe den Befehl nur auf einem anderen System als deinem NAS aus, also z.B. auf der FritzBox.

Dass der nc-Befehl nun die Fehlermeldung Connection refused ausgibt ist normal, denn aufgrund des Fehlers wurde Auto UnRar beendet (siehe Log-Eintrag: FATAL: Error establishing socket server, exiting.)

Du müsstest also Auto UnRar erneut starten und dann von der FritzBox den nc-Befehl erneut ausführen, dann sollte es auch ohne Fehler klappen.

 

[Ixam]

Nein, ich bin sicher, dass ich den Befehl über die Shell der Fritz!Box ausgeführt habe. 100%ig - habe den Verlauf ja noch geöffnet.

 

[djtifosi]

Ok, und du bist dir auch sicher, dass zu dem Zeitpunkt der Auto UnRar-Prozess auch nur ein einziges Mal lief?

Denn wenn Auto UnRar mehrfach in Netzwerk-Modus gestartet wird, dann versuchen mehrere Prozesse, auf Port 4444 zu lauschen, was natürlich verboten ist.

Bitte check das doch nochmal mit einem ps | grep cacao

Edit: Ansonsten würde mir noch die Möglichkeit einfallen, dass zufällig ein anderes Programm auf deinem NAS zeitweise den Port 4444 verwendet. Um diesem Problem zu entgehen, ändere doch mal in deiner configuration.properties den Listening-Port auf z.B. 4441. Nicht vergessen, danach AU zu killen und neu zu starten.

 

[Ixam]

Ich habe es gerade noch einmal getestet.
Der gleiche Fehler erscheint immer wieder und AutoUnRar stürzt ab wenn ich versuche die Datei zu entpacken. AutoUnRar läuft auch nur ein einziges Mal, habe gerade nachgeschaut.

Das entpacken aller anderen von mit getesteten Dateien funktioniert aber soweit.

Was ebenfalls nicht funktioniert ist das Anstoßen des Entpackvorgangs durch Fritz!Load. Ich habe jetzt die Datei do_after_dl_and_transfer.sh entsprechend angepasst:

#!/bin/ash
# Diese Datei wird ausgeführt, wenn der Transfer abgeschlossen ist
# Dazu bitte den Haken in der Config setzen
### Achtung!!!
# Falls diese Datei gestartet werden soll, bitte in "shutdown_nas.sh" umbenennen, sonst
# wird sie bei jedem Update überschrieben!
########################################################################################### Ab hier den Code einfügen
echo "unrar" | nc 192.168.178.22 4444
########################################################################################### Hier nichts mehr einfügen
exit 0

Die Datei wird nach dem Entpackvorgang laut den Fritz!Load Download Log auch ausgefürt, es beinhaltet aber noch einen Fehler... Hier der Log aus F!L:

00:02:54 Downloadliste ist leer.
Die Datei do_after_transfer.sh wird aufgerufen ...
/var/media/ftp/OCZ-RALLY2-00/fritzload/bin/../bin/do_after_dl_and_transfer.sh: line 13: 
: not found
nc: cannot connect to remote host (192.168.178.22): Connection refused
/var/media/ftp/OCZ-RALLY2-00/fritzload/bin/../bin/do_after_dl_and_transfer.sh: line 15: 
: not found
MSG: 00:02: Die Datei do_after_dl_and_transfer.sh wurde ausgeführt

Wenn du mir in diesem Fall aber nicht weiterhelfen kannst / möchtest verstehe ich das, ich würde mich dann an das IP-Phone-Forum wenden, sobald das wieder erreichbar ist.

Viele Grüße...

 

[Ixam]

Ein weiterer Punkt, ich kann zwar die entpackten Dateien unter Windows löschen - die Ordner, in die die Dateien entpackt worden sind (die Ordner, die also den Namen des Archivs tragen) kann ich unter Windows aber nicht löschen.

drwxr-xr-x    2 root     root          4096 Jan  1 23:38 Testarchiv1234

Irgendetwas stimmt dabei auch nicht, habe es jetzt an mehreren Computern getestet.

Edit: Ich habe dein Edit von oben gerade erst gesehen - ich teste es einmal mit Port 4441 und gebe dir dann noch einmal eine Rückmeldung!

 

[djtifosi]

Mit was für einem Editor hast du denn die Datei do_after_dl_and_transfer.sh bearbeitet?

Mir erscheint es so, als hättest du die Datei im Windows-Format und nicht im Unix-Format gespeichert. Der Unterschied zwischen den beiden Formaten besteht darin, dass im Windows-Format eine Zeile mit carriage return + linefeed beendet wird, im unix-Format hingegen nur ein linefeed ohne carriage return verwendet wird. Daher auch die Fehlermeldungen in Zeile 13 und 15.

Ich empfehle dir, entweder vi in der Shell zu nutzen, oder dir den kostenlosen und meines Erachtens besten Editor Notepad++ herunterzuladen und auf deinem Rechner zu installieren. Denn damit kannst du Dateien auch im Unix-Format speichern.

 

[djtifosi]

Ein weiterer Punkt, ich kann zwar die entpackten Dateien unter Windows löschen - die Ordner, in die die Dateien entpackt worden sind (die Ordner, die also den Namen des Archivs tragen) kann ich unter Windows aber nicht löschen.

drwxr-xr-x    2 root     root          4096 Jan  1 23:38 Testarchiv1234

Irgendetwas stimmt dabei auch nicht, habe es jetzt an mehreren Computern getestet.

Das sieht nach einem Berechtigungsproblem aus, denn nur der User root hat auf das Verzeichnis Testarchiv1234 Schreibrechte.

Ich empfehle, Auto UnRar nicht als root zu starten, sondern als der User, mit dem du auch von deinem Windows-System auf den Samba- / CIFS-Share deines NAS zugreifst.

Wenn du AU nur als eingeschränkter User startest, dann wird eben dieser eingeschränkte User auch der Owner der Ordner, die AU anlegt. Und mit diesem eingeschränkten User gehst du dann ja auch per Samba / CIFS auf dein NAS.

Außerdem hat es natürlich sicherheitstechnische Vorteile, wenn man Programme nur als User mit eingeschränkten Rechten startet, denn im schlimmsten Fall (unbekannter Bug zerstört Dateien) können sie nur die Dateien zerschießen, auf die sie schreibberechtigt sind.

 

[Ixam]

Das mit dem Editor war schon einmal ein Volltreffer.
Habe die Datei nun mit Notepad++ bearbeitet - und jetzt funktioniert es.

Das mit dem User klappt leider nicht so wirklich, ich habe AU jetzt mehrfach mit unterschiedlichen Usern gestartet (Einmal der User, mit dem ich über Windows auf den gemeinsamen Ordner "Downloadserver" zugreife, und einmal mit dem User, mittels dem F!L auf das NAS zugreift) - ich kann aber unter Windows die Ordner in keinem der Fälle bearbeiten.

Die Ordner im Ordner "rdy" (also die Ordner, die die Namen der Archive tragen) kann ich unter Windows noch umbenennen.

Alle Ordner, die dann aus den Archiven entpackt worden sind kann ich nicht einmal umbenennen - es bricht mit der Fehlermeldung "Wird bereits von einem anderen Programm verwendet" ab.

Löschen kann ich keinen der Ordner: "Sie benötigen Berechtigungen zur Durchführung des Vorgangs. Sie müssen die erforderlichen Berechtigungen von "SYNOLOGY_DS211J\MAX-PC erhalte, um Änderngen an diesem Ordner durchführen zu können.

Das komische dabei ist, dass ich bei der letztgenannten Fehlermeldung auch mit genau diesem User MAX-PC AU gestartet habe und auch mit diesem User über Windows auf den Ordner zugreife!?

Wie kann das sein!?

DANKE schon einmal und eine gute Nacht.
Max

 

[djtifosi]

Okay, dann musst du wohl etwas mit den Ownern / Berechtigungen aufräumen. Hierfür zunächst als root einloggen, Auto UnRar beenden und anschließend die folgenden Kommandos absetzen:

chown -R MAX-PC:users /volume1/Downloadserver
chmod -R 755 /volume1/Downloadserver
chmod 777 /volume1/Downloadserver


chown -R MAX-PC:users /opt/auto-unrar
chmod -R 755 /opt/auto-unrar

Anschließend sind der User MAX-PC und die Gruppe users Owner deines AU-Folders inkl. Unterverzeichnisse bzw. deines Download-Folders ink. Unterverzeichnisse.

Wenn du dann AU als MAX-PC startest sollten auch alle Dateien und Ordner, die AU produziert den User MAX-PC als Owner haben und du solltest per Samba entsprechend zugriffsberechtigt sein.

Hat das mit dem Port 4441 denn geklappt?

Edit: Die Fehlermeldung "Wird bereits von einem anderen Programm verwendet" deutet darauf hin, dass AU vielleicht noch mit dem Entpacken beschäftigt war. Bist du dir sicher, dass der unrar-Job schon komplett durchgelaufen war, als du versucht hast umzubenennen? Du kannst übrigens die Log-Datei von AU recht komfortabel mit dem Kommando tail -f /opt/auto-unrar/log/auto-unrar.log überwachen.

Wünsch dir ebenfalls eine gute Nacht!

 

[Ixam]

Danke - Danke - Danke!
Jetzt läuft endlich alles, der Fehler mit den Berechtigungen lag bei mir, ich hatte einen Haken beim Verbinden des Netzlaufwerks vergessen bzw. nicht gesetzt (Siehe Screenshot im Anhang).

Über Port 4441 funktioniert jetzt auch alles ohne Absturz.
Ich bin gerade noch etwas am testen, wie sich das mit dem beenden von AU verhält. Am liebsten wäre es mir, wenn AU einfach immer im Hintergrund laufen würde - "egal was passiert" - das müsste im Netzwerkmodus so ja der Fall sein?!

AutoUnRar habe ich mit dem folgenden Befehl (nachdem ich mittels cd in das AU-Verzeichnis gewechselt habe) gestartet:

cacao -jar auto-unrar-1.0.jar -n &

Abschließend möchte ich noch sagen, dass ich die do_after_dl_and_transfer.sh im Fritz!Load-Verzeichnis noch einmal zum kopieren der Passwortliste angepasst habe:

cp /var/media/ftp/OCZ-RALLY2-00/fritzload/config/unrar_passwords.txt /var/media/ftp/cifs/
sleep 5
echo "unrar" | nc 192.168.178.22 4441

Das "sleep 5" habe ich eingefügt, so dass die unrar_passwords.txt auch sicher vollständig kopiert wird bevor der Entpackvorgang gestartet wird.

Zum Schluss: das Entpacken des Archivs mit der Datei "Bitrate; 320 kBit_s.txt" funktioniert nach wie vor nicht so recht - das Archiv wird zwar Entpackt aber die o.g. Datei kann ich unter Windows weder öffnen noch darauf zugreifen und sie löschen ("Das Element konnte nicht gefunden werden"). Das liegt wohl irgendwie an der Dateinamenbezeichnung mit dem Semikolon oder dem Unterstrich im Namen?!

Ansonsten funktioniert alles astrein und automatisch! DANKE.

 

[Ixam]

So, jetzt bin ich mit meinen Tests noch ein Stück weitergekommen:
Wenn ich F!L mit dem in meinem vorangegangenen Post genannten Befehl starte, so beendet sich das Script jedesmall, wenn ich die Shell (also das PuTTY-Fenster) schließe:

cacao -jar auto-unrar-1.0.jar -n &

Wie kann das sein, sobald ich das Fenster schließe kann ich mittels dem folgenden Befehl (über die Fritz!Box-Shell) AutoUnRar nicht mehr starten:

echo "unrar" | nc 192.168.178.22 4441

Logge ich mich dann wieder in die Shell des NAS ein und überprüfe mittels ps | grep cacao ob AU noch läuft, sehe ich nämlich - nichts - dass eben kein AU-Prozess mehr läuft.
Warum wird AutoUnRar beendet, wenn ich die Shell des NAS schließe, das sollte doch gerade im Netzwerk-Modus nicht der Fall sein?!
Ansonsten läuft alles, es wäre aber toll, wenn das auch noch funktionieren würde, denn sonst müsste mein PC ja wieder laufen
Viele Grüße.

 

[djtifosi]

Komisch, denn normal sollte das & dafür sorgen, dass der Prozess im Hintergrund läuft und keine Abhängigkeit mehr zur Shell hat.

Lies dir folgenden Artikel mal durch und befolge die im letzten Absatz beschriebene Vorgehensweise http://linuxwiki.de/ProgrammeStarten

 

[itari]

Komisch, denn normal sollte das & dafür sorgen, dass der Prozess im Hintergrund läuft und keine Abhängigkeit mehr zur Shell hat.

Vielleicht geht es ja mit Screens (IPKG) besser.

Üblicherweise bekommen die in den Hintergrund gesetzten Prozesse ja trotzdem einen Trapp auf die Terminalsignale (damit man sie auch ohne kill -9) abschießen kann. Dieser Trapp wird meist mit einem nohup stillgelegt.

Itari

 

[Ixam]

Danke für eure Antworten - ich habe Screen jetzt über IPKG installiert - and now? ...
Das müsste dann ja ähnlich wie hier beschrieben funktionieren.

Edit: Ich habe jetzt folgendes versucht - AU scheint aber dennoch nicht zu laufen, zumindest gibt das Startkommando aus der Fritz!Box-Shell nach wie vor einen Fehler zurück.

cd /opt/auto-unrar
screen -dmS autounrar /opt/auto-unrar/auto-unrar-1.0.jar

screen -ls gibt auch das Folgende aus: No Sockets found in /tmp/screens/S-root.

Das mit dem STRG-Z funktioniert leider nicht djtifosi, ich habe so das Gefühl, dass das mit PuTTY nicht funktioniert, bzw. nicht mit der Synology-Shell?!

 

[djtifosi]

Erstelle mal eine Datei mit dem Namen auto-unrar.sh in /opt/auto-unrar und bearbeite sie mit vi oder Notepad++

Dort fügst du den folgenden Inhalt ein:

#!/bin/bash
cd /opt/auto-unrar
cacao -jar auto-unrar-1.0.jar -n

Mache anschließend die Datei mit chmod 755 /opt/auto-unrar/auto-unrar.sh für den aktuellen User ausführbar.

Dann starte dieses Sehll-Script unter Zuhilfenahme von screen mit dem folgenden Kommando.

screen -dmS autounrar /opt/auto-unrar/auto-unrar.sh

 

[Ixam]

Datei mittels Notepad++ erstellt und Berechtigungen angepasst:

drwxr-xr-x    8 FRITZLOA users         4096 Jan  2 15:36 .
drwxr-xr-x   12 root     root          4096 Jan  2 14:48 ..
-rwxr-xr-x    1 FRITZLOA users       739592 Dec 30 15:08 auto-unrar-1.0.jar
-rwxr-xr-x    1 FRITZLOA users           65 Jan  2 15:36 auto-unrar.sh
drwxr-xr-x    2 FRITZLOA users         4096 Jan  1 18:45 conf
drwxr-xr-x    2 FRITZLOA users         4096 Dec 30 15:08 doc
drwxr-xr-x    2 FRITZLOA users         4096 Dec 30 15:08 interceptors
drwxr-xr-x    2 FRITZLOA users         4096 Jan  1 19:07 log
drwxr-xr-x    3 FRITZLOA users         4096 Dec 30 15:08 src
drwxr-xr-x    2 FRITZLOA users         4096 Jan  2 13:15 tmp

Hier das, was ich danach gemacht habe:

SYNOLOGY_DS211J> screen -dmS autounrar /opt/auto-unrar/auto-unrar.sh
SYNOLOGY_DS211J> screen -ls
No Sockets found in /tmp/screens/S-root.

Die Fritz!Box-Shell bestätigt das nur:

# echo "unrar" | nc 192.168.178.22 4441
nc: cannot connect to remote host (192.168.178.22): Connection refused

So, sitzt der Fehler jetzt hier vor dem Computer?... Ich verstehe es langsam nicht mehr, warum das nicht funktioniert, gibt es in dem Administrationsmenü der DiskStation vielleicht eine Option die Hintergrundprogramme grundsätlich verbietet? Oder kann ich irgendeine andere Grundeinstellung völlig falsch haben?

Weißt du noch eine andere Lösungsmöglichkeit?!

 

[itari]

Ich verstehe es langsam nicht mehr, warum das nicht funktioniert, gibt es in dem Administrationsmenü der DiskStation vielleicht eine Option die Hintergrundprogramme grundsätlich verbietet?

Wie kommst denn darauf? Der background-Operator '&' geht doch ohne Probleme, oder?

Kann ja sein, dass der Screens-Monitor nicht geht. Deswegen hatte ich ja auch die Empfehlung mit 'Vielleicht ...' eingeleitet.

Kannst ja auch mal die Shell wechseln (bash per IPKG installieren). Vielleicht hast da schneller Erfolg.

Itari

 

[djtifosi]

Was auch noch mal ein Versuch wert wäre, mittels nohup das hangup signal des Shell-Terminals ignorieren zu lassen. Modifiziere hierzu den Aufruf mal wie folgt:

nohup cacao -jar auto-unrar-1.0.jar -n &

Edit: Wikipedia beschribt die Funktionsweise ziemlich genau http://en.wikipedia.org/wiki/Nohup. Und da du nicht die bash verwendest, wird mir auch klar, warum der Prozess terminiert wird, sobald du das Terminal schließt.

 

[Ixam]

Ich habe jetzt Bash installiert:

ipkg install bash

Dann habe ich den Befehl "bash" aufgegeben und anschließend eben versucht "in Bash" die Befehle aufzugeben.

Funktioniert aber alles nicht - immer wenn ich das Terminalfenster schließe ist AU auch weg...

SYNOLOGY_DS211J> bash
bash-3.2# cd /opt/auto-unrar/
bash-3.2# cacao -jar auto-unrar-1.0.jar -n &
[1] 20590
bash-3.2#
Auto UnRar, Version 1.0 (stable)  Copyright (C) 2010  djtifosi

This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; see <http://www.gnu.org/licenses/> for details.

Updates of this program are available on the Auto UnRar project page at
<http://sourceforge.net/projects/auto-unrar/>.
Please report bugs using the Sourceforge bugs tracker.

2011-01-02 16:59:26,533 - INFO - AutoUnrarStarter - -------------------------------------------------
2011-01-02 16:59:26,572 - INFO - AutoUnrarStarter - Starting Auto UnRar, Version 1.0 (stable)  Copyright (C) 2010  djtifosi
2011-01-02 16:59:26,574 - INFO - AutoUnrarStarter - -------------------------------------------------
2011-01-02 16:59:26,575 - DEBUG - AutoUnrarStarter - Reading configuration from conf/configuration.properties
2011-01-02 16:59:26,589 - INFO - Configuration - -------------------------------------------------
2011-01-02 16:59:26,591 - INFO - Configuration - Configuration settings:
2011-01-02 16:59:26,593 - INFO - Configuration - UNRAR_APPLICATION_FOLDER = /opt/bin/
2011-01-02 16:59:26,594 - INFO - Configuration - SOURCE_FOLDER = /volume1/Downloadserver/
2011-01-02 16:59:26,595 - INFO - Configuration - TARGET_FOLDER = /volume1/Downloadserver/rdy/
2011-01-02 16:59:26,596 - INFO - Configuration - STATUS_MONITOR_FOLDER = /opt/auto-unrar/log/
2011-01-02 16:59:26,598 - INFO - Configuration - TEMPORARY_FOLDER = /opt/auto-unrar/tmp/
2011-01-02 16:59:26,600 - INFO - Configuration - SOCKETSERVER_PORT = 4441
2011-01-02 16:59:26,601 - INFO - Configuration - DELETE_SOURCE_FILES_AFTER_UNRAR = true
2011-01-02 16:59:26,602 - INFO - Configuration - ACTIVATE_STATUS_MONITOR = false
2011-01-02 16:59:26,604 - INFO - Configuration - SMALL_FILE_THRESHOLD = 1024
2011-01-02 16:59:26,605 - INFO - Configuration - ACTIVATE_RECURSIVE_EXTRACTION = false
2011-01-02 16:59:26,606 - INFO - Configuration - ACTIVATE_DEEP_RECURSIVE_EXTRACTION = false
2011-01-02 16:59:26,608 - INFO - Configuration - ACTIVATE_INTERCEPTOR_SCRIPT = false
2011-01-02 16:59:26,609 - INFO - Configuration - -------------------------------------------------
2011-01-02 16:59:27,750 - INFO - UnrarSocketServer - -------------------------------------------------
2011-01-02 16:59:27,752 - INFO - UnrarSocketServer - Socket server is listening for incomming connections on port 4441
2011-01-02 16:59:27,753 - INFO - UnrarSocketServer - -------------------------------------------------

Edit: Natürlich habe ich in Bash auch den von dir (djtifosi) als letztes vorgeschlagenen Befehl getestet - was auch keine Veränderungen hervorbringt:

nohup cacao -jar auto-unrar-1.0.jar -n &

Was mich wundert - wenn ich ps | grep cacao aufrufe wird das &-Zeichen nicht mehr hinter dem laufenden Prozess angezeigt...?!

SYNOLOGY_DS211J> ps | grep cacao
20590 root     32324 S    cacao -jar auto-unrar-1.0.jar -n
26396 root      2944 S    grep cacao
SYNOLOGY_DS211J>

 

[djtifosi]

Den nohup Befehl nicht in der bash, sondern in deiner terminal shell verwenden. Denn auch die bash wird ja beim verlassen der shell terminiert.