Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

[udev] lancer une synchronisation de dossiers quand j'insère une clé usb

31 réponses
Avatar
Francois Lafont
Bonjour à tous,

Je suis sous Debian Squeeze avec Gnome version "2.3". Je voudrais que,
juste après avoir branché une clé usb particulière, la commande suivante
soit exécutée :

rsync -ax --progress --delete /dossier/source/ /media/ma-cle/cible/

afin de synchroniser un dossier « cible » de ma clé usb avec un dossier
« source » de mon PC.

Voilà où j'en suis pour l'instant. J'ai crée le fichier «
101-MY-key-save.rules » dans le dossier « /etc/udev/rules.d » et ce
fichier contient cette ligne là :

ACTION=="add", ATTRS{product}=="Cruzer",
ATTRS{serial}=="445671168F907F84", RUN+="/home/francois/Bureau/go.bash"

C'était juste un test idiot où le script go.bash est le suivant :

#----------------------------------------
#! /bin/bash

echo "Éxecution..." >> "/home/francois/Bureau/out.txt"
#----------------------------------------

1) Mon problème, c'est que, lorsque j'insère ma clé usb, j'ai bien un
fichier « out.txt » qui est crée sur le Bureau mais il contient 11 fois
la ligne « Éxecution... » ? J'en conclus que le script « go.bash » a été
lancé 11 fois, non ? Pourquoi ? J'imaginais qu'il y aurait une seule
exécution ?

Une fois que j'aurais résolu ce problème, j'aurais d'autres obstacles à
surmonter sur lesquels je n'ai pas trop d'idée :

2) A priori ma clé est automatiquement monté sur le dossier «
/media/KEYSAVE ». Mais comment être sûr d'exécuter le script « go.bash »
après le montage. J'ai nommé ma règle udev « 101-MY-key-save.rules » et
je pensais que la valeur 101 me garantissait que l'exécution se
produirait en dernier (ou presque). Pourtant, de visu, il m'a semblé que
le montage de la clé s'effectuait un temps après l'exécution du script.

3) Ou bien je pourrais gérer un montage puis démontage de la clé « fait
maison » dans le script « go.bash » mais dans ce cas comment connaître à
l'avance le nom de fichier associé à ma clé dans /dev (même si ça semble
être /dev/sdc souvent mais si j'insère avec une autre clé usb avant...) ?

Merci d'avance pour votre aide.

--
François Lafont

10 réponses

1 2 3 4
Avatar
Nicolas George
Francois Lafont , dans le message
<4eaff482$0$27609$, a écrit :
1) Mon problème, c'est que, lorsque j'insère ma clé usb, j'ai bien un
fichier « out.txt » qui est crée sur le Bureau mais il contient 11 fois
la ligne « Éxecution... » ? J'en conclus que le script « go.bash » a été
lancé 11 fois, non ? Pourquoi ? J'imaginais qu'il y aurait une seule
exécution ?



Il y a une exécution à chaque fois q'udev détecte un nouveau « truc » lié à
un périphérique de nom de procuit « Cruzer » et de numéro de série
« 445671168F907F84 », mais de tels trucs, il y en a pas mal : extrémité USB,
support de stockage, partition, filesystem, etc.

2) A priori ma clé est automatiquement monté sur le dossier «
/media/KEYSAVE ». Mais comment être sûr d'exécuter le script « go.bash »
après le montage. J'ai nommé ma règle udev « 101-MY-key-save.rules » et
je pensais que la valeur 101 me garantissait que l'exécution se
produirait en dernier (ou presque).



D'une part non, c'est un ordre lexicographique qui compte, pas un ordre
numérique, donc 101 se trouve entre 10 et 11. D'autre part, ça n'est valable
que si le montage est fait de manière synchrone par un script udev, et pas
de manière asynchrone par un environnement de bureau notifié par dbus.
Avatar
Bruno Tréguier
Le 01/11/2011 à 14:32, Francois Lafont a écrit :
Bonjour à tous,

Je suis sous Debian Squeeze avec Gnome version "2.3". Je voudrais que,
juste après avoir branché une clé usb particulière, la commande suivante
soit exécutée :

rsync -ax --progress --delete /dossier/source/ /media/ma-cle/cible/

