[erledigt] Festen Mount point für USB cardreader

[TomL]

Wir wollen es mit sda1 aufrufen, nicht mit sda.

das liegt daran, dass er nicht tut, was ich gesagt habe ....ich habe in der Regel "sd??" vorgegeben, er hat "sd*" daraus gemacht. Ist doch logisch, dass auch auf nur "sda" reagiert wird.

[Eomer]

Sorry Tom,
ich habe die Regel von NAB übernommen, die er zuletzt gepostet hat.
Ich weiß nicht auf wen ich von euch beiden hören soll. Ich will niemanden vor den Kopf stoßen

Ich baue mal den Punkt mit "sd??" ein, der ist ja in der aktullen Regel überhaupt nicht vorgesehen.


EDIT: So sieht es jetzt aus:

Code: Alles auswählen

KERNEL=="sd??", ACTION=="add",  SUBSYSTEM=="block", ENV{DEVTYPE}=="partition",  ENV{ID_SERIAL_SHORT}=="000000000039",  ENV{ID_DRIVE_FLASH_CF}=="1",  SYMLINK+="cfrdr%n",  RUN+="/bin/bash /opt/bin/myfork.sh /dev/%k"

Code: Alles auswählen

Tue Apr 19 16:57:17 CEST 2016
Versuche: /bin/mount /dev/sda1 /media/cardreader -o rw

Das ist die myfork.log, also alles andere war alt. er mountet wirklich nur noch was er soll, was schonmal prima ist!

Syslog sagt aber nach wie vor:

Code: Alles auswählen

Apr 19 16:57:17 raspberrypi org.gtk.Private.UDisks2VolumeMonitor[801]: index_parse.c:191: indx_parse(): error opening /media/cardreader/BDMV/index.bdmv
Apr 19 16:57:17 raspberrypi org.gtk.Private.UDisks2VolumeMonitor[801]: index_parse.c:191: indx_parse(): error opening /media/cardreader/BDMV/BACKUP/index.bdmv
Apr 19 16:57:48 raspberrypi systemd-udevd[2710]: timeout '/bin/bash /opt/bin/myfork.sh /dev/sda1'
Apr 19 16:57:48 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Tue Apr 19 16:58:48 2016 [try http://www.rsyslog.com/e/2007 ]
Apr 19 16:57:49 raspberrypi systemd-udevd[2710]: timeout: killing '/bin/bash /opt/bin/myfork.sh /dev/sda1' [2735]
Apr 19 16:57:49 raspberrypi systemd-udevd[2710]: '/bin/bash /opt/bin/myfork.sh /dev/sda1' [2735] terminated by signal 9 (Killed)

[TomL]

Wenn du den symlink nicht verwendest, würde ich den wieder entfernen, denn die Definition ist sinnlos, wenn du sie nicht explizit verwendest und führt später zu Verwirrung, weil ein Device nicht so heisst, wie man es eigentlich erwartet.

Und den Sinn von ID_DRIVE_Flash kann ich auch nicht nachvollziehen. Was passiert, wenn die beiden nicht mehr enthalten sind? Funktioniert es dann nicht mehr?

[NAB]

das liegt daran, dass er nicht tut, was ich gesagt habe ...

Nein, daran bin ich schuld, weil ich ihm das mit dem sd.. wieder ausgeredet habe

Aber hast recht, ein
KERNEL=="sd??"
könnte inzwischen auch auch wieder rein, statt dem
ENV{DEVTYPE}=="partition"
sollte auf's gleiche hinauskommen.

Ich wollt erst mal ne Regel haben, die überhaupt greift.

Und der Symlink kann auch raus, der war als Ersatz gedacht, falls das Script gar nicht anspringt.

[Eomer]

Okay, ich habe die Regel mal weiter gekürzt.

Wir sind jetzt bei:

KERNEL=="sd??", ACTION=="add", SUBSYSTEM=="block", ENV{ID_SERIAL_SHORT}=="000000000039", RUN+="/bin/bash /opt/bin/myfork.sh /dev/%k"

Ich denke ein Stick mit der gleichen Serial ist ja eher unwahrscheinlich, oder?

Soweit läuft alles korrekt, bis auf den Prozess der zwangsbeendet wird:

Code: Alles auswählen

Apr 19 17:08:26 raspberrypi kernel: [ 3460.573204] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Apr 19 17:08:26 raspberrypi org.gtk.Private.UDisks2VolumeMonitor[801]: index_parse.c:191: indx_parse(): error opening /media/cardreader/BDMV/index.bdmv
Apr 19 17:08:26 raspberrypi org.gtk.Private.UDisks2VolumeMonitor[801]: index_parse.c:191: indx_parse(): error opening /media/cardreader/BDMV/BACKUP/index.bdmv
Apr 19 17:08:57 raspberrypi systemd-udevd[3069]: timeout '/bin/bash /opt/bin/myfork.sh /dev/sda1'
Apr 19 17:08:58 raspberrypi systemd-udevd[3069]: timeout: killing '/bin/bash /opt/bin/myfork.sh /dev/sda1' [3098]
Apr 19 17:08:58 raspberrypi systemd-udevd[3069]: '/bin/bash /opt/bin/myfork.sh /dev/sda1' [3098] terminated by signal 9 (Killed)

[TomL]

Ich wollt erst mal ne Regel haben, die überhaupt greift.

Deswegen ist m.E. der richtige Weg erstmal ohne Regel anfangen, dass es grundsätzlich funktioniert, und dann versuchen, mit Filtern explizit das Gerät zu identifizieren und die Regel auf dieses Gerät zu beschränken.

Das gelingt eigentlich immer. Ich finds halt unergiebig alles mögliche an Parametern auszuprobieren und auf nen Zufallstreffer zu hoffen. Und wenn es sich um ein "sd??"-Device handelt, würde ich keinesfalls darauf in der Regel verzichten, weil Udev-Regeln für alles mögliche abgearbeitet werden. Nicht dass nen falsche Regel auch ein unpassendes Device betrifft und irgendwas lahm legt und wo man nicht den Zusammenhang offensichtlich erkennt.

Jm2c

[TomL]

Was heisst zwangsbeendet? Wer wird zwangsbeendet?

[NAB]

TomL, lies dir den Thread durch ... der zentrale Fehler war, dass das Script auf 50 falsch platziert war. Wir brauchen ENV, um den Cardreader einwandfrei zu identifizieren, und das gab's auf 50 noch nicht. Drum hab ich erst mal auf ENV getestet, bis das lief.

Und mit ENV{ID_DRIVE_FLASH_CF} erkennt man zuverlässig einen CF-Reader ... was weiß ich, wieviele davon Eomer zuhause rumliegen hat, gestern war er mit einem zweiten zugange. Drum wollt ich danach erst mal wissen, was er überhaupt will. Optimieren kann man später.

Nebenbei hab ich weder von Cardreadern noch vom Pi Ahnung und weiß nicht, ob die grundsätzlich immer als sdX erkannt werden.

zwangsbeendet = kill -9

[NAB]

Eomer, wie schaut's denn nun aus? Hab ich das richtig verstanden, dass nicht nur myfork.sh abgeschossen wird, sondern auch das Backupscript?

Dann gibt's vielleicht auch noch ein systemd-Problem:
http://unix.stackexchange.com/questions ... udev-event

[Eomer]

Also erstmal: Ich find's super, dass Ihr beide beteiligt wart. Nur durch unterschiedliche Ideen und Meinungen kommt eine wirklich gute Lösung zustande!


quote="NAB"]Eomer, wie schaut's denn nun aus? Hab ich das richtig verstanden, dass nicht nur myfork.sh abgeschossen wird, sondern auch das Backupscript?

