[gelöst] findmnt, mount finden udev -mounts nicht mehr?

[detix]

Ein Backup das über eine udev Regel beim Anschließen einer externen USB-Platte angestoßen wird, soll mir auch ein Icon auf dem Desktop erstellen (kde, stretch).

Das Backup selbst funktioniert einwandfrei, nur kann ich per mount|findmnt (gestartet durch inotifywait) nicht mehr festellen ob das Device gerade gemountet ist, was natürlich hilfreich wäre um das Icon zu erstellen aber die Ausgaben der Befehle verschweigen dies.

Probiert mit mount und findmnt, als device wird leider nur root (hier: /dev/sda6) angezeigt.
udev Regel:

Code: Alles auswählen

KERNEL=="sd[g-i]1", SUBSYSTEM=="block", ENV{ID_FS_LABEL}=="backup_usb_hd", ACTION=="add", RUN+="/bin/su -c '/usr/local/bin/pn_backup_usb_hd %k %E{ID_FS_LABEL}' detix"

in /usr/local/bin/pn_backup_usb_hd (Ausschnitt):

Code: Alles auswählen

UsbDevice="/dev/$1"
UsbLabel="$2"
pmount $UsbDevice $UsbLabel

inotifywait Skript, ruft sich nach Beenden immer wieder selbst auf:

Code: Alles auswählen

