[erledigt] Festen Mount point für USB cardreader

[Eomer]

Leider hört es immer wieder ungefähr an der gleichen Stelle auf.

Läuf das Kopierscript durch, wenn der Mount vorher erfolgt ist und Du das Script losgelöst von der Udev-Regel manuell startest?

Jepp, läuft nach wie vor (nach 2-3 Minuten habe ich abgebrochen).

[NAB]

Teste es einfach mal.... es funktioniert tadellos.

Hab kein Systemd!
Eh, testest du auf Debian oder Raspbian? Vielleicht gibt's da Unterschiede ...

Ich denke nicht, dass es am Automount-Timeout liegt. Udev räumt immer auf. "man udev":

Starting daemons or other long-running processes is not appropriate for udev; the forked
processes, detached or not, will be unconditionally killed after the event handling has
finished.

Vielleicht guckst du noch mal in die von meinem Link vorgeschlagene UnitFile-Lösung ... scheint unter Systemd der saubere Weg zu sein.

[TomL]

Also hat das gar nix mit der Udev-Regel und myfork.sh zu tun... das Problem liegt woanders.

Um welche Art von Dateien handelt es sich...?...richtig fette im GB-Bereich...?... möglicherweise stirbt das Script gar nicht, sondern das ist einfach ein Effekt von Sync und Async.... *hmmm*... installiere doch mal htop.... du wirst später nicht mehr drauf verzichten wollen... und schau Dir während des Kopierscript-Laufes mal den Prozess "rsync" an.

Code: Alles auswählen

apt-get install htop

Dann htop starten, f4 drücken und als Filter rsync eintragen.Wenn der nämlich weiter aktiv ist, dann ist das Script gar nicht gestorben, sondern es braucht einfach seine Zeit... ist ja nur ein langsamer PI, mit langsamen USB-Device. Wenn rsync weiter aktiv ist, dann könntest Du einen Stick testen, der nur ein paar Dateien in überschaubarer Größe enthält, um zu sehen, ob das Script sauber zum Ende kommt.

Teste auch einfach mal den Inhalt des Sticks/CardReaders von Hand zu kopieren... am besten mit dem mc... dann siehst Du sofort auch die Übertragungsrate und kannst hochrechnen, wie lange das voraussichtlich dauern wird.

Code: Alles auswählen

apt-get install mc

Auch den wirst Du irgendwann nicht mehr missen wollen.

[TomL]

Eh, testest du auf Debian oder Raspbian? Vielleicht gibt's da Unterschiede ...

Ist mir bisher nie aufgefallen.... funktioniert immer beides gleichermaßen.

Starting daemons or other long-running processes is not appropriate for udev; the forked
processes, detached or not, will be unconditionally killed after the event handling has finished.

Das ist ja jetzt ein neuer Aspekt... wenn das also schon von der Intention nicht astrein ist, dann wäre auch mein Vorschlag nicht das gelbe vom Ei.

[Eomer]

Also hat das gar nix mit der Udev-Regel und myfork.sh zu tun... das Problem liegt woanders.

Um welche Art von Dateien handelt es sich...?...richtig fette im GB-Bereich...?... möglicherweise stirbt das Script gar nicht, sondern ist einfach ein Effekt von Sync und Async.... *hmmm*... installiere doch mal htop.... du wirst später nicht mehr drauf verzichten wollen... und schau Dir während des Kopierscript-Laufes mal den Prozess "rsync" an.

Code: Alles auswählen

apt-get install htop

Dann htop starten, f4 drücken und als Filter rsync eintragen.Wenn der nämlich weiter aktiv ist, dann ist das Script gar nicht gestorben, sondern es braucht einfach seine Zeit... ist ja nur ein langsamer PI, mit langsamen USB-Device. Wenn rsync weiter aktiv ist, dann könntest Du einen Stick testen, der nur ein paar Dateien in überschaubarer Größe enthält, um zu sehen, ob das Script.

Teste auch einfach mal den Inhalt des Sticks/CardReaders von Hand zu kopieren... am besten mit dem mc... dann siehst Du sofort auch die Übertragungsrate und kannst hochrechnen, wie lange das voraussichtlich dauern wird.

Code: Alles auswählen

apt-get install mc

Auch den wirst Du irgendwann nicht mehr missen wollen.

