Re: Démarrer un service lorsque un périphérique est prêt
Posté : jeu. 9 févr. 2023 11:52
Ce n'est pas encore la solution miracle car si j'ai bien compris :
les règles udev permettent de :
- renommer un périphérique
- créer des liens symboliques
- forcer une adresse mac (carte réseau)
- préparer les périphériques de partitionnement (disque)
- lancer un programme (si celui si répond très rapidement car cela bloque la poursuite du chargement de udev)
- modifier/créer une variable d'environnement
- détecter le branchement / débranchement à chaud d'un périphériques USB
Il n'est pas fait pour interférer avec les programmes utilisateurs.
Avec les règles udev, je peux dans mon cas :
- détecter le chargement de udev sur mon périphérique et assigner une variable d'environnement par exemple ou lancer un petit script
- mais pas lancer mon service qui est un programme utilisateur
Par contre, j'ai maintenant la méthode avec udevadm pour identifier de manière certaine mon périphérique quelque soit le port usb sur lequel il est branché.
Pour le moment, je ne vois qu'une solution :
- exploiter udevadm dans systemd (ou un script dans systemd) pour identifier mon matériel, voir si le pilote est chargé et s'il l'est : alors démarrer mon service.
Mais je bloque encore car j'aimerai ne pas faire de boucle avec un un sleep (beurk) mais utiliser les bonnes pratiques de systemd (genre : la clé After)
Entretemps, j'ai découvert autre chose :
Si je lance mon service par init.d (à l'ancienne), il démarre alors que le pilote est chargé, alors que si j'utilise systemd, il essaie de démarrer avant.
What the F .... ?
On pourrait dire que ça résoud le Pb mais non : la méthode par init.d est destinée à disparaitre dans un avenir de plus en plus proche.
les règles udev permettent de :
- renommer un périphérique
- créer des liens symboliques
- forcer une adresse mac (carte réseau)
- préparer les périphériques de partitionnement (disque)
- lancer un programme (si celui si répond très rapidement car cela bloque la poursuite du chargement de udev)
- modifier/créer une variable d'environnement
- détecter le branchement / débranchement à chaud d'un périphériques USB
Il n'est pas fait pour interférer avec les programmes utilisateurs.
Avec les règles udev, je peux dans mon cas :
- détecter le chargement de udev sur mon périphérique et assigner une variable d'environnement par exemple ou lancer un petit script
- mais pas lancer mon service qui est un programme utilisateur
Par contre, j'ai maintenant la méthode avec udevadm pour identifier de manière certaine mon périphérique quelque soit le port usb sur lequel il est branché.
Pour le moment, je ne vois qu'une solution :
- exploiter udevadm dans systemd (ou un script dans systemd) pour identifier mon matériel, voir si le pilote est chargé et s'il l'est : alors démarrer mon service.
Mais je bloque encore car j'aimerai ne pas faire de boucle avec un un sleep (beurk) mais utiliser les bonnes pratiques de systemd (genre : la clé After)
Entretemps, j'ai découvert autre chose :
Si je lance mon service par init.d (à l'ancienne), il démarre alors que le pilote est chargé, alors que si j'utilise systemd, il essaie de démarrer avant.
What the F .... ?
On pourrait dire que ça résoud le Pb mais non : la méthode par init.d est destinée à disparaitre dans un avenir de plus en plus proche.