Dann gibt's vielleicht auch noch ein systemd-Problem:
http://unix.stackexchange.com/questions ... udev-event[/quote]

Also das Backup-Script wird nicht wirklich abeschossen, sondern es hört einfach auf weiterzukopieren. Es hängt sich also eher auf. Die letzte Meldung im Syslog ist die, die ich auch im letzten Log gepostet habe.
Das UDEV keine langen Porzesse mag ist ja bekannt, daher auch myfork.sh, was wiederum das Copyscript startet.

Die Lösung scheint ja ein

Code: Alles auswählen

 | at now

zu sein. Macht man also:

Code: Alles auswählen

#!/bin/bash
date >> /opt/bin/myfork.log
echo "Versuche: /bin/mount $1 /media/cardreader -o rw" >> /opt/bin/myfork.log

[[ ! -z $(grep $1 /proc/mounts) ]] && exit 1
[ -d /media/cardreader ] || /bin/mkdir -p /media/cardreader
/bin/mount $1 /media/cardreader -o rw
/bin/chmod 777 /media/cardreader

setsid /opt/bin/copyscript.sh | at now > /setsid.log

Oder wie soll ich mir das vorstellen?



So sieht die ganze Geschichte aus:

Code: Alles auswählen

pi@raspberrypi:/media/backup $ cat /opt/bin/copyscript.log
To: user1@raspberrypi.local
From: goprosync@raspberrypi.local
Subject: GoProSync_Result
==============
Script Started
Tue Apr 19 19:05:02 CEST 2016
20
== Source Disk Found - Look for the Destination Disk ==
Tue Apr 19 19:05:02 CEST 2016
20
== Destination Disk Found - Sync Started ==
sending incremental file list
cardreader/
cardreader/DSC00015.JPG
cardreader/DSC00016.ARW
cardreader/DSC00016.JPG
cardreader/DSC00017.ARW
cardreader/MAH00191.MP4