Also nein, es ist noch alles im Mbyte-Bereich (glaube 460 MB ist die größte).
Ich halte es für unwahrscheinlich, dass es am Pi liegt weil: Gerade lief er so durch, als ich ihn manuell gestartet habe. Gar keine Probleme oder Verzögerung.

Aber um sicher zu gehen, werde ich mal htop installieren und das monitoren. Arbeite nur per SSH am Pi, muss erstmal nen Bildschirm finden

[TomL]

Arbeite nur per SSH am Pi, muss erstmal nen Bildschirm finden

Brauchst keinen Bildschirm... mach einfach ne zweite SSH-Sitzung auf.

Ansonsten hat auf jeden Fall die udev-Man-Page recht... lange Jobs sind nicht empfohlen... ich empfehle Dir jetzt auch, ne andere Lösung zu suchen. Nur aus Neugier und zur Diagnose würde ich die Tests trotzdem noch durchführen.

[NAB]

TomL, ich denke, Eumer verwendet gar nicht mehr dieses Script:
viewtopic.php?f=34&t=160495#p1087641
mit rsync, sondern dieses Script:
viewtopic.php?f=34&t=160495#p1087740
mit cp.

[Eomer]

TomL, ich denke, Eumer verwendet gar nicht mehr dieses Script:
viewtopic.php?f=34&t=160495#p1087641
mit rsync, sondern dieses Script:
viewtopic.php?f=34&t=160495#p1087740
mit cp.

Nein, das war nur ein kurzer Test. Bin beim Script geblieben.

EDIT: Wie cool ist denn bitte htop?

Und ja: rsync bricht ab!

Und zu Deinem Tipp: Ja, es wäre ja schön, wenn UDEV sich raushalten würde
Einfach mounten, myfork.sh stirbt und das copyscript bleibt am leben.

Dann hat UDEV seine Ruhe....und ich auch

[TomL]

Ich glaube, systemd könnte eine Lösung sein..... also ganz einfach den Job via systemd-service-unit starten..... das ist (auf den ersten Eindruck) eine geniale Idee.... *fg*... hätte ich auch selber drauf kommen können... aber mir war diese Udev-Restriktion nicht bewusst, insofern hatte ich keinem Anlass, darüber nachzudenken.

http://unix.stackexchange.com/questions ... udev-event

[NAB]

Wie funktioniert denn dieses Automount beim Raspbian? Kann man sich da irgendwie reinhängen und von da aus ein Script starten lassen?

Sonst kann man sich einen Daemon basteln, der am dbus-monitor lauscht.

[TomL]

Oder so:
https://coreos.com/os/docs/latest/using ... rules.html

systemd ist einfach genial ....

[TomL]

Wie funktioniert denn dieses Automount beim Raspbian?

Raspian ist Debian für ARM. Das Repository ist kleiner, aber die Basics sind nach meinen Erfahrungen funktional identisch. Ich konnte bisher alles an Aufgaben und Verfahren von Debian nach Raspian portieren und umgekehrt.

[NAB]

https://coreos.com/os/docs/latest/using ... rules.html

udevadm monitor meinte ich ...

Sieht gut aus!

[Eomer]

Endlich mal gute Neuigkeiten

Ich werde leider nicht ganz schlau daraus. Ich mache den ersten Teil also einfach nach, aber an welcher Stelle kommt die Erkennung dieses bestimmten sticks?

LG

[TomL]

udevadm monitor meinte ich ...

Darauf hatte ich mich doch gar nicht bezogen... der zweite Link war stattdessen ein Nachtrag zum vorherigen Posting von mir.

Und ja, das geht alles mit den udev-Regeln.

Code: Alles auswählen

udevadm info --query=symlink --attribute-walk --name=/dev/sdb| grep ATTRS{serial} && \
udevadm info --query=symlink --attribute-walk --name=/dev/sdb| grep ATTRS{model}  && \
udevadm info --query=symlink --attribute-walk --name=/dev/sdb| grep ATTRS{vendor} && \
udevadm info --query=symlink --attribute-walk --name=/dev/sdb| grep ATTRS{product}

... wird auf dem Raspi einfandfrei beantwortet. udevadm monitor wird genau so funktionieren.

[TomL]

