Eigenes Skript nach anstecken vom USB-Stick ausführen

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo,

    wenn ich einen USB-Stick an meinen Raspberry Pi 3B steckte, dann pop das Fenster für die Aktion zum Wechseldatenträger auf. Ich kann dort nur den Dateimanager auswählen. Ich hätte gerne zusätzlich die Möglichkeit, dort mein Backup Skript auszuwählen.

    Kann mir jemand sagen, wie ich die Aktion hinzufügen kann?

    Ich suche schon lange im Netz, habe aber keine Infos dazu gefunden...

    Gruß

    Holger

  • Eigenes Skript nach anstecken vom USB-Stick ausführen? Schau mal ob du hier fündig wirst!

  • ich wusste doch das war schon mal!

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • das Stichwort heißt: udev Regel

    Nachtrag: damit kannst du das Backupskript automatisch ausführen lassen.

    Mit udev geht das aber leider nicht direkt, sondern nur über den Umweg einer systemd-Service-Unit. Und natürlich wieder mit der Einschränkung, dass unter UID 0 laufende Prozesse zunächst mal keinen Zugriff auf den xserver des Users haben.

    Darüber hinaus gibts es konkrete Beschränkungen für udev-Rules, siehe Man-Page, Sektion "run" und "program":

    Zitat:

    "PROGRAM

    Execute a program to determine whether there is a match; the key is true if the program returns successfully. The device properties
    are made available to the executed program in the environment. The program's standard output is available in the RESULT key.

    This can only be used for very short-running foreground tasks. For details, see RUN."

    Man kann das machen, man hat aber zu keiner Zeit die Gewährleistung, dass der Prozess ordentlich und von selber zu ende gekommen ist. Es besteht aber auch die Möglichkeit, dass er einfach entfernt wurde, mitten in der Arbeit. Für Backups ist das eine Katastrophe.

  • Ich hatte auch mal mit dieser Geschichte experimentiert, damals ging es um ein Programmiergerät für SD-Karten.

    Nur unsere Firma fand, das man ein neues Gerät kaufen sollte.

    Von meinem Projekt wussten sie nichts (Und das war gut so).

    Es fehlten eigentlich nur ein paar Kleinigkeiten, grundsätzlich lief es schon, es ist aber noch im Prototypstatus, also Achtung.

    Gedacht war an eine Blackbox in der der User einen SD-Card Reader(Writer) in einer der 4 USB-Buchsen steckt

    und in Abhängigkeit der entsprechenden Buchse eine entsprechende Datei mittels dd auf die SD-Karte gespielt wird.

    Auch hier wird mit udev gearbeitet, ist ein bißchen tricky, aber fangen wir mal mit den udev-Regeln an:

    sudo vi /etc/udev/rules.d/99-PROG.rules

    Code
    ACTION=="add", KERNEL=="sd?1", SUBSYSTEMS=="usb", SYMLINK+="PROG_%k", RUN+="/bin/bash /usr/local/bin/PROG.sh add %k"
    ACTION=="remove", KERNEL=="sd?1", SUBSYSTEMS=="usb", RUN+="/bin/bash /usr/local/bin/PROG.sh remove %k"

    Diese Regel wird immer dann aufgerufen wenn man einen Speicherstick in einem der USB-Ports steckt.

    Hier wird das Bash-Script PROG.sh aufgerufen, in der Übergabe steht entweder add oder remove und die Laufwerksbezeichnung (sda1-sdd1)

    Kommen wir zu sudo vi /usr/local/bin/PROG.sh

    Wenn man sich die Zeile mit PORT= genauer betrachtet, wird man sehen, das hier /dev/disk/by-path/ ausgewertet wird.

    Aber Achtung, sollte sich noch ein USB-Hub zwische RPi und SD-Karte befinden ändert sich die Zeile, genauer: Der Pfad.

    Das DEVICE wird in der Zeile darunter ermittelt.

    Ab jetzt habe ich eine Zuordnung von Device (z.B. sda) zu Port (z.B. Buchse rechts unten neben den Ethernet-Anschluss).

    Dem zufolge kann ich jetzt ein Script aufrufen das das Image aus den Ordnern (hier /IMAGE/IMAGE_(sda-sdd))

    auf das entsprechende Device schreibt. Also 4 unterschiedliche Images auf 4 SD-Karten "gleichzeitig".

    sudo vi /usr/local/bin/WRITE.sh

    Bash
    #!/bin/bash
    #
    # Das eigentliche Schreibprogramm
    PFAD=/IMAGE/IMAGE_$1
    #(pv -n -p $PFAD/raspian_stretch_s_.img | sudo dd status=none of=/dev/$2 bs=1M) 2> /tmp/PROG_$1.tmp
    /usr/bin/logger "von "/dev/$2" mit Pfad "$PFAD/raspian_stretch_s_.img

    Das Programm pv muss noch mit sudo apt install pv nach installiert werden, es ermöglicht eine Zustandsangabe,

    wie weit das Programmieren schon ist. Die Idee war, das auf ein LCDisplay (2004) mitzuschreiben.

    Diese Zeile ist erstmal auskommentiert, a) weil sie funktioniert und b) weil das programmieren beim testen einfach zu lange dauert.

    Zudem sind SD-Karten mit so einen Dauerbeschuß "not amused".

    So ganz Bugfrei ist das Projekt noch nicht, irgendetwas war noch nicht ganz richtig.

    Allerdings habe ich schon einmal 4 Images gleichzeitig beschrieben.

    Aber da ich zur Zeit andere Prioitäten habe ist es erstmal in der Prioritätenliste weit nach unten gerutscht.

    Vielleicht hilft es den einen oder anderen, normalerweise gebe ich nichts Halbfertiges raus.

    MfG

    Jürgen

  • Ich hatte schon in #7 drauf hingewiesen....

    This can only be used for very short-running foreground tasks. For details, see RUN."

    ...ich finde, dass man das durchaus beachten sollte... gerade wenn man an Backups denkt oder andere längere Jobläufe beabsichtigt. Ich vermute, Lösungen, die das nicht beachten, könnten durchaus planmäßig Schaden verursachen.

    Ein kleines via udev-Rule gestartetes Test-Script führt zu diesen Log-Einträgen. Nach 60 Sekunden gibts ne Warnung, nach weiteren 120 Sekunden wird der Job gekillt. Wenn der eigentliche Job länger dauern würde, ist das Backup definitiv unbrauchbar.

    Code
    Dez 13 22:12:00 thomaspc thlu:usbmount[5575]: Started: 1=add 2=sde1
    Dez 13 22:13:01 thomaspc systemd-udevd[878]: seq 3244 '/devices/...block/sde/sde1' is taking a long time
    Dez 13 22:15:01 thomaspc systemd-udevd[878]: seq 3244 '/devices/...block/sde/sde1' killed
    Dez 13 22:15:01 thomaspc systemd-udevd[878]: worker [5564] terminated by signal 9 (Killed)
    Dez 13 22:15:01 thomaspc systemd-udevd[878]: worker [5564] failed while handling '/devices/...block/sde/sde1'

    jm2c

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!