Und so bleibt es letztlich auch. Ich bin dann mal in /media/backup rein (das Zielverzeichnis) und dort bewegt sich auch nichts, also die Größe der Datei verändert sich nicht mehr.
Ich kann den Stick dann ganz normal auswerfen, keine Meldung das er Busy ist etc.

VG
Eomer

[TomL]

Und mit ENV{ID_DRIVE_FLASH_CF} erkennt man zuverlässig einen CF-Reader ...

Nein, erkennt man nicht. Das ist NUR ein Flag, dass Kompatibilität mit "Compact Flash" anzeigt. Und es wird auch nur gesetzt, wenn das Gerät genau das erfüllt. Kein einziger meiner Standard-Card-Reader hat dieses Flag gesetzt.

Du musst konkret jeden verwendeten Parameter resp. Attribut für jedes Gerät explizit auf "vorhanden und gesetzt" prüfen, und natürlich dabei auf Konflikte mit ähnlichen Geräten achten. Und du kannst auch nur die Attribute verwenden, die explizit erkannt werden. Das kann von Gerät zu Gerät unterschiedlich sein.

Sorry ...kann noch nicht alles lesen. Immer nur in den pausen am handy

[Eomer]

Also ich habe gerade noch ein wenig rumprobiert, aber immer das gleiche.

Hab mal etwas anderes probiert um zu shen in welchem zeitlichen abstand das passiert:

Code: Alles auswählen