afin de synchroniser un dossier « cible » de ma clé usb avec un dossier
« source » de mon PC.

Voilà où j'en suis pour l'instant. J'ai crée le fichier «
101-MY-key-save.rules » dans le dossier « /etc/udev/rules.d » et ce
fichier contient cette ligne là :

ACTION=="add", ATTRS{product}=="Cruzer",
ATTRS{serial}=="445671168F907F84", RUN+="/home/francois/Bureau/go.bash"

C'était juste un test idiot où le script go.bash est le suivant :

#----------------------------------------
#! /bin/bash

echo "Éxecution...">> "/home/francois/Bureau/out.txt"
#----------------------------------------

1) Mon problème, c'est que, lorsque j'insère ma clé usb, j'ai bien un
fichier « out.txt » qui est crée sur le Bureau mais il contient 11 fois
la ligne « Éxecution... » ? J'en conclus que le script « go.bash » a été
lancé 11 fois, non ? Pourquoi ? J'imaginais qu'il y aurait une seule
exécution ?



Bonsoir,

Je pense qu'en fait, votre règle dans le fichier rules n'est pas assez
spécifique.

Comme vous l'a dit Nicolas Georges dans son message, il y a une
exécution du script à chaque fois que quelque chose se passe en rapport
avec la clef dont vous avez donné les caractéristiques dans la ligne du
fichier rules. Cela peut d'ailleurs se voir via la commande suivante:

$ udevadm monitor --udev

Lancez-la et insérez votre clef. Vous verrez... ;-)

Du coup, en étant plus spécifique dans la règle, et en vous limitant au
sous-système "block" et à l'identifiant "sd*1" (sdb1, sdc1, etc.), pour
désigner la 1ère partition de votre clef (si elle est partitionnée ainsi
tout au moins), on a la ligne suivante, qui ne devrait "matcher" qu'une
seule fois et provoquer, du coup, une seule exécution de votre script:

KERNEL=="sd*1", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ACTION=="add",
ATTRS{product}=="Cruzer", ATTRS{serial}=="445671168F907F84",
RUN+="/home/francois/Bureau/go.bash"


Une fois que j'aurais résolu ce problème, j'aurais d'autres obstacles à
surmonter sur lesquels je n'ai pas trop d'idée :



On verra en temps utile... ;)

Cordialement,

--
Bruno Tréguier
Avatar
Francois Lafont
Le 01/11/2011 18:49, Nicolas George a écrit :

Il y a une exécution à chaque fois q'udev détecte un nouveau « truc » lié à
un périphérique de nom de procuit « Cruzer » et de numéro de série
« 445671168F907F84 », mais de tels trucs, il y en a pas mal : extrémité USB,
support de stockage, partition, filesystem, etc.



Ok, je vois. Personnellement, je pensais que justement, avec le numéro
de série, j'étais globalement sûr que ça ne concernerait que ma clé usb.
Mais je ne pensais pas que ma clé usb était vu par udev comme plein de
composants différents.

2) A priori ma clé est automatiquement monté sur le dossier «
/media/KEYSAVE ». Mais comment être sûr d'exécuter le script « go.bash »
après le montage. J'ai nommé ma règle udev « 101-MY-key-save.rules » et
je pensais que la valeur 101 me garantissait que l'exécution se
produirait en dernier (ou presque).



D'une part non, c'est un ordre lexicographique qui compte, pas un ordre
numérique, donc 101 se trouve entre 10 et 11.



Ok, merci pour cette rectification.

D'autre part, ça n'est valable
que si le montage est fait de manière synchrone par un script udev, et pas
de manière asynchrone par un environnement de bureau notifié par dbus.



Je ne suis pas sûr d'avoir compris cette phrase.

Ça veut dire que le montage automatique de ma clé n'est pas géré par
udev mais par Gnome et cela indépendamment de udev, c'est ça ?

Si c'est ça, alors udev ne serait pas la bonne piste pour réaliser ma
synchronisation automatique de dossiers ? Par ailleurs, je viens de
regarder la page man de udev et ceci semble indiquer que je ne vais pas
dans la bonne direction :

