Autorun für ext. Datenträger

[Tommes]

Willkommen im Club der DSM Developer!

Ich habe mir dein Paket zwar noch nicht geladen (was ich natürlich noch nachholen werde), aber mich bereits ein wenig durch dein Repo gewühlt. Erfreulicher Weise hast du dabei u.a. auch ein paar Dinge aus meinem Demo Paket herangezogen.

Ich habe für Basic Backup eine eigene “autorun“ Funktion geschrieben, die ich “autopilot“ getauft habe. Vielleicht magst du dir das ja mal anschauen und für dich bzw. autorun nutzbar machen. Innerhalb Basic Backup kann man dabei auch über eine GUI einige Einstellungen für „autopilot“ treffen bzw. verändern. Den Link zum GitHub Repo zu Basic Backup findest du in meiner Signatur. Die Scriptdatei von “autopilot“ kannst du dir hier anschauen.

BTW: autopilot ist so gesehen auch ein Fork von autorun. Ich habe das Rad also nicht neu erfunden, nur für meine Zwecke umgeschrieben. Ich finde es aber toll, das sich (wieder) jemand um autorun kümmert und wünsche dir viel Erfolg.

Tommes

 

[ceee]

Ich habe einen Fork von Autorun für DSM 7 als Version 1.10.0-0001 in Github veröffentlich: https://github.com/schmidhorst/synology-autorun.

Vielen Dank dafür. Nachdem ich mit dem original gescheitert bin, habe ich diese Version ausprobiert und bin schon mal etwas weiter gekommen, dass man die Parameter anpassen kann ist schon mal super. Zusammen mit der sehr tollen Anleitung hier klappt es dann auch mit dem Ausführen des Scripts. Was leider (auf meiner DS720+) nicht funktioniert ist das mit den LEDs. Statt der Copy LED, die es auf der 7er nicht gibt, wird die Power LED angesprochen. Wenn die blinkt werde ich aber nervös , die Status-LED wird nicht orange. Ich weiss nicht ob die 7er das überhaupt kann. Beim originalen autorun wird die Status LED dunkel statt orange.

Als ich Anfangs noch eine falsche Task-ID verwendete klappte es mit exit 100 und dem Auswerfen. Bei den letzten Test-Ausführungen endete das Script immer mit Status 2 und die USB Disk bleibt gemountet.

 

[plang.pl]

Bei mir wird die Status LED orange. Liegt vermutlich am anderen Paket. Du kannst aber den "Farbwechsel" einfach im Script realisieren. Ich weiß nur grad den Befehl nicht mehr. Es gibt auch eine Info-Seite, wo alle Möglichkeiten mit den LEDs aufgeführt sind. Vielleicht kann sie z.B. @geimist an der Stelle noch einmal verlinken. Hatte er mir schonmal verlinkt, aber ich habs mir nicht aufgeschrieben und ich hab die Seite auch gerade nicht gefunden.
EDIT: Hab sie gefunden. Ist tatsächlich bei uns im Wiki. Schande über mich. Link

 

[Horst22]

Zum Thema LED:

Wenn die blinkt werde ich aber nervös , die Status-LED wird nicht orange. Ich weiss nicht ob die 7er das überhaupt kann. Beim originalen autorun wird die Status LED dunkel statt orange.

Bei mir wird die Status LED orange. Liegt vermutlich am anderen Paket. Du kannst aber den "Farbwechsel" einfach im Script realisieren. Ich weiß nur grad den Befehl nicht mehr. Es gibt auch eine Info-Seite, wo alle Möglichkeiten mit den LEDs aufgeführt sind. Vielleicht kann sie z.B. @geimist an der Stelle noch einmal verlinken. Hatte er mir schonmal verlinkt, aber ich habs mir nicht aufgeschrieben und ich hab die Seite auch gerade nicht gefunden.
EDIT: Hab sie gefunden. Ist tatsächlich bei uns im Wiki. Schande über mich. Link

Die Konfigurationsmöglichkeiten der Bedingen der LED-Steuerung in der Autorun-Version sind noch nicht richtig ausgetestet. Da kann es noch Fehler geben. Eine neue Version von Autorun ist in Arbeit und wird kommen.
Infos zur LED-Steuerung gibts auch unter https://smallhacks.wordpress.com/2012/04/17/working-with-synology-hardware-devsynobios-and-devttys1/, https://www.synology-forum.de/threads/leds-ausschalten-oder-runterdimmen.30013/#post-247250. In jedem Fall gilt, LEDs steuern geht nur mit root-Rechten!

 