Ich werde leider nicht ganz schlau daraus. Ich mache den ersten Teil also einfach nach, aber an welcher Stelle kommt die Erkennung dieses bestimmten sticks?

Meiner Meinung nach gibts nun 2 Möglichkeiten.... unter der Prämisse, dass Udev NUR mountet.

Entweder startet das mountscript eine systemd-service-unit oder Du nutzt in der Udev-Regel den Eventhandler um systemd zu informieren, die entsprechende Unit anzuziehen.... könnte beides klappen.... Variante 2 sogar bestimmt, da systemd die Kontrolle über den langen Copy-Job übernimmt.

[NAB]

TomL, ich versteh das nicht ... wird dieses device-attach.service bei jedem hinzugefügten Gerät ausgeführt?

Dann könnte man es auch einfach bei meinem Symlink belassen und den Automounter sein Werk tun lassen.

Und device-attach.service startet dann ein Script, das den Symlink dereferenziert, guckt wo der Stick hingemounted ist, und dem Backupscript verrät, wo die Verzeichnisse liegen. Wär meiner Meinung nach am wenigsten Invasiv und transparenter als dein Script-Gemounte.

[Eomer]

Also ich habe folgendes probiert:

Code: Alles auswählen

ACTION=="add", KERNEL=="sd??" SUBSYSTEM=="block", ENV{ID_SERIAL_SHORT}=="000000000039", TAG+="systemd", ENV{SYSTEMD_WANTS}="device-attach.service", RUN+="/bin/bash /opt/bin/myfork.sh /dev/%k"

So habe ich es gerade probiert. Hat nicht funktioniert. Also bricht nach wie vor ab.

[TomL]

TomL, ich versteh das nicht ... wird dieses device-attach.service bei jedem hinzugefügten Gerät ausgeführt?

Nööö, schau dir die udev-regel für den systemd-call an... die wird genauso gefiltert, wie die derzeitige mount-regel... er hat dann eben 2 Regeln.

Dann könnte man es auch einfach bei meinem Symlink belassen und den Automounter sein Werk tun lassen.

Nööö, dann läuft ja wieder der lange Copy-Job nicht, weil Udev den killt.... und gemäß man-page ist das eh falsches Vorgehen.

Und device-attach.service startet dann ein Script, das den Symlink dereferenziert,

Nööö, die Unit startet einfach den Copy-Job, da ja die gegebenen Symlinks (mount-points) konstant sind und bereits leben.

Invasiv und transparenter als dein Script-Gemounte.

Noch mal nööö... das mount-script sorgt ja nur für den konstanten symlink, eben was ja genau der vorgebene mount-point ist. Und um diesen fixen mount-point kommt er nicht ohne Aufwand drum rum. Sonst müsste das Copy-Script dynamisch damit umgehen... das ist definitiv viel zu aufwendig.

Und zum gegebenen sowieso notwendigen Symlink (mount-point) einen weiteren für das Device zu genierieren, halte ich für völlig überflüssig. Es ist doch völlig egal, ob sda1 nach /media/gopro gemountet wird, oder sdb2, oder sdc5.... jeder Stick/USB-Device wird bei entgsprechender Regel auf den Symlink /media/gopro gemountet... wie das Device tatsächlich im Kernel heisst, ist hierbei unwichtig.

[TomL]

So habe ich es gerade probiert. Hat nicht funktioniert. Also bricht nach wie vor ab.

Ja, ist klar... ... da ist noch einiges nachzuarbeiten.... die systemd-unit muss erst erstellt werden und dann enabled werden. Allerdings muss das bis morgen warten... ich habe heute nen harten Rentner-Garten-Rupper-und-Malocher-Tag hinter mir... dass die Finger überhaupt noch mitspielen und nicht streiken ist eh nen Wunder...

[Eomer]

So habe ich es gerade probiert. Hat nicht funktioniert. Also bricht nach wie vor ab.

Ja, ist klar... ... da ist noch einiges nachzuarbeiten.... die systemd-unit muss erst erstellt werden und dann enabled werden. Allerdings muss das bis morgen warten... ich habe heute nen harten Rentner-Garten-Rupper-und-Malocher-Tag hinter mir... dass die Finger überhaupt noch mitspielen und nicht streiken ist eh nen Wunder...

Alles klar, da war ich zu voreilig