« RUN : Add a program to the list of programs to be executed for a
specific device. This can only be used for very short running tasks.
Running an event process for a long period of time may block all further
events for this or a dependent device. Long running tasks need to be
immediately detached from the event process itself. »

Ça aussi, ça ne va pas dans le bon sens pour mon problème car la
synchronisation des dossiers ne sera pas souvent a priori une tâche très
courte dans son exécution.


--
François Lafont
Avatar
Francois Lafont
Le 01/11/2011 23:36, Bruno Tréguier a écrit :

Du coup, en étant plus spécifique dans la règle, et en vous limitant au
sous-système "block" et à l'identifiant "sd*1" (sdb1, sdc1, etc.), pour
désigner la 1ère partition de votre clef (si elle est partitionnée ainsi
tout au moins), on a la ligne suivante, qui ne devrait "matcher" qu'une
seule fois et provoquer, du coup, une seule exécution de votre script:

KERNEL=="sd*1", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ACTION=="add",
ATTRS{product}=="Cruzer", ATTRS{serial}=="445671168F907F84",
RUN+="/home/francois/Bureau/go.bash"



Ok. Merci beaucoup pour ces précisions. En utilisant la ligne
ci-dessous, j'ai bien une seule exécution du script après avoir inséré
ma clé usb :

KERNEL=="sd*", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ACTION=="add",
ATTRS{product}=="Cruzer", ATTRS{serial}=="445671168F907F84",
RUN="/home/francois/Bureau/go.bash"

KERNEL=="sd*1" ne convenait pas car lorsque j'insére ma clé, c'est
/dev/sdc qui est monté et il n'y a pas de /dev/sdc1 ce qui au passage me
surprend un peu car je pensais qu'on avait toujours /dev/sdc pour le
périphérique dans son ensemble et /dev/sdc1, ..., /dev/sdcN pour les
partitions, même avec une seule partition.

Une fois que j'aurais résolu ce problème, j'aurais d'autres obstacles à
surmonter sur lesquels je n'ai pas trop d'idée :



On verra en temps utile... ;)



J'ai l'impression que udev n'est pas la bonne piste pour mon problème.
Mais je me trompe peut-être.

--
François Lafont
Avatar
Nicolas George
Francois Lafont , dans le message
<4eb079a3$0$18974$, a écrit :
Ok, je vois. Personnellement, je pensais que justement, avec le numéro
de série, j'étais globalement sûr que ça ne concernerait que ma clé usb.



Tu as mis ATTRS, qui dit de chercher dans les attributs de tous les
périphériques sous-tendant le nouvel élément détecté : support, contrôleur,
etc. L'autre possibilité est de mettre ATTR, mais ça ne marchera pas, parce
que le numéro de série est une caractéristique du support, pas de la
partition que tu veux monter.

Ça veut dire que le montage automatique de ma clé n'est pas géré par
udev mais par Gnome et cela indépendamment de udev, c'est ça ?



Probablement par Gnome, si c'est ce que tu utilises Gnome, et après
notification par udev à travers dbus : une règle udev (ou le fonctionnement
normal, je n'ai pas vérifié) dit d'envoyer un message sur dbus, et ton
bureau récupère la notification.

Par ailleurs, je viens de
regarder la page man de udev et ceci semble indiquer que je ne vais pas
dans la bonne direction :

« RUN : Add a program to the list of programs to be executed for a
specific device. This can only be used for very short running tasks.
Running an event process for a long period of time may block all further
events for this or a dependent device. Long running tasks need to be
immediately detached from the event process itself. »

Ça aussi, ça ne va pas dans le bon sens pour mon problème car la
synchronisation des dossiers ne sera pas souvent a priori une tâche très
courte dans son exécution.



Il suffit de la lancer en tâche de fond depuis le script que tu invoques par
udev.

Mais personnellement, je pense que c'est une idée plutôt risquée d'un point
de vue utilisabilité : une synchronisation qui se lance en tâche de fond,
immédiatement quand on branche un périphérique, c'est un coup à se faire des
ennuis un jour où on est pressé.

Il vaudrait mieux, à mon avis, viser un raccourci très rapide pour lancer la
synchronisation manuellement, ou au pire semi-automatiquement, et avec un
retour visuel de la progression.
Avatar
Bruno Tréguier
Le 02/11/2011 à 0:00, Francois Lafont a écrit :
Le 01/11/2011 18:49, Nicolas George a écrit :
D'autre part, ça n'est valable
que si le montage est fait de manière synchrone par un script udev, et pas
de manière asynchrone par un environnement de bureau notifié par dbus.



Je ne suis pas sûr d'avoir compris cette phrase.

Ça veut dire que le montage automatique de ma clé n'est pas géré par
udev mais par Gnome et cela indépendamment de udev, c'est ça ?



Je pense que c'est effectivement ce que veut dire Nicolas (mais je me
trompe peut-être). Udev ne se charge pas directement du montage, en fait
(sauf s'il y a des scripts pour cela dans les fichiers de règles, avec
des actions "RUN" qui vont bien).