inotifywait -q -q -e open /bin/*mount /usr/bin/*mount /usr/bin/sshfs
if findmnt ...

Es funktioniert wenn ich Laufwerke von Hand oder per Skript mounte:

Code: Alles auswählen

mount: /dev/sdi1 on /media/backup_usb_hd type ext4...
findmnt: /media/backup_usb_hd /dev/sdi1 ext4...

nicht aber wenn über udev gestartet, da ist dann keine vergleichbare Ausgabe!
Wo ist mein Denkfehler?

[TomL]

Ein Backup das über eine udev Regel beim Anschließen einer externen USB-Platte angestoßen wird, soll mir auch ein Icon auf dem Desktop erstellen (kde, stretch).
::::
Wo ist mein Denkfehler?

Möglicherweise an der Stelle, dass das Vorhaben vielleicht konzeptionell grundsätzlich falsch ist.... was ich an der Stelle allerdings erst Mal nur vermuten kann.
Der Grund für meine Vermutung ist der Gedanke, dass ein Backup möglicherweise nicht in 2, 3 oder 5 oder 20 Sekunden abgehandelt ist, sondern mehr Zeit benötigt. Und falls das so ist, dass es also wirklich länger dauert, ist diese Lösung hinsichtlich der Integrität des Backups ein reines Glückspiel. Gemäß den UDEV-Beschränkungen dürfen im Run-Statement nur "very short-running foreground tasks" gestartet werden. Ich schließe nicht aus, dass systemd den Prozess vielleicht auch kurzerhand killt, wenn es der Meinung ist, das dauert zu lange.

Wenn Du nicht absolut sicher bist und gewährleisten kannst, dass der Job regelmäßig wirklich in kürzester Zeit durch ist, würde ich hier die Fehlersuche beenden und den Start über systemctl und eine Service-Unit einrichten. Aber auch dabei MUSS der aufgerufene Prozess schnell durch sein, sondern wertet systemd den Job als failed und kill ihn wieder. Die Lösung ist dabei relativ einfach: eine Service-Unit startet das Parent-Script, welches sich dann als Child forked, wartet dann auf eine "Fork'd-Child-Erfolgreich"-Meldung, was man über ein PID-File bewerkstelligen könnte und kehrt sofort mit exit 0 zurück. Im Hintergrund könnte der Fork dann seinen Backup-Job erledigen, und natürlich auch sowas wie ein Desktop-Icon anlegen. Ist alles durch, beendet er sich einfach. Im Vordergrund kriegt man davon soweit nix mit.

BTW: Die Bedeutung bzw. den Zweck von Inotifywait verstehe ich aufgrund der wenigen Infos leider nicht. Und ich verstehe die Variablenzuweisung und den pmount am Ende der udev-Regel irgendwie auch nicht, bzw. was das in einer udev-Regel machen soll.

[detix]

BTW: Die Bedeutung bzw. den Zweck von Inotifywait verstehe ich aufgrund der wenigen Infos leider nicht. Und ich verstehe die Variablenzuweisung und den pmount am Ende der udev-Regel irgendwie auch nicht, bzw. was das in einer udev-Regel machen soll.

Habs oben korrigiert!

Danke für die Antwort Thomas, ich fang mal unten an:
inotifywait soll den Zugriff auf irgendeinen mount -Befehl überwachen, wird also einer davon aufgerufen
soll eine Aktion ausgeführt werden, in meinem Fall das Erstellen eines Desktop-Icons.
inotifywait wird per Skript einmalig gestartet, danach nur noch sein Inhalt ausgeführt,
sieht im Skript dann so aus:

Code: Alles auswählen

# der Erststart erfolgt zum Aufräumen, also ohne Befehlszeilen Parameter
if [ -n "$1" ]; then
  inotifywait -q -q -e open /bin/*mount /usr/bin/*mount /usr/bin/sshfs
fi
#...erstellen des icons...und...und...und...
# Selbstaufruf mit Befehlszeilen Parameter und exit am Ende:
$0 blabla &
exit 0

Das läuft auch, wenn ich mount|pmount... von Hand oder per Skript ausführe,
das Icon wird erstellt und ich kann, wenns um ein längeres Backup geht,
zwischendurch mount|findmnt aufrufen und damit sehen das mein Backup-Laufwerk auch tatsächlich gemountet ist,
nur halt dann nicht wenns über udev gestartet wird.
Da erzeugen die mount -Befehle eben keine Ausgabe bzgl dieses Laufwerks.
Dieses 'Run-Statement nur "very short-running foreground tasks"' trifft hier mMn nicht zu,
da die Augabe sofort und ohne weitere Rückfragen direkt ans Backup-Skript abgetreten werden.
ps: ich bin mir sicher, das dass seit Jahren so funktioniert hat, irgendwas muss sich vor Kurzem geändert haben...

[TomL]

Das Konzept ist sehr schwer zu verstehen.... ich bin noch ziemlich weit weg von "Zusammenhang und Ablauf verstehen"...

Dieses 'Run-Statement nur "very short-running foreground tasks"' trifft hier mMn nicht zu, da die Augabe sofort und ohne weitere Rückfragen direkt ans Backup-Skript abgetreten werden. ps: ich bin mir sicher, das dass seit Jahren so funktioniert hat, irgendwas muss sich vor Kurzem geändert haben...

Ich bezog mich auf dieses Statement in der udev-Rule:

Code: Alles auswählen

RUN+="/bin/su -c '/usr/local/bin/pn_backup_usb_hd ...."

Ist dieses Script nicht dasjenige, welches das Backup durchführt und spielt neben diesem Script und inotifywait noch ein dritter Kandidat für ein Backup im Hintergrund mit? Dieses Script /usr/local/bin/pn_backup_usb_hd ist mit dem "very-short" gemeint. Das muss binnen kurzer Zeit zurückkehren. Fork'ed sich dieses Script selber auch in den Background oder startet es einen weiteren Job? Denn, falls es nicht forked, sondern selber direkt das Backup macht, kanns halt sein, dass systemd den Job killt. Wie da der Ablauf ist, geht aus Deinem Text soweit nicht hervor.

Und der Zusammenhang mit inotifywait ist mir völlig unklar. Wenn ich das richtig verstehe, hat dieser Prozess erst mal nix mit dem Backup zu tun... das ist anscheinend ein zweiter Job, der immer durchläuft? Ich verstehe auch noch nicht nicht, welcher der beiden Jobs wie auf den anderen reagieren soll. Soll inotifywait "anzeigen", dass der Backup angelaufen ist, oder soll der Backup nur dann anlaufen, wenns dieses Desktop-Icon nicht gibt, weil dann der Mount noch nicht durchgeführt wurde? Was macht inotifywait, wenn der Backup-Job gar nicht selber mounten muss, weil der Mount schon früher von anderer Stelle durchgeführt wurde? Soll Inotifywait auch anzeigen, wenn von anderer Stelle beliebige Mounts angestoßen werden? Wofür braucht man inotifywait überhaupt? Das Backupscript kann doch prüfen, ob der Mount besteht und dann selber das Icon anlegen, wenn er den geöffnet hat? Dient inotifywait zur allgemeinen Überwachung vom beliebige Mountpoints oder speziell nur für das Backupscript?

Solange ich weder das Problem noch den Lösungsansatz verstanden habe, habe ich echt keine Ahnung, wo da der Denkfehler ist und ob überhaupt...

[detix]

Ja, es sind zwei völlig unabhängig voneinander laufende Prozesse.
Wenn die USB-Platte Strom bekommt greift die udev-Regel und das Backup wird auf Nachfrage ausgeführt.
Dazu muss die Platte natürlich gemountet sein was im pn_backup_usb_hd -Skript sichergestellt ist.
Dieser Teil funktioniert ja auch noch, das Backup wird problemlos erstellt.

Zeitgleich läuft eben noch das inotifywait -Skript was Zugriffe auf die diversen mount -Befehle überwacht
und falls einer davon aufgerufen wurde dann die entsprechende Aktion ausführt, hier halt das Erstellen eines Desktopicons für gemountete Laufwerke.

Ich kann pn_backup_usb_hd als user detix aus einer Konsole heraus aufrufen und das Icon wird automatisch erstellt,
wenn das Backup länger dauert kann ich wie og aus einer anderen Konsole mount|findmnt aufrufen und sehe das die usb-Platte wirklich gemountet ist.

Aber genau letzteres funktioniert nicht mehr, wenn pn_backup_usb_hd über udev gestartet wird,
dann ergibt mount|findmnt eben absolut keine Ausgabe über den aktuellen mount -Zustand dieser USB-Platte,
und daran scheitert offensichtlich das inotifywait -Skript, das dieses Skript aufgerufen wurde ist an seiner neuen PID leicht erkennbar.
Es ist nur dafür da das Icon zu erstellen.

[TomL]

Wann, wie und von wem wird das inotify-Script gestartet... wer ist Prozess-Owner?

Nachtrag:
Ich glaube, dass funktioniert deshalb nicht, weil systemd nicht den klassischen /bin/mount verwendet, sondern sein eigenes Werkzeug systemd.mount. Ein wesentlicher Unterschied ist, dass die Systemd-Mounts nicht direkt ausgeführt werden, sondern in die Dienste-Schleife 'enqueued' werden.

[detix]

Ich glaub das war mal wieder ein Volltreffer!
Nach ein wenig Suchen findet sich dann das:
https://wiki.archlinux.org/index.php/ud ... udev_rules
Im roten Kasten (für debian angepasst):
"copy /lib/systemd/system/systemd-udevd.service to /etc/systemd/system/systemd-udevd.service
and replace MountFlags=slave to MountFlags=shared"

Das wars schon (MountFlags=shared), zur Sicherheit noch einen Neustart gemacht ‒ perfekt!
mount, findmnt funktionieren so wieder und inotifywait erstellt ganz brav die Icons, während des Backups auch nochmal die beiden entscheidenden Befehle aufgerufen:

Code: Alles auswählen

mount
/dev/sdh1 on /media/backup_usb_hd type ext4 (rw,nosuid,nodev,noexec,relatime,errors=remount-ro,data=ordered,user)
findmnt
/media/backup_usb_hd /dev/sdh1 ext4 rw,nosuid,nodev,noexec,relatime,errors=remount-ro,data=ordered

So muss das sein!
Der Prozess-Owner des inotify-Scripts bin natürlich ich als user
Vielen Dank Thomas

[TomL]

Der Prozess-Owner des inotify-Scripts bin natürlich ich als user

Ich hatte mir das gedacht und dabei die Idee, dass es vielleicht damit zusammenhängen könnte, dass udev die Jobs als "root" ausführt und vielleicht die Berechtigungsprüfung dazwischenfunkt. Aber das wars ja dann wohl doch nicht.

Vielen Dank Thomas

Wofür? *fg* Ich habe ja gar nicht helfen können... und wenn ich ehrlich bin, habe ich den gesamten Workflow immer noch nicht begriffen und verstehe auch nicht, wie diese Lösung dabei geholfen hat. Ich selber habe auch mehrere kleine mobile USB-Platten, die ich beim durch udev erkannten Plugin zuerst mit cryptsetup entschlüssel und dann sofort mounte. Warum ich diesen Parameter jetzt nicht brauche und warum das bei Dir nur mit diesem Parameter funktioniert, und ob es keinen anderen Weg für einen Eventhandler gibt, außer den Zugriff auf /bin/mount zu überwachen, ist mir ein totales Rätsel.

Aber ist wohl nicht so wichtig... hauptsache es läuft......

[detix]

Wofür? *fg* Ich habe ja gar nicht helfen können...

Doch doch mein Lieber, das hast du und zwar ganz entscheidend!
>>>dass die Systemd-Mounts nicht direkt ausgeführt werden, sondern in die Dienste-Schleife 'enqueued' werden
Mit heutigen weiteren Versuchen, sah ich dass das Laufwerk garnicht so „richtig” gemountet wurde, damit meine ich das /media/backup_usb_hd leer blieb!
Irgendwie sollte doch dort nachgeschaut werden um feststellen zu können ob das Backup aktuell ist oder es etwas zu übertragen gibt,...und es dafür gemountet sein.
Leider Fehlanzeige, diese systemd-udev (per Skript gestarteten) mounts scheinen auch an /media vorbeizugehen...
Jetzt allerdings nicht mehr, war vielleicht auch einer der Gründe warum die *mount Befehle diesbzgl. keine Ausgabe hatten!
So richtig erklären kann ichs nur leider nicht und haks mal unter geheimnisvolles systemd ab...