Ceci a piqué ma curiosité, et je suis allé voir comment détecter quand
j'insère ou retire ma clé usb (partition sdd1):
quand j'utilise ceci :
udevadm monitor \
| egrep --line-buffered "UDEV.+sdd1" \
| while $(true)
do
read event
event=$(echo "$event" | cut -d' ' -f4 )
echo $event
done
$event est 'add' quand j'insère la clé
$event est 'remove' quand je retire la clé
Si çà peut servir. Il faut d'abord que 'udevadm monitor' détecte ton device...
NOTE: J'ai reformaté et pas testé, ma ligne de commande originale est:
udevadm monitor | egrep --line-buffered "UDEV.+sdd1" | while $(true); do read
event ; event=$(echo "$event" | cut -d' ' -f4 ) ; echo $event ; done
Le 09/11/2023 à 21:36, Patrice Karatchentzeff a écrit :
> Le jeu. 9 nov. 2023 à 20:55, Edgar Bonet <guilde@???> a écrit :
>>
>> Patrice Karatchentzeff a écrit :
>>> Un truc de bourrin si jamais c'est bogué... Tu lances un second
>>> service qui monitore l'absence de connexion et qui kille les deux
>>> unités actives...
>>
>> Merci pour la suggestion. Je risque, en effet, de faire quelque chose de
>> ce style si je ne trouve pas de meilleure solution : une boucle infinie
>> qui attend l'apparition du port, lance le service, attend sa
>> disparition, arrête le service, puis recommence.
>>
>> Je trouve cependant ce genre d'approche, avec attente active, pas très
>> élégante. Surtout quand on a un système d'init qui se prétend être aussi
>> un « service manager ». De plus, systemd.path(5) dit
>>
>> Internally, path units use the inotify(7) API to monitor
>> file systems.
>>
>> ce qui semble bien plus élégant qu'une attente active...
>
> Techniquement, c'est identique... C'est une boucle qui renifle la
> sortie d'inotify pour lancer et arrêter le service.
>
> D'ailleurs, quitte à faire le script que tu proposes, tu pourrais
> directement attaquer le problème avec inotify.
>
> Mais bon, faut avoir un peu de temps... Ma solution ultra-bourrine
> avait l'avantage de plier le problème en un rien de temps, en
> attendant une solution propre à la systemd.
>
> PK
>