Pour être certain de pouvoir faire votre synchro, il faudrait donc
prévoir, dans votre script, le montage, le rsync, puis le démontage de
la clef. Le problème est alors de savoir comment tout cela va interagr
avec le système d'auto-montage de gnome (que je ne connais pas).


Si c'est ça, alors udev ne serait pas la bonne piste pour réaliser ma
synchronisation automatique de dossiers ? Par ailleurs, je viens de
regarder la page man de udev et ceci semble indiquer que je ne vais pas
dans la bonne direction :

« RUN : Add a program to the list of programs to be executed for a
specific device. This can only be used for very short running tasks.
Running an event process for a long period of time may block all further
events for this or a dependent device. Long running tasks need to be
immediately detached from the event process itself. »

Ça aussi, ça ne va pas dans le bon sens pour mon problème car la
synchronisation des dossiers ne sera pas souvent a priori une tâche très
courte dans son exécution.



Ca, ce n'est pas vraiment un problème: la synchro et le démontage
peuvent être simplement lancés en tâche de fond par le script en
question (qui, lui, rend la main une fois le montage effectué)...

Cordialement,

--
Bruno Tréguier
Avatar
Bruno Tréguier
Bonsoir et désolé pour le quasi-doublon. On a posté en même temps à
quelques secondes près... ;-)

Le 02/11/2011 à 0:24, Nicolas George a écrit :
Mais personnellement, je pense que c'est une idée plutôt risquée d'un point
de vue utilisabilité : une synchronisation qui se lance en tâche de fond,
immédiatement quand on branche un périphérique, c'est un coup à se faire des
ennuis un jour où on est pressé.



C'est vrai, ne serait-ce que parce qu'on est jamais sûr, avec ce
système, du moment où tout ça se termine... Cela dit, tout dépend de ce
qu'on veut faire: moyennant un tout petit peu "d'ingénierie sociale",
c'est un assez bon plan pour récupérer des infos sur la clef USB de
quelqu'un d'autre (suffit de virer le numéro de série des exigences de
la règle et hop, on a un bel aspirateur...).

Mais y'a que des méchants qui auraient ce genre d'idées... ;-)

Cordialement,

--
Bruno Tréguier
Avatar
Francois Lafont
Le 02/11/2011 00:24, Nicolas George a écrit :

Tu as mis ATTRS, qui dit de chercher dans les attributs de tous les
périphériques sous-tendant le nouvel élément détecté : support, contrôleur,
etc. L'autre possibilité est de mettre ATTR, mais ça ne marchera pas, parce
que le numéro de série est une caractéristique du support, pas de la
partition que tu veux monter.



Ok, la subtilité entre ATTRS et ATTR m'avait échappé.

De toute façon, Bruno Tréguier m'a donné les indications pour que la
règle soit suffisamment sélective (cf mon message précédent).

Ça veut dire que le montage automatique de ma clé n'est pas géré par
udev mais par Gnome et cela indépendamment de udev, c'est ça ?