[plang.pl]

Also ich muss ja sagen, dass mit der LED ist nur ne nette Nebengeschichte. Mir gehts hauptsächlich darum, dass das Backup läuft. Ich steh ja nicht neben der DS und beobachte die bei der Arbeit. Und wenn da etwas komisch blinkt während des Backups, dann weiß ich, dass es am Script/an dem Paket liegt und dann is auch gut.

 

[framp]

Im Prinzip stimme ich Dir zu.

Aber gerade eben habe ich einen ESP Sensor bei mir restartet - im konkreten Fall hat er sich einen neuen SW Stand von meinem Webserver downloaded und aktiviert und das wie programmiert per Blinkzeichen signalisiert. Somit weiss ich dass alles gut gelaufen ist.

Wenn ich eine Platte an die Syno haenge sind solche Blinksignale dass alles wie gewuenscht funktioniert bzw gestartet wurde schon sinnvoll

 

[Horst22]

Als ich Anfangs noch eine falsche Task-ID verwendete klappte es mit exit 100 und dem Auswerfen. Bei den letzten Test-Ausführungen endete das Script immer mit Status 2 und die USB Disk bleibt gemountet.

Soweit ich es verstehe, startest Du vom Autorun eine im Task-Scheduler definiert Aufgabe. Oder? Wann diese Aufgabe welche Codes zurückgibt, ist mir unbekannt.
Die in Arbeit befindliche nächste Version wird zusätzliche Konfigurationsmöglichkeiten enthalten. Zum einen, welche Rückgabe-Codes als Fehler gewertet werden sollen und die LED anders als bei Erfolg steuern sollen. Und auch, welche Rückgabecodes das Auswerfen triggern sollen, wird frei konfigurierbar sein:

Wenn Du auch beim Exit-Code 2 auswerfen möchtest: Vielleicht kannst Du bis zur Veröffentlichung der neuen Version ein zusätzliche Skript zwischenschalten, welches auch dann 100 zurückgibt?

 

[ceee]

Hallo!

Nein, ich starte ein Hyperbackup Task mit dem Standard-Script, was man hier mehrfach findet. Meine Stolperstellen waren bisher:
1. Statt einfach nur die ID als Nummer zu schreiben, also "4" wie in meinem Beispiel unten, habe ich "task_4" geschrieben. Erst als ich mal versuchte das Backup über die Konsole zu starten fand ich den Fehler raus.
2. Um nicht immer die dicke Platte ansschließen zu müssen, auf das das Backup nachher laufen soll hatte ich einen Stick genommen und das Verzeichnis darauf erstellt. Dass beim Erstellen des Backup-Jobs aber auch Dateien im Verzeichnis abgelegt werden und das Ziel offline ist, wenn diese Dateien nicht gefunden werden wusste ich nicht (mehr) sondern war davon ausgegangen, dass einfach der Pfad verfügbar sein muss.

Mein Script:

#!/bin/sh
/usr/syno/bin/synobackup --backup 4 --type local
sleep 60
while [ "$(/bin/pidof img_backup)" -o "$(/bin/pidof dsmbackup)" -o "$(/bin/pidof synoimgbktool)" -o "$(/bin/pidof synolocalbkp)" -o "$(/bin/pidof synonetbkp)" -o "$(/bin/pidof updatebackup)" ]do
  sleep 60
done
exit 100

Woher der Exit-code 2 kommt weiß ich nicht, er erscheint in der statusmeldung:

Das Skript /volumeUSB1/usbshare/sicheremich auf dem Gerät /volumeUSB1/usbshare wurde mit dem Ergebnis 2 beendet. Auf dem Gerät sind noch 7.4GBytes frei.

 

[plang.pl]

"4" wie in meinem Beispiel unten, habe ich "task_4" geschrieben

Das hätte ich in meiner Anleitung tatsächlich besser beschreiben müssen.

Woher der Exit-code 2 kommt weiß ich nicht, er erscheint in der statusmeldung:

Das Skript /volumeUSB1/usbshare/sicheremich auf dem Gerät /volumeUSB1/usbshare wurde mit dem Ergebnis 2 beendet. Auf dem Gerät sind noch 7.4GBytes frei.

Alles außer Exit Code 0 ist ein Fehler.
Dein Fehler ruht daher: Hyper Backup braucht mindestens 16 GB freien Speicher auf dem Medium.

 

[ceee]

Dein Fehler ruht daher: Hyper Backup braucht mindestens 16 GB freien Speicher auf dem Medium.