Vielen Dank, gute Nacht und gute Erholung. Ich bin dann auch weg für heute!

LG

[NAB]

Nööö, dann läuft ja wieder der lange Copy-Job nicht, weil Udev den killt.... und gemäß man-page ist das eh falsches Vorgehen.

Nein. Stell dir eine Udev-Regel vor, die einzig den Symlink anlegt. Kein Copy-Job.

Nöö, die Unit startet einfach den Copy-Job, da ja die gegebenen Symlinks (mount-points) konstant sind und bereits leben.

Nein. SYMLINK legt keinen Mountpoint an! (Eigentlich hat Udev generell nix mit Mounten zu tun). SYMLINK legt einen Link auf das Device an. Der Symlink zeigt also z.B. auf /dev/sda1.

Und genau die Info brächten wir ja ... dann könnten wir gucken. ob sda1 gemounted ist (macht der Automounter) und wohin.

Noch mal nööö... das mount-script sorgt ja nur für den konstanten symlink, eben was ja genau der vorgebene mount-point ist. Und um diesen fixen mount-point kommt er nicht ohne Aufwand drum rum. Sonst müsste das Copy-Script dynamisch damit umgehen... das ist definitiv viel zu aufwendig.

DEVICE=' readlink -f /dev/cfrdr1'
MOUNTPOINT='cat /proc/mounts | grep $DEVICE | cut -d" " -f2'
backupscript $MOUNTPOINT
(Eumer, so nicht nachmachen ... ungetestet und da fehlen Sicherheitsabfragen!)

[TomL]

Nein. SYMLINK legt keinen Mountpoint an! (Eigentlich hat Udev generell nix mit Mounten zu tun). SYMLINK legt einen Link auf das Device an. Der Symlink zeigt also z.B. auf /dev/sda1.

Ja, das geht wohl. Aber dann muss das Copy-Script dynamisch diesen Symlink verwenden und passend mounten bzw. einen gegebenen sich möglicherweise von Mal zu Mal verändernden Mountpoint verwenden. Ich halte das für aufwendiger. Ausserdem ist damit immer noch nicht gelöst, dass ein langläufer nicht von udev gestartet werden darf. Andererseits hat er aber jetzt schon den konstanten Mountpoint mit der vorhandenen Regel erreicht. Warum das jetzt wieder verwerfen?

Ohne Udev-Regel und das dem Zufall überlassen halte ich erstmal für keine gute Idee. Das widerspricht meiner Neigung nach Kontrolle und Begrenzung von automatischen Jobs. Aber das ist sicher auch Ansichtssache.... funktionieren wird wohl beides. Begleitend zur Udev-Regel braucht es jetzt imho nur einen simplen 2 Zeiler als einfachste Lösung, wo das von Udev übergebene Device auf den passenden Mountpoint gelegt wird.... damit existiert ein Mountpoint, mit dem das Copy-Sript sofort was anfangen kann, ohne angepasst werden zu müssen.

Danach muss nur noch das Copy-Script als eigenständiger Job gestartet werden... eigentlich wärs das dann schon.... *hmmm*...., da muss eomer sich jetzt entscheiden, was er will. Ich würde das jetzt über systemd realisieren und dann die Baustelle schließen.

[NAB]

TomL, lies dir das noch mal ausgeschlafen durch. Ich sprach eh vom Scriptstart über Systemd.

Die Alternative wäre, das Script über udevadm monitor zu starten, und das will ich euch nun wirklich nicht zumuten.

Die Udev-Regel setzt dann nur noch den Symlink und verklickert Systemd, was es tun soll ... schön übersichtlich, leicht wartbar, kein Scriptgestarte und Gemounte in Udev.

Und wenn dich der variable Mountpoint stört, dann schreib halt den Symlink in die fstab ... dafür ist sie da. Dann macht das Script "mount SYMLINK" ... fertig. Wenn der Automounter dann noch nervt, erschlag ihn.

[Eomer]

Hmm...Ihr stellt mich hier vor Entscheidungen, denen ich fachlich nicht gewachsen bin.

NABs Ansatz klingt erstmal einfacher...daher würde es vielleicht Sinn machen es vorher zu probieren, bevor Aufwand für Tom entsteht?
Oh man, weiß gar nicht was ich sagen soll...bin einfach froh, dass Ihr helft