Probablement par Gnome, si c'est ce que tu utilises Gnome, et après
notification par udev à travers dbus : une règle udev (ou le fonctionnement
normal, je n'ai pas vérifié) dit d'envoyer un message sur dbus, et ton
bureau récupère la notification.



Dans les règles déjà existantes, je suis tombé sur celle-ci :

$ cat /etc/udev/hdparm.rules
ACTION=="add", SUBSYSTEM=="block", KERNEL=="[sh]d[a-z]",
RUN+="/etc/init.d/hdparm hotplug"

C'est sûrement elle qui doit faire ce que tu décris. Je suis allé voir
le script init.d mais ça me dépasse.

Ça aussi, ça ne va pas dans le bon sens pour mon problème car la
synchronisation des dossiers ne sera pas souvent a priori une tâche très
courte dans son exécution.



Il suffit de la lancer en tâche de fond depuis le script que tu invoques par
udev.



Oui exact, avec le caractère "&".

Mais personnellement, je pense que c'est une idée plutôt risquée d'un point
de vue utilisabilité : une synchronisation qui se lance en tâche de fond,
immédiatement quand on branche un périphérique, c'est un coup à se faire des
ennuis un jour où on est pressé.



Oui, dans l'absolu, je crois bien que tu as raison et en fait, tout ça
va se finir dans un petit alias de mon ~/.bashrc :

alias Synchronise-travail='rsync -axv --delete
/home/francois/MesDocs/travail/ /media/KEYSAVE/save/travail/'

Ceci étant, « pour la beauté du sport », j'aurais bien aimé mettre la
chose en place avec udev juste une fois. :-) C'est pourquoi je vais
essayer quand même d'aller au bout du fil. Mais encore une fois, je me
contenterai au final d'un alias.

Il vaudrait mieux, à mon avis, viser un raccourci très rapide pour lancer la
synchronisation manuellement, ou au pire semi-automatiquement, et avec un
retour visuel de la progression.



Ce que tu décris là serait l'idéal, mais hélas au niveau du retour
visuel de la progression j'ai peur que ça dépasse mes compétences. J'ai
bien quelques connaissances en Python et une fois dans ma vie j'ai
programmé un petit truc de rien du tout avec une fenêtre (avec le module
Tkinter) et ça m'avait pris du temps. :-)


Petite question à propos de rsync :
J'ai été un déçu par la lenteur d'exécution de la commande :

rsync -axv --delete /home/francois/MesDocs/travail/
/media/KEYSAVE/save/travail/

Avant rsync, j'effaçais dans ma clé et je recopiais intégralement de
dossier travail de mon PC ce qui était assez long pour finalement mettre
à jour un nombre assez limité de fichiers. Avec rsync, même quand au
final il y a très peu de fichiers à mettre à jour, la commande reste
quand même assez long. Est-ce normal ? Ma clé est un clé Usb 2 classique
de 2G et le dossier travail compte 6892 « petits » fichiers (des pdf et
des .tex) et 890 dossiers le tout faisant 600 Mégas.


--
François Lafont
Avatar
Francois Lafont
Le 02/11/2011 00:24, Bruno Tréguier a écrit :

Ça aussi, ça ne va pas dans le bon sens pour mon problème car la
synchronisation des dossiers ne sera pas souvent a priori une tâche très
courte dans son exécution.



Ca, ce n'est pas vraiment un problème: la synchro et le démontage
peuvent être simplement lancés en tâche de fond par le script en
question (qui, lui, rend la main une fois le montage effectué)...



Ok, est-ce que vous voulez dire un truc comme ça par exemple ?

#------------------------------------
#! /bin/bash

# Supposons que la clé usb soit /dev/sdc
# Supposons que le dossier /mnt/KEYSAVE existe déjà :

mount -t vfat /dev/sdc /mnt/KEYSAVE

{
rsync -axv --progress --delete /dossier/source/ /media/ma-cle/cible/
umount /mnt/KEYSAVE
} &
#------------------------------------


--
François Lafont
Avatar
Francois Lafont
J'oubliais une remarque.

Le 03/11/2011 16:40, Francois Lafont a écrit :

Ca, ce n'est pas vraiment un problème: la synchro et le démontage
peuvent être simplement lancés en tâche de fond par le script en
question (qui, lui, rend la main une fois le montage effectué)...



Ok, est-ce que vous voulez dire un truc comme ça par exemple ?

#------------------------------------
#! /bin/bash

# Supposons que la clé usb soit /dev/sdc



En admettant que mon script soit à peu prêt correct, je ne peux pas
prédire à l'avance si la clé usb correspondra à /dev/sdb ou à /dev/sdc
etc. ce qui pose un problème.


--
François Lafont
1 2 3 4