Echt Jetzt? Der Hyperbackup-Job, der zum testen natürlich klein ist, beschwert sich gar nicht und meldet alles i.O. Ich probiere ein größeren Stick...

Auch mit mehr freiem Speicher die gleiche Meldung. Ich hab aber mal mehr content rein gepackt, damit der Job länger läuft. Die Autorun-Meldung mit Ergebnis 2 kommt noch während der Backup-job läuft. Es scheint an der Überprüfung, ob das Backuptool noch läuft zu liegen. ?! Hab ich einen Copy & Paste Fehler irgendwo?

ARGH, das do war hoch gerutscht. Ich hab in meinem Script nun noch mal die Zeilen korrekt gesetzt, dann funktioniert es auch. Hyperbackup beendet und etwas später meldet sich Autorun mit Ergebnis 100 und unmountet auch

Die Status-LED reagiert jedoch gar nicht. Aktuell ist "2" eingestellt, also blinkend während des Runs, danach wieder an in grün.

Für mich ist die LED schon wichtig, da der full backup Job schon mal einen halben Tag dauern kann, da würde ich auch gerne ohne blick in die Mails sehen können, ob er durch ist oder nicht.

#!/bin/sh
/usr/syno/bin/synobackup --backup 4 --type local
sleep 60
while [ "$(/bin/pidof img_backup)" -o "$(/bin/pidof dsmbackup)" -o "$(/bin/pidof synoimgbktool)" -o "$(/bin/pidof synolocalbkp)" -o "$(/bin/pidof synonetbkp)" -o "$(/bin/pidof updatebackup)" ]
do
sleep 60
done
exit 100

 

[plang.pl]

ok gut.
Zu der LED kann ich nix sagen, ich verwende das andere autorun Tool, da geht es. Du kannst höchstens noch mal kucken, ob die LED im Script ändern lassen willst. Hierzu verweise ich auf meinen Post #863

 

[Tommes]

Hm... meiner Meinung nach, sollte der Benutzer selbst entscheiden dürfen, ob er eine optische und/oder akustische Signalausgabe haben möchte, oder nicht. Dabei finde ich die akustische Signalausgabe sogar noch viel interessanter und aussagekräftiger, als die optische Signalausgabe. Bei meiner App (kurz die Werbetrommel gerührt) Basic Backup, kann man die optische und akustische Signalausgabe z.B. für jeden Backup-Auftrag individuell ansteuern. Verwendet man darüber hinaus die AutoPilot Funktion (und schon wieder die Werbetrommel gerührt), was quasi der Pendant zu autorun darstellt, kann man die optische und akustische Signalsteuerung entweder ein- oder ausschalten. Grade beim Einstecken eines ext. Datenträgers mag ich es, wenn ich ein akustisches Singal von der DS erhalten, wenn das Backup startet und wenn es erfolgreich durchgelaufen ist. Traten während der Ausführung Fehler auf, quittiert das die DS mit 3 kurzen Piep-Tönen und der ext. Datenträger wird nicht ausgeworfen.

Zur Exit-Code Steuerung!
Deine Konfigurationsfreiheit in allen Ehren @Horst22, aber ich würde es nicht allzu komplex gestalten. Meiner Meinung nach sollte ein ext. Datenträger nur dann ausgeworfen werden, wenn ein exit 0 erfolgte oder wenn es der Benutzer ausdrücklich so haben möchte, was dann ja über einen exit 100 erfolgt. Das Problem bei dem exit 100 ist halt, das du nie weißt, warum dein Script nicht durchgelaufen ist, da du den exit Code des Scripts garnicht auffängst. Ich habe das bei Basic Backup / AutoPilot so gelöst, das ich mir nach dem Durchlauf eines Scriptes den exit Code mit einem exit ${?} Auffange und sollte dieser nicht gleich 0 sein, wird ein Protokolleintrag mit dem erhaltenden exit Code geschrieben. Wie gesagt... ist nur so eine Idee von mir, wie du es vielleicht umsetzten könntest. Ob du es tust, bleibt ja dir überlassen.

Ähm... oder fängst du bereits den exit Code des ausgeführten Scriptes ab? Ich muss zu meiner Schande gestehen, das ich mir dein autorun noch gar nicht näher angeschaut habe... ich hab mir nur deinen Script-Code auf GitHub kurz angeschaut. Das sollte ich vielleicht mal tun, bevor ich hier mit guten Ratschlägen um die Ecke komme. Sorry *räusper*

Tommes