Apr 19 19:45:22 raspberrypi sd-autocopy: Karte akzeptiert. Starte Kopiervorgang...
Apr 19 19:45:22 raspberrypi kernel: [ 1216.672516] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Apr 19 19:45:22 raspberrypi org.gtk.Private.UDisks2VolumeMonitor[791]: index_parse.c:191: indx_parse(): error opening /media/cardreader/BDMV/index.bdmv
Apr 19 19:45:22 raspberrypi org.gtk.Private.UDisks2VolumeMonitor[791]: index_parse.c:191: indx_parse(): error opening /media/cardreader/BDMV/BACKUP/index.bdmv
Apr 19 19:45:53 raspberrypi systemd-udevd[3297]: timeout '/bin/bash /opt/bin/myfork.sh /dev/sda1'
Apr 19 19:45:53 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Tue Apr 19 19:46:23 2016 [try http://www.rsyslog.com/e/2007 ]
Apr 19 19:45:54 raspberrypi systemd-udevd[3297]: timeout: killing '/bin/bash /opt/bin/myfork.sh /dev/sda1' [3325]
Apr 19 19:45:54 raspberrypi systemd-udevd[3297]: '/bin/bash /opt/bin/myfork.sh /dev/sda1' [3325] terminated by signal 9 (Killed)

Das killen von myfork hängt anscheinend mit dem Kopiervorgang zusammen. Wie auch immer.

[NAB]

Das ist NUR ein Flag, dass Kompatibilität mit "Compact Flash" anzeigt.

Ah ... muss also gar nicht bedeuten, dass gerade eine CF-Karte drin steckt? Das würde erklären, warum ID_DRIVE_FLASH_CF angezeigt wurde, ID_DRIVE_MEDIA_FLASH_CF aber nicht. Is aber nu auch egal, wirf lieber einen Blick auf die Sache mit Eomers stoppendem Script

Eomer, erst mal würd mich interessieren, was da eigentlich passiert. Kannst du mal diese mittlere Zeile in dein Backup-Script aufnehmen:

Code: Alles auswählen

echo "==============" >> $logfile
echo "My PID: "$$ >> $logfile
echo "Script Started" >> $logfile

Und wenn das Backup-Script wieder hängt, dann schaust du mal ins Log. Hinter PID: siehst du eine ZAHL.

Und dann schaust du mit

Code: Alles auswählen

ps -e | grep ZAHL

mal nach, ob der Prozess überhaupt noch läuft.

Wenn du auf den Befehl keine Antwort bekommst, dann ist der Prozess wirklich "weg", also höchstwahrscheinlich abgeschossen worden (darüber sollte systemd eigentlich im Log berichten, aber naja ...)

Ansonsten hab ich jetzt neben dem Problem, dass ich weder einen Pi noch einen Cardreader habe, auch noch das Problem, dass ich Systemd nicht verwende. Ich kann inzwischen also gar nicht mehr nachstellen, was da bei dir los ist. Meine Lösung bestände darin, Systemd zu deinstallieren, aber ich bin mir sicher, TomL hätte eine viel bessere Lösung, also warte mal ab, ob der sich noch meldet.

Andernfalls wär die Frage glatt einen neuen Thread wert ... "Wie starte ich von Udev aus einen lang laufenden Prozess?".

Edit: Ach, und, die /media/cardreader/BDMV/index.bdmv-Fehler sind nebensächlich. Da scheitert die Auto-Erkennung von Blu-Rays ... vermutlich, weil es keine Blu Ray ist. Der Fehler ist schon älter, aber harmlos.

[TomL]

Wir sind jetzt bei:

Code: Alles auswählen

KERNEL=="sd??", ACTION=="add",  SUBSYSTEM=="block", ENV{ID_SERIAL_SHORT}=="000000000039", RUN+="/bin/bash /opt/bin/myfork.sh /dev/%k"

Ist das oben jetzt die aktuelle Regel? Und die läuft? Prima! Füge bitte einfach mal diese folgende Regel zusätzlich vor Deiner Regel ein, so das beide Regeln wirksam sind.

Code: Alles auswählen

ACTION=="add", KERNEL=="sd??", RUN+="/bin/bash /opt/bin/usbtrace add /dev/%k %p %b $name %E{SUBSYSTEM} $driver %E{ID_SERIAL_SHORT} %E{ID_DRIVE_FLASH_CF}"

Und dann erstelle dieses kleine folgende Script für ein Pseudo-Trace mit:

Code: Alles auswählen

nano /opt/bin/usbtrace

mit folgendem Inhalt:

Code: Alles auswählen

#!/bin/bash

d=`date +%d-%m-%Y-%H-%M-%S`
log=/tmp/debtrace.log

m=$(udevadm info --query=symlink --attribute-walk --name=$2 | grep model -i)
m="${m#"${m%%[![:space:]]*}"}"
m=$(echo $m|tr -d '\n')

p=$(udevadm info --query=symlink --attribute-walk --name=$2| grep ATTRS{product} -i)
p="${p#"${p%%[![:space:]]*}"}"
p=$(echo $p|tr -d '\n')

v=$(udevadm info --query=symlink --attribute-walk --name=$2| grep ATTRS{vendor} -i)
v="${v#"${v%%[![:space:]]*}"}"
v=$(echo $v|tr -d '\n')

s=$(udevadm info --query=symlink --attribute-walk --name=$2 | grep serial -i)
s="${s#"${s%%[![:space:]]*}"}"
s=$(echo $s|tr -d '\n')

echo $d `basename $0`" - Action            : $1" >>/$log
echo $d `basename $0`" - Device            : $2" >>/$log
echo $d `basename $0`" - Device-Path       : $3" >>/$log
echo $d `basename $0`" - ID/Name           : $4" >>/$log
echo $d `basename $0`" - Kernel            : $5" >>/$log
echo $d `basename $0`" - Subsystem         : $6" >>/$log
echo $d `basename $0`" - Driver            : $7" >>/$log
echo $d `basename $0`" - ID_SERIAL_SHORT   : $8" >>/$log
echo $d `basename $0`" - DEVNAME           : $9" >>/$log
echo $d `basename $0`" - ID_DRIVE_FLASH_CF : $10" >>/$log
echo $d `basename $0`" - Vendor    (Query) : $v" >>/$log
echo $d `basename $0`" - Model     (Query) : $m" >>/$log
echo $d `basename $0`" - Product   (Query) : $p" >>/$log
echo $d `basename $0`" - SerialID  (Query) : $s" >>/$log

echo $d `basename $0`" - Start sleep" >>/$log
/usr/bin/setsid /bin/bash -c "/bin/sleep 120 &"
echo $d `basename $0`" - exit 0" >>/$log

exit 0

Dann die zwei Befehle

Code: Alles auswählen

chmod 755 /opt/bin/usbtrace
udevadm control --reload-rules

und danach den CardReader einmal einstecken. Poste anschließend mal den Inhalt des Logs, ansehen mit

Code: Alles auswählen

cat /tmp/debtrace.log

Und ganz zum Schluß diese Trace-Regel mit einem Comment-Tag # wieder deaktivieren.... nicht vergessen! Diese Udev-Regel und das Script kannst Du bei Bedarf erneut aktivieren, wenn Du einen anderes /dev/sd??-Device mit Udev "lenken" möchstest. Und es eignet sich ein bisschen, um mal eben andere Devices auf Konflikte z.B. beim Udev-Filter zu prüfen.

[TomL]

Also das Backup-Script wird nicht wirklich abeschossen, sondern es hört einfach auf weiterzukopieren. Es hängt sich also eher auf. Die letzte Meldung im Syslog ist die, die ich auch im letzten Log gepostet habe.

Nein, es hängt sich nicht auf. Es ist einfach ein Child-Prozess, der ebenfalls geschlossen wird, wenn der Eltern-Prozess beendet wird.

Die Lösung scheint ja ein

Code: Alles auswählen

 | at now

Das ist nur die drittbeste Lösung, die ich gar nicht erst versuchen würde. Besser wäre es, den Childprozess unabhängig vom Eltern-Prozess zu starten.

Ändere das Script in der letzten Zeile mal wie folgt ab

Code: Alles auswählen

#!/bin/bash
date >> /opt/bin/myfork.log
echo "Versuche: /bin/mount $1 /media/cardreader -o rw" >> /opt/bin/myfork.log

[[ ! -z $(grep $1 /proc/mounts) ]] && exit 1
[ -d /media/cardreader ] || /bin/mkdir -p /media/cardreader
/bin/mount $1 /media/cardreader -o rw
/bin/chmod 777 /media/cardreader

/usr/bin/setsid /usr/bin/lxterminal -e /opt/bin/copyscript.sh

Wobei, wenn ich ehrlich bin, würde mir ein Script, was ausserhalb meiner Wahrnehmung irgendwas im Geheimen irgendwohin kopiert, einigermaßen Bauchschmerzen bereiten... aber wenns trotzdem sein soll......

[Eomer]

Ui, eins nach dem anderen

Code: Alles auswählen

pi@raspberrypi:/opt/bin $ cat /tmp/debtrace.log
19-04-2016-21-11-37 usbtrace - Action            : add
19-04-2016-21-11-37 usbtrace - Device            : /dev/sda1
19-04-2016-21-11-37 usbtrace - Device-Path       : /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1
19-04-2016-21-11-37 usbtrace - ID/Name           : sda1
19-04-2016-21-11-37 usbtrace - Kernel            : block
19-04-2016-21-11-37 usbtrace - Subsystem         : 000000000039
19-04-2016-21-11-37 usbtrace - Driver            : 1
19-04-2016-21-11-37 usbtrace - ID_SERIAL_SHORT   :
19-04-2016-21-11-37 usbtrace - ID_DRIVE_FLASH_CF :
19-04-2016-21-11-37 usbtrace - Vendor    (Query) :
19-04-2016-21-11-37 usbtrace - Model     (Query) : ATTRS{model}=="SD Transcend "
19-04-2016-21-11-37 usbtrace - Product   (Query) :

Ich editiere gleich nochmal.

[TomL]

Yep, in dem Log siehst Du die Filter, die Du verwenden kannst... z.B. auch den Begriff "Transcend". Aber irgendwas ist da noch durcheinandergeraten.... die serialid steht bei Dir falsch *hmmm*

Und das nächste Problem.... boar, ist das ein Scheiss....

Ich habe jetzt in meinem Trace-Script zum 20 Mal noch mal geändert und getestet. Und siehe da, der Child-Job "Sleep 120" wird jetzt beim Einstecken eines USB-Sticks komplett durchgeführt, obwohl der Parent-Prozess beendet wurde. Das ist also die Lösung.

Code: Alles auswählen

#!/bin/bash

d=`date +%d-%m-%Y-%H-%M-%S`
log=/tmp/debtrace.log

m=$(udevadm info --query=symlink --attribute-walk --name=$2 | grep model -i)
m="${m#"${m%%[![:space:]]*}"}"
m=$(echo $m|tr -d '\n')

p=$(udevadm info --query=symlink --attribute-walk --name=/dev/sdb| grep ATTRS{product} -i)
p="${p#"${p%%[![:space:]]*}"}"
p=$(echo $p|tr -d '\n')

v=$(udevadm info --query=symlink --attribute-walk --name=/dev/sdb| grep ATTRS{vendor} -i)
v="${v#"${v%%[![:space:]]*}"}"
v=$(echo $v|tr -d '\n')

echo $d `basename $0`" - Action            : $1" >>/$log
echo $d `basename $0`" - Device            : $2" >>/$log
echo $d `basename $0`" - Device-Path       : $3" >>/$log
echo $d `basename $0`" - ID/Name           : $4" >>/$log
echo $d `basename $0`" - Kernel            : $5" >>/$log
echo $d `basename $0`" - Subsystem         : $6" >>/$log
echo $d `basename $0`" - Driver            : $7" >>/$log
echo $d `basename $0`" - ID_SERIAL_SHORT   : $8" >>/$log
echo $d `basename $0`" - ID_DRIVE_FLASH_CF : $9" >>/$log
echo $d `basename $0`" - Vendor    (Query) : $v" >>/$log
echo $d `basename $0`" - Model     (Query) : $m" >>/$log
echo $d `basename $0`" - Product   (Query) : $p" >>/$log

echo $d `basename $0`" - Start sleep" >>/$log
/usr/bin/setsid /bin/bash -c "/bin/sleep 120 &"
echo $d `basename $0`" - exit 0" >>/$log

exit 0

Jetzt gibts zwei Möglichkeiten.... entweder 2 Regeln mit den gleichen Filtern, die zweite mit dem Kopierscript NACH der Mountregel. Oder eben versuchen, ob der Sleep-Beispielaufruf in meinem Trace-Log angepasst auch direkt in Dein mount-Script am Ende angefügt werden kann.

Du kannst das testen, in dem Du einfach ein zweites Terminal startest, mit htop und dem Filter (F4) "sleep" öffnest , dann siehst Du, dass das passt.

Mein Ergebnis sieht bei 2 verschiedenen Sticks so aus... einer der Sticks enthält 2 Partitionen:

Code: Alles auswählen

19-04-2016-21-33-59 usbtrace - Action            : add
19-04-2016-21-33-59 usbtrace - Device            : /dev/sdb1
19-04-2016-21-33-59 usbtrace - Device-Path       : /devices/pci0000:00/0000:00:13.2/usb....sdb1
19-04-2016-21-33-59 usbtrace - ID/Name           : 4-3:1.0
19-04-2016-21-33-59 usbtrace - Kernel            : sdb1
19-04-2016-21-33-59 usbtrace - Subsystem         : block
19-04-2016-21-33-59 usbtrace - Driver            : usb-storage
19-04-2016-21-33-59 usbtrace - ID_SERIAL_SHORT   : 000000000001FB
19-04-2016-21-33-59 usbtrace - ID_DRIVE_FLASH_CF : 
19-04-2016-21-33-59 usbtrace - Vendor    (Query) : ATTRS{vendor}=="USB2.0 " ATTRS{vendor}=="0x1002"
19-04-2016-21-33-59 usbtrace - Model     (Query) : ATTRS{model}=="FlashDisk "
19-04-2016-21-33-59 usbtrace - Product   (Query) : ATTRS{product}=="USB Mass Storage Device" 
19-04-2016-21-33-59 usbtrace - Start sleep
19-04-2016-21-33-59 usbtrace - exit 0
19-04-2016-21-36-31 usbtrace - Action            : add
19-04-2016-21-36-31 usbtrace - Device            : /dev/sdb2
19-04-2016-21-36-31 usbtrace - Device-Path       : /devices/pci0000:00/0000:00:13.2/usb.....sdb2
19-04-2016-21-36-31 usbtrace - ID/Name           : 4-3:1.0
19-04-2016-21-36-31 usbtrace - Kernel            : sdb2
19-04-2016-21-36-31 usbtrace - Subsystem         : block
19-04-2016-21-36-31 usbtrace - Driver            : usb-storage
19-04-2016-21-36-31 usbtrace - ID_SERIAL_SHORT   : 11032108034168
19-04-2016-21-36-31 usbtrace - ID_DRIVE_FLASH_CF : 
19-04-2016-21-36-31 usbtrace - Vendor    (Query) : ATTRS{vendor}==" " ATTRS{vendor}=="0x1002"
19-04-2016-21-36-31 usbtrace - Model     (Query) : ATTRS{model}==" "
19-04-2016-21-36-31 usbtrace - Product   (Query) : ATTRS{product}=="EHCI Host Controller"
19-04-2016-21-36-31 usbtrace - Start sleep
19-04-2016-21-36-31 usbtrace - exit 0
19-04-2016-21-36-31 usbtrace - Action            : add
19-04-2016-21-36-31 usbtrace - Device            : /dev/sdb1
19-04-2016-21-36-31 usbtrace - Device-Path       : /devices/pci0000:00/0000:00:13.2/usb.....sdb1
19-04-2016-21-36-31 usbtrace - ID/Name           : 4-3:1.0
19-04-2016-21-36-31 usbtrace - Kernel            : sdb1
19-04-2016-21-36-31 usbtrace - Subsystem         : block
19-04-2016-21-36-31 usbtrace - Driver            : usb-storage
19-04-2016-21-36-31 usbtrace - ID_SERIAL_SHORT   : 11032108034168
19-04-2016-21-36-31 usbtrace - ID_DRIVE_FLASH_CF : 
19-04-2016-21-36-31 usbtrace - Vendor    (Query) : ATTRS{vendor}==" " ATTRS{vendor}=="0x1002"
19-04-2016-21-36-31 usbtrace - Model     (Query) : ATTRS{model}==" "
19-04-2016-21-36-31 usbtrace - Product   (Query) : ATTRS{product}=="EHCI Host Controller"
19-04-2016-21-36-31 usbtrace - Start sleep
19-04-2016-21-36-31 usbtrace - exit 0

HTH

[NAB]

TomL, wenn da wirklich keine Cgroups im Spiel sind, könnte man auch einen Doppelfork machen.

[TomL]

TomL, wenn da wirklich keine Cgroups im Spiel sind, könnte man auch einen Doppelfork machen.

Was ist das?

Sorry... neuer Begriff für mich.....muss ich erst mal googlen, was das in diesem Zusammenhang bedeuten könnte

[Eomer]

Sorry, ich muss sagen so ganz verstanden habe ich nicht, was ich tun soll

htop habe ich leider nicht. Sollte ich das auf dem Pi installieren?

Also das Script zum Mounten ist jetzt so:

Code: Alles auswählen

#!/bin/bash
date >> /opt/bin/myfork.log
echo "Versuche: /bin/mount $1 /media/cardreader -o rw" >> /opt/bin/myfork.log

[[ ! -z $(grep $1 /proc/mounts) ]] && exit 1
[ -d /media/cardreader ] || /bin/mkdir -p /media/cardreader
/bin/mount $1 /media/cardreader -o rw
/bin/chmod 777 /media/cardreader

/usr/bin/setsid /usr/bin/lxterminal -e /opt/bin/copyscript.sh

echo $d `basename $0`" - Start sleep" >>/$log
/usr/bin/setsid /bin/bash -c "/bin/sleep 120 &"
echo $d `basename $0`" - exit 0" >>/$log

exit 0

Die rule sieht so aus:

Code: Alles auswählen

#ACTION=="add", KERNEL=="sd??", RUN+="/bin/bash /opt/bin/usbtrace add /dev/%k %p %b $name %E{SUBSYSTEM} $driver %E{ID_SERIAL_SHORT} %E{ID_DRIVE_FLASH_CF}"

KERNEL=="sd??", ACTION=="add",  SUBSYSTEM=="block", ENV{ID_SERIAL_SHORT}=="000000000039", RUN+="/bin/bash /opt/bin/myfork.sh /dev/%k"

EDIT: Inzwischen wird das Script zum kopieren nicht mehr aufgerufen. Also irgendwie passiert da nichts.

Code: Alles auswählen

Apr 19 21:58:11 raspberrypi kernel: [ 3202.513965] usb 1-1.4: USB disconnect, device number 10
Apr 19 21:58:11 raspberrypi systemd-udevd[3425]: inotify_add_watch(6, /dev/sda, 10) failed: No such file or directory
Apr 19 21:58:13 raspberrypi kernel: [ 3205.203518] usb 1-1.5: new high-speed USB device number 11 using dwc_otg
Apr 19 21:58:14 raspberrypi kernel: [ 3205.306638] usb 1-1.5: New USB device found, idVendor=8564, idProduct=4000
Apr 19 21:58:14 raspberrypi kernel: [ 3205.306657] usb 1-1.5: New USB device strings: Mfr=3, Product=4, SerialNumber=5
Apr 19 21:58:14 raspberrypi kernel: [ 3205.306670] usb 1-1.5: Product: Transcend
Apr 19 21:58:14 raspberrypi kernel: [ 3205.306683] usb 1-1.5: Manufacturer: TS-RDF5
Apr 19 21:58:14 raspberrypi kernel: [ 3205.306695] usb 1-1.5: SerialNumber: 000000000039
Apr 19 21:58:14 raspberrypi kernel: [ 3205.307747] usb-storage 1-1.5:1.0: USB Mass Storage device detected
Apr 19 21:58:14 raspberrypi kernel: [ 3205.308987] scsi host6: usb-storage 1-1.5:1.0
Apr 19 21:58:14 raspberrypi mtp-probe: checking bus 1, device 11: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5"
Apr 19 21:58:14 raspberrypi mtp-probe: bus: 1, device: 11 was not an MTP device
Apr 19 21:58:15 raspberrypi kernel: [ 3206.305177] scsi 6:0:0:0: Direct-Access     TS-RDF5  SD  Transcend    TS37 PQ: 0 ANSI: 6
Apr 19 21:58:15 raspberrypi kernel: [ 3206.306162] sd 6:0:0:0: Attached scsi generic sg0 type 0
Apr 19 21:58:15 raspberrypi kernel: [ 3206.583213] sd 6:0:0:0: [sda] 31116288 512-byte logical blocks: (15.9 GB/14.8 GiB)
Apr 19 21:58:15 raspberrypi kernel: [ 3206.584624] sd 6:0:0:0: [sda] Write Protect is off
Apr 19 21:58:15 raspberrypi kernel: [ 3206.584638] sd 6:0:0:0: [sda] Mode Sense: 23 00 00 00
Apr 19 21:58:15 raspberrypi kernel: [ 3206.585426] sd 6:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Apr 19 21:58:15 raspberrypi kernel: [ 3206.589908]  sda: sda1
Apr 19 21:58:15 raspberrypi kernel: [ 3206.595157] sd 6:0:0:0: [sda] Attached SCSI removable disk
Apr 19 21:58:15 raspberrypi kernel: [ 3206.817316] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Apr 19 21:58:15 raspberrypi org.gtk.Private.UDisks2VolumeMonitor[817]: index_parse.c:191: indx_parse(): error opening /media/cardreader/BDMV/index.bdmv
Apr 19 21:58:15 raspberrypi org.gtk.Private.UDisks2VolumeMonitor[817]: index_parse.c:191: indx_parse(): error opening /media/cardreader/BDMV/BACKUP/index.bdmv
Apr 19 21:58:46 raspberrypi systemd-udevd[3425]: timeout '/bin/bash /opt/bin/myfork.sh /dev/sda1'

Liegt glaube ich am:

Code: Alles auswählen

/usr/bin/setsid /usr/bin/lxterminal -e /opt/bin/copyscript.sh

[NAB]

TomL, im Moment machen wir einen Fork ... den kann man als Child-Prozess noch nachvollziehen. Der Mutterprozess muss sterben.

Schau mal hier, den Link hatte ich schon Eomer gegeben:
http://unix.stackexchange.com/questions ... udev-event
Die Lösung von "Alives" gefällt mir am besten ... hilft nur alles nichts, wenn "Elias Probst" Recht hat und Udev jetzt mit Cgroups arbeitet. Aber dann dürfte dein Sleep auch nicht überleben.

Vermutlich machst du mit "setsid" plus "&" auch einen Doppelfork, aber den versteh ich nicht so ganz. Eventuell macht ein
( setsid /opt/bin/goprosync.sh > setsid.log ) &
das Gleiche.

Eomer, mach ma:
apt-get install lxterminal

[TomL]

Code: Alles auswählen

Liegt glaube ich am: /usr/bin/setsid /usr/bin/lxterminal -e /opt/bin/copyscript.sh

Ja, das war der Fehler.... den ich selber erst später bemerkt habe. Beim direkten Test ging das tadellos. Deswegen hatte ich noch mal neu gepostet.... die Variante mit dem Testaufruf "sleep". Damit ist gelungen, den Prozess vom Eltenprozess abzukoppeln. Das heisst, in dieser Form also müsste auch Dein Copy-Job durchlaufen.

Also so:

Code: Alles auswählen

/usr/bin/setsid /bin/bash -c "/opt/bin/copyscript.sh &"

[Eomer]

Ich poste nochmal die Kombination in der ich es habe laufen lassen:

Code: Alles auswählen

#!/bin/bash
date >> /opt/bin/myfork.log
echo "Versuche: /bin/mount $1 /media/cardreader -o rw" >> /opt/bin/myfork.log

[[ ! -z $(grep $1 /proc/mounts) ]] && exit 1
[ -d /media/cardreader ] || /bin/mkdir -p /media/cardreader
/bin/mount $1 /media/cardreader -o rw
/bin/chmod 777 /media/cardreader

/usr/bin/setsid /bin/bash -c "/opt/bin/copyscript.sh &"

Und:

Code: Alles auswählen

KERNEL=="sd??", ACTION=="add",  SUBSYSTEM=="block", ENV{ID_SERIAL_SHORT}=="000000000039", RUN+="/bin/bash /opt/bin/myfork.sh /dev/%k"

Habe es auch in der Kombination:

Code: Alles auswählen

#!/bin/bash
date >> /opt/bin/myfork.log
echo "Versuche: /bin/mount $1 /media/cardreader -o rw" >> /opt/bin/myfork.log

[[ ! -z $(grep $1 /proc/mounts) ]] && exit 1
[ -d /media/cardreader ] || /bin/mkdir -p /media/cardreader
/bin/mount $1 /media/cardreader -o rw
/bin/chmod 777 /media/cardreader

/usr/bin/setsid /bin/bash -c "/opt/bin/copyscript.sh &"

echo $d `basename $0`" - Start sleep" >>/$log
/usr/bin/setsid /bin/bash -c "/bin/sleep 120 &"
echo $d `basename $0`" - exit 0" >>/$log

exit 0

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



EDIT: Lxterminal läuft.

[TomL]

Aber dann dürfte dein Sleep auch nicht überleben.

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

Aber statt nem Doppelfork würde ich - sofern das mit meinem Vorschlag immer noch nicht klappt- einfach die mount-regel nur mounten lassen und danach mit einer zweiten Regel nur den Kopierjob starten. Dann gibt es keine Konflikte mit dem Timeout beim Automount. Die zweite Regel wird ja keinen Timeout haben.

Aber wie gesagt, der Sleep klappte bei mir bei 2 STicks und einem Card-Reader tadellos.

[TomL]

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?