Ultimate Backup Ultimate Backup und Autostart funktioniert nicht

[PsychoHH]

Danke für deine Hilfe.

Das mit check_autostart kann so bleiben wie es ist.
Es bringt nichts, dies zu verändern. Das ganze hat im ersten Teil ein $, da hier eine Variable bzw. die Datei abgefragt wird, genauer gesagt der Variablenwert von autostart.
Deshalb darf hier auch kein "autorun_restricted" stehen.

folgender one liner sollte genügen.

[ -z "$autorun_restricted" ] && autorun_restricted="0"

 

[Anguel]

@PsychoHH @Tommes:

Würde mich sehr freuen, wenn ihr meine Erkenntnisse aus #19 kurz kommentieren könntet:
https://www.synology-forum.de/showt...rt-nicht/page2&p=777859&viewfull=1#post777859

Danke im Voraus.

 

[PsychoHH]

Ohne begrenzen Mithilfe von maxdepth kann es natürlich dauern ist klar.
Allerdings sollte es zu keinem Abbruch deswegen kommen auch nicht nachdem das Script gestartet wurde.

Bei mir wird hier auch alles richtig vermerkt.

Evtl mal Zeitstempel mit in die Ausgabe hauen und auch mit den logs vom Script überprüfen. Theoretisch könnte man auch vor und nach find einen Zeitstempel schreiben lassen und auch find umleiten.

Die Befehle werden nacheinander abgearbeitet, da hier keine Aufgabe in den Hintergrund geschickt wird.

 

[Anguel]

Theoretisch könnte man auch vor und nach find einen Zeitstempel schreiben lassen und auch find umleiten.

Das Problem ist, dass das Skript wohl komplett abbricht, sobald das find ausgeführt wird. Ein echo nach dem find findet nicht mehr statt.
Auf der Kommandozeile funktioniert das find wiederum. Es braucht evtl. ein paar Sekunden, aber so lange auch nicht.
Ein testweise sleep mit 15 Minuten im Skript verursacht auch kein Timeout.
Ich habe echt keine Ahnung, woran es liegen könnte, dass das Skript mittendrin aussteigt.
ong10 wird evtl. die Tage mal testen, ob bei ihm auch das find die Ursache für das nicht-funktionierte Autorun sein könnte. Mit dem maxdepth 1 startet es bei mir immer korrekt, bricht dann aber nach dem Ablauf des eigentlichen Backup-Skripts erneut ab, so dass es zum aufrufenden autostart-Skript nicht mehr zurückkehrt...

 

[PsychoHH]

Wie wäre es denn den exit Code nach dem ausführen des Scriptes umzuleiten?

 

[Anguel]

Du meinst den Exit-Code des /volume1/@appstore/UltimateBackup/includes/autostart Skriptes? Wie könnte man das machen? In dieser 99-ubautostart.rules ?

 

[PsychoHH]

Nein ich meinte z.B. wie folgt. direkt in der autostart
Ist aber selbst in der 1.3.2 schon integriert, weswegen es auftauchen sollte.

exit_script=$?
echo "$script beendet - exit:$exit_script" >> "$log"

Du kannst doch aber im jeweiligen Backuplog sehen wie der letzte Stand war.
Läuft das Backup denn durch, wenn du dies manuell ausführst?

Problem ist eigentlich, bei mir klappt es.
Ich werde aber verschiedene exits ausgeben und ins Log schreiben, damit man es detaillierter bekommt.

 

[Anguel]

exit_script=$?
echo "$script beendet - exit:$exit_script" >> "$log"

So weit kommt es nicht, da als Letztes die Zeile 77 der Datei autostart ausgeführt wird:

sh "$script"

Das dort aufgerufene eigentliche Backup-Skript wird erfolgreich ausgeführt, es findet nur keine Rückkehr zu autostart zurück.

Läuft das Backup denn durch, wenn du dies manuell ausführst?

Ja, sowohl wenn ich es manuell starte als auch automatisch beim Einstecken der ext. USB-Platte. Das automatische Starten setzt aber wie bereits geschrieben eine Modifikation der Zeile 47 der autostart voraus:

script_find=$(find $mount ! -name "end_rsync_*" ! -name "start_rsync_*" -name "rsync_*.sh" -o -name "autorun")

und zwar um maxdepth 1. Wenn diese nicht gemacht wird, bricht das autostart bereits in dieser Zeile 47 ab.

Problem ist eigentlich, bei mir klappt es.

Bei mir leider nicht und bei einigen anderen wohl auch nicht :-( Mit maxdepth wird das Skript zumindest automatisch gestartet, ein auswerfen der USB-Platte nach dem Backup findet aber nicht mehr statt, da das autostart nach Zeile 77 nicht weiter läuft.

Gibt es eine Möglichkeit den exit-Code der autostart abzufangen? IMHO bricht genau dieses Skript ab.

 

[PsychoHH]

99-ubautostart.rules löschen und dann das autostart script einfach per Terminal ausführen und schauen welchen exit es gibt.

Hast du mal geschaut ob die autostart weiterläuft ?
Könnte man per Terminal erfahren:
ps aux | grep autostart


Schon mal gecheckt ob die Rechte vom Script korrekt sind? Evtl sonst mal chmod +x setzen.
Hast du mal eine andere Platte probiert oder einen Neustart durchgeführt?

 

[Anguel]

Wie von mir anfangs vermutet, kommt es wohl zum timeout. Ich finde folgendes in /var/log/messages:

2018-06-26T11:05:11+02:00 DiskStation hotplugd: hotplugd.c:1338 ##### ACTION:add
2018-06-26T11:05:11+02:00 DiskStation hotplugd: DEVNAME:sdq
2018-06-26T11:05:11+02:00 DiskStation hotplugd: DEVICE:/proc/bus/usb/002/005
2018-06-26T11:05:11+02:00 DiskStation hotplugd: DEVGUID:37534759583244430
2018-06-26T11:05:11+02:00 DiskStation hotplugd: DEVPATH:sdq
2018-06-26T11:05:11+02:00 DiskStation hotplugd: SUBSYSTEM:block
2018-06-26T11:05:11+02:00 DiskStation hotplugd: PHYSDEVPATH:/devices/pci0000:00/0000:00:15.0/usb2/2-3/2-3:1.0/host7/target7:0:0/7:0:0:0
2018-06-26T11:05:11+02:00 DiskStation hotplugd: hotplugd.c:1501 ==== USB disk [sdq] plugged in ====
2018-06-26T11:05:11+02:00 DiskStation hotplugd: hotplugd.c:1502 goto USB disk, szDeviceName=sdq
2018-06-26T11:05:11+02:00 DiskStation hotplugd: external_storage_parts_vol_info_get.c:105 Dev:sdq cannot find PostfixNumber.
2018-06-26T11:05:13+02:00 DiskStation synocheckshare: synocheckshare_vol_mount.c:47 Export Share [USB] [/dev/sdq1] [/volumeUSB1/usbshare]
2018-06-26T11:05:13+02:00 DiskStation synoiscsiep: iscsi_start_all.cpp:118 Successfully started iSCSI service.
2018-06-26T11:05:41+02:00 DiskStation udevd[9571]: timeout '/usr/syno/synoman/webman/3rdparty/UltimateBackup/includes/autostart sdq1'
2018-06-26T11:05:42+02:00 DiskStation udevd[9571]: timeout: killing '/usr/syno/synoman/webman/3rdparty/UltimateBackup/includes/autostart sdq1' [9673]
2018-06-26T11:05:42+02:00 DiskStation udevd[9571]: '/usr/syno/synoman/webman/3rdparty/UltimateBackup/includes/autostart sdq1' [9673] terminated by signal 9 (Killed)

Nach kurzem googlen ist es wohl so, dass man über udev keine längeren Prozesse starten soll, also irgendwie auslagern. Oder evtl. das udev Timeout ändern?
Als Linux-Anfänger bin ich an dieser Stelle aber etwas überfordert. Aber vielleicht hat PsychoHH eine Idee, wie man es am besten macht.

 

[PsychoHH]

Das sind doch mal Ausgaben mit denen wir arbeiten können. Hab diese Meldung noch nicht gesehen.
Theoretisch müsste man das Script dann nur im Hintergrund schicken per &.
Ob dies direkt in der rules bei PROGRAM geht weiß ich noch nicht.
Sonst muss man ein Script zwischenschalten.

 

[Anguel]

Momentan teste ich hiermit:
https://ubuntuforums.org/showthread.php?t=1098089&p=6906858#post6906858

 

[PsychoHH]

Genau das meinte ich.
Berichte mal ob es klappt.

 

[Anguel]

Habe alles nach #!/bin/sh in
{
...
} &

eingekapselt, jetzt läuft es durch und wirft auch die USB-Platte am Ende aus

Zwar immer noch ein timeout im Log, aber das eigentliche Skript läuft ja im Hintergrund weiter. Es wird wohl auch eine elegantere Lösung geben.

Evtl. müsste man prüfen, ob so eine Hintergrund-Ausführung keine Nebenwirkungen hat.

2018-06-26T13:37:30+02:00 DiskStation kernel: [94807.303780] xhci_hcd 0000:00:15.0: device is plugged out, empty URBs
2018-06-26T13:37:30+02:00 DiskStation kernel: [94807.327655] xhci_hcd 0000:00:15.0: Cannot set link state.
2018-06-26T13:37:30+02:00 DiskStation kernel: [94807.333958] usb usb2-port3: cannot disable (err = -32)
2018-06-26T13:37:49+02:00 DiskStation kernel: [94815.640141] ............ready
2018-06-26T13:37:49+02:00 DiskStation kernel: [94826.683048] sd 9:0:0:0: [sdq] No Caching mode page found
2018-06-26T13:37:49+02:00 DiskStation kernel: [94826.689226] sd 9:0:0:0: [sdq] Assuming drive cache: write through
2018-06-26T13:37:52+02:00 DiskStation hotplugd: hotplugd.c:1338 ##### ACTION:add
2018-06-26T13:37:52+02:00 DiskStation hotplugd: DEVNAME:sdq
2018-06-26T13:37:52+02:00 DiskStation hotplugd: DEVICE:/proc/bus/usb/002/007
2018-06-26T13:37:52+02:00 DiskStation hotplugd: DEVGUID:37534759583244430
2018-06-26T13:37:52+02:00 DiskStation hotplugd: DEVPATH:sdq
2018-06-26T13:37:52+02:00 DiskStation hotplugd: SUBSYSTEM:block
2018-06-26T13:37:52+02:00 DiskStation hotplugd: PHYSDEVPATH:/devices/pci0000:00/0000:00:15.0/usb2/2-3/2-3:1.0/host9/target9:0:0/9:0:0:0
2018-06-26T13:37:52+02:00 DiskStation hotplugd: hotplugd.c:1501 ==== USB disk [sdq] plugged in ====
2018-06-26T13:37:52+02:00 DiskStation hotplugd: hotplugd.c:1502 goto USB disk, szDeviceName=sdq
2018-06-26T13:37:52+02:00 DiskStation hotplugd: external_storage_parts_vol_info_get.c:105 Dev:sdq cannot find PostfixNumber.
2018-06-26T13:37:54+02:00 DiskStation synocheckshare: synocheckshare_vol_mount.c:47 Export Share [USB] [/dev/sdq1] [/volumeUSB1/usbshare]
2018-06-26T13:37:54+02:00 DiskStation synoiscsiep: iscsi_start_all.cpp:118 Successfully started iSCSI service.
2018-06-26T13:38:22+02:00 DiskStation udevd[18419]: timeout '/usr/syno/synoman/webman/3rdparty/UltimateBackup/includes/autostart sdq1'
2018-06-26T13:44:53+02:00 DiskStation hotplugd: hotplugd.c:1338 ##### ACTION:remove
2018-06-26T13:44:53+02:00 DiskStation hotplugd: DEVNAME:sdq
2018-06-26T13:44:53+02:00 DiskStation hotplugd: DEVICE:/proc/bus/usb/002/007
2018-06-26T13:44:53+02:00 DiskStation hotplugd: DEVGUID:37534759583244430
2018-06-26T13:44:53+02:00 DiskStation hotplugd: DEVPATH:sdq
2018-06-26T13:44:53+02:00 DiskStation hotplugd: SUBSYSTEM:block
2018-06-26T13:44:53+02:00 DiskStation hotplugd: PHYSDEVPATH:/devices/pci0000:00/0000:00:15.0/usb2/2-3/2-3:1.0/host9/target9:0:0/9:0:0:0
2018-06-26T13:44:53+02:00 DiskStation hotplugd: hotplugd.c:1510 ==== USB disk [sdq] plugged out====

 

[PsychoHH]

Das klingt sehr gut.
Manchmal gibt es nur Unterschiede, wenn man Sachen umleiten will und ein Script im bg läuft.
Gibt ja auch noch nohup, aber es läuft ja

 

[Anguel]

Habe noch diese Anleitung gefunden: http://www.reactivated.net/writing_udev_rules.html#external-run

Gibt es einen bestimmten Grund, dass ihr PROGRAM= statt RUN= verwendet? Ich habe unten mit rot einige Stellen markiert, die mir Sorgen bereiten.

Running external programs upon certain events

Yet another reason for writing udev rules is to run a particular program when a device is connected or disconnected. For example, you might want to execute a script to automatically download all of your photos from your digital camera when it is connected.

Do not confuse this with the PROGRAM functionality described above. PROGRAM is used for running programs which produce device names (and they shouldn't do anything other than that). When those programs are being executed, the device node has not yet been created, so acting upon the device in any way is not possible.

Stattdessen soll besser RUN verwendet werden, wenn ich richtig verstehe. Hier wird auch auf die Sache mit dem Timeout hingewiesen:

The functionality introduced here allows you to run a program after the device node is put in place. This program can act on the device, however it must not run for any extended period of time, because udev is effectively paused while these programs are running. One workaround for this limitation is to make sure your program immediately detaches itself.

Here is an example rule which demonstrates the use of the RUN list assignment:

KERNEL=="sdb", RUN+="/usr/bin/my_program"

When /usr/bin/my_program is executed, various parts of the udev environment are available as environment variables, including key values such as SUBSYSTEM. You can also use the ACTION environment variable to detect whether the device is being connected or disconnected - ACTION will be either "add" or "remove" respectively.

udev does not run these programs on any active terminal, and it does not execute them under the context of a shell. Be sure to ensure your program is marked executable, if it is a shell script ensure it starts with an appropriate shebang (e.g. #!/bin/sh), and do not expect any standard output to appear on your terminal.

 

[Tommes]

Als Linux-Anfänger bin ich an dieser Stelle aber etwas überfordert.

Für einen Linux-Anfänger, wie du dich selbst betitelst, bist du aber ganz schön taff!

 

[Anguel]

Für einen Linux-Anfänger, wie du dich selbst betitelst, bist du aber ganz schön taff!

Naja, einige Grundkenntnisse habe ich und mit Programmier- und Computerkenntnissen, Google und Englisch kommt man schon weit
Als Fortgeschrittener wäre ich wohl sofort auf die Idee gekommen in /var/log/messages zu schauen ;-)

 

[Tommes]

...wäre ich wohl sofort auf die Idee gekommen in /var/log/messages zu schauen ;-)

Ob du es glaubst oder nicht, aber wir haben bereits eine Funktion für das nächst größere Release von Ultimate Backup - welches irgendwann in ferner Zukunft mal erscheinen wird - eingebaut, wo wir alle Protokolle unter /var/log nach relevanten Einträgen durchsuchen können, die unser System betreffen.

 

[Anguel]

Das hört sich sehr gut an. Leitet bitte auch die stderr-Ausgabe ( 2>>... ) des rsync in ein Log um, so hat man einen genauen Überblick über die Fehler, die das Programm direkt ausspuckt. Diese sind äußerst hilfreich im Gegensatz zu dem undurchsichtigen Error-Code, der jetzt am Ende ausgegeben wird.