udev (Français)

État de la traduction:
Cet article est la version francophone de
udev
. Date de la dernière traduction: 2022-10-05. Vous pouvez aider à synchroniser la traduction s'il y a eu des
changements
dans la version anglaise.
Related articles
udisks
udev
est une interface entre le
noyau
et l'utilisateur qui permet au système d'exploitation d'enregistrer la gestion des événements en espace utilisateur. Les événements décodés par le
daemon
d'
udev
sont en effet principalement déclenchés par le noyau Linux en réponse à des signaux physiques comme la connexion d'un périphérique plug-and-play. De ce point de vue, la principale fonction d'
udev
est la détection de  périphérique et la connexion de ports intelligents, ainsi que la restitution du contrôle au noyau Linux, par ex. le chargement de modules ou de
firmwares
vers le noyau. Un autre élément de cette détection consiste à ajuster les autorisations de l'appareil pour qu'il soit accessible aux utilisateurs et groupes non root.
En tant que successeur de
devfsd
et de
hotplug
,
udev
gère également les nœuds de périphériques dans le répertoire
/dev
en les ajoutant, en créant des liens symboliques et en les renommant.
udev
remplace les fonctionnalités de
hotplug
et de
hwdetect
.
udev
traite des événements distincts simultanément (en parallèle), ce qui entraîne une amélioration potentielle des performances par rapport aux anciens systèmes. En même temps, cela peut compliquer l'administration du système, car, par exemple, l'ordre de chargement des modules du noyau n'est pas préservé d'un démarrage à l'autre. Si la machine possède plusieurs périphériques de type bloc, cela peut se manifester sous la forme de nœuds de périphérique changeant de désignation après le redémarrage. Par exemple, si la machine possède deux disques durs,
/dev/sda
peut devenir
/dev/sdb
au prochain démarrage. Poursuivez votre lecture pour plus d'informations à ce sujet.
Installation
udev
fait partie de
systemd
et est donc installé par défaut. Consultez
systemd-udevd.service(8)
pour plus d'informations.
Introduction aux règles udev
Les règles
udev
écrites par l'administrateur se trouvent dans
/etc/udev/rules.d/
, leur nom de fichier doit se terminer par
.rules
. Les règles
udev
fournies avec divers paquets se trouvent dans
/usr/lib/udev/rules.d/
. S'il y a deux fichiers du même nom sous
/usr/lib
et
/etc
, celui de
/etc
est prioritaire.
Pour en savoir plus sur les règles
udev
, reportez-vous au manuel
udev(7)
. Consultez également
Writing udev rules
et des exemples pratiques sont fournis dans le guide :
Rédaction des règles udev - Exemples
.
Exemple de règle udev
Voici un exemple de règle qui crée un lien symbolique
/dev/video-cam
lorsqu'une webcam est connectée.
Disons que cette caméra est actuellement connectée et a été chargée avec le nom de périphérique
/dev/video2
. La raison de l'écriture de cette règle est qu'au prochain démarrage, le périphérique pourrait apparaître sous un nom différent, comme
/dev/video0
.
$ udevadm info --attribute-walk --path=$(udevadm info --query=path --name=/dev/video2)
Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices.
It prints for every device found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device and the attributes from one single parent device.

looking at device '/devices/pci0000:00/0000:00:04.1/usb3/3-2/3-2:1.0/video4linux/video2':
  KERNEL=="video2"
  SUBSYSTEM=="video4linux"
   ...
looking at parent device '/devices/pci0000:00/0000:00:04.1/usb3/3-2/3-2:1.0':
  KERNELS=="3-2:1.0"
  SUBSYSTEMS=="usb"
  ...
looking at parent device '/devices/pci0000:00/0000:00:04.1/usb3/3-2':
  KERNELS=="3-2"
  SUBSYSTEMS=="usb"
  ATTRS{idVendor}=="05a9"
  ATTRS{manufacturer}=="OmniVision Technologies, Inc."
  ATTRS{removable}=="unknown"
  ATTRS{idProduct}=="4519"
  ATTRS{bDeviceClass}=="00"
  ATTRS{product}=="USB Camera"
  ...
Pour identifier la webcam, à partir du périphérique
video4linux
, nous utilisons
KERNEL=="video2"
et
SUBSYSTEM=="video4linux"
, puis nous remontons deux niveaux au-dessus, nous faisons correspondre la webcam en utilisant les identifiants du fournisseur et du produit du parent usb
SUBSYSTEMS=="usb"
,
ATTRS{idVendor}=="05a9"
et
ATTRS{idProduct}=="4519"
.
Nous sommes maintenant en mesure de créer une règle de correspondance pour ce périphérique comme suit :
/etc/udev/rules.d/83-webcam.rules
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="05a9", ATTRS{idProduct}=="4519", SYMLINK+="video-cam"
Nous créons ici un lien symbolique en utilisant
SYMLINK+="video-cam"
mais nous pourrions facilement définir l'utilisateur
OWNER="john"
ou le groupe en utilisant
GROUP="video"
ou définir les autorisations en utilisant
MODE="0660"
.
Si vous avez l'intention d'écrire une règle pour faire quelque chose lorsqu'un périphérique est retiré, sachez que les attributs du périphérique peuvent ne pas être accessibles. Dans ce cas, vous devrez travailler avec des
variables d'environnement
de périphérique prédéfinies. Pour surveiller ces variables d'environnement, exécutez la commande suivante tout en débranchant votre périphérique :
$ udevadm monitor --environment --udev
Dans le résultat de cette commande, vous consulterez des paires de valeurs telles que
ID_VENDOR_ID
et
ID_MODEL_ID
, qui correspondent aux attributs précédemment utilisés
idVendor
et
idProduct
. Une règle qui utilise les variables d'environnement du périphérique au lieu des attributs du périphérique peut ressembler à ceci :
/etc/udev/rules.d/83-webcam-removed.rules
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="05a9", ENV{ID_MODEL_ID}=="4519", RUN+="
/path/to/your/script
"
Lister les attributs d'un périphérique
Pour obtenir une liste de tous les attributs d'un périphérique que vous pouvez utiliser pour écrire des règles, exécutez cette commande :
$ udevadm info --attribute-walk --name=
device_name
Remplacez
device_name
par le périphérique présent dans le système, tel que
/dev/sda
ou
/dev/ttyUSB0
.
Si vous ne connaissez pas le nom du périphérique, vous pouvez également lister tous les attributs d'un chemin système spécifique :
$ udevadm info --attribute-walk --path=/sys/class/backlight/acpi_video0
Pour affiner la recherche d'un périphérique, déterminez sa classe et exécutez :
$ ls /dev/
class
/by-id
Vous pouvez utiliser le lien symbolique ou ce qu'il pointe comme entrée de
--name
. Par exemple :
$ udevadm info --attribute-walk --name=/dev/input/by-id/usb-foostan_Corne-event-kbd
Pour obtenir le chemin d'un périphérique USB nu qui ne contient aucun périphérique subordonné, vous devez utiliser le chemin complet du périphérique USB. Démarrez le mode moniteur, puis branchez le périphérique USB pour l'obtenir :
$ udevadm monitor
...
KERNEL[26652.638931] add /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:05.0/0000:05:00.0/usb1/1-3 (usb)
KERNEL[26652.639153] add /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:05.0/0000:05:00.0/usb1/1-3/1-3:1.0 (usb)
...
Vous pouvez simplement choisir le chemin le plus profond et
--attribute-walk
montrera de toute façon tous les attributs du parent :
Vous pouvez simplement choisir le chemin le plus profond et
--attribute-walk
montrera de toute façon tous les attributs du parent :
$ udevadm info --attribute-walk --path=
/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:05.0/0000:05:00.0/usb1/1-3/1-3:1.0
Test des règles avant le chargement
# udevadm test $(udevadm info --query=path --name=
device_name
) 2>&1
Cette procédure n'exécutera pas toutes les actions de vos nouvelles règles, mais elle traitera les règles symlink sur les périphériques existants, ce qui peut s'avérer utile si vous ne parvenez pas à les charger autrement. Vous pouvez également fournir directement le chemin du périphérique pour lequel vous voulez tester la règle
udev
:
# udevadm test /sys/class/backlight/acpi_video0/
Charger de nouvelles règles
udev
détecte automatiquement les modifications apportées aux fichiers de règles, ainsi les changements prennent effet immédiatement sans nécessiter le redémarrage de
udev
. Cependant, les règles ne sont pas redéclenchées automatiquement sur les périphériques déjà existants. Les périphériques connectables à chaud, comme les périphériques USB, devront probablement être reconnectés pour que les nouvelles règles prennent effet, ou au moins décharger et recharger les modules du noyau ohci-hcd et ehci-hcd et ainsi recharger tous les pilotes USB.
Si les règles ne se rechargent pas automatiquement :
# udevadm control --reload
Pour forcer manuellement
udev
à déclencher vos règles :
# udevadm trigger
Composantes des règles udev
Action de l'évènement
La directive
ACTION==""
permet de limiter la règle à s'activer uniquement lorsque quelque-chose de spécifique se produit avec un appareil, habituellement lorsqu'il est branché ou débranché. Il y a huit types d'actions qu'un évènement peut avoir:
add/remove
Lorsque le noeud d'un appareil (dans /dev/) est créé/détruit
bind/unbind
Quand un pilote est attaché/détaché d'un appareil
change
Levée manuellement par les pilotes lors d'un "changement d'état de l'appareil", sans signification normalisée
offline
Quand un appareil (souvent de la
mémoire vive
ou des
processeurs
) devient bloqué en vue d'un débranchement à chaud
online
Quand un appareil précédemment marqué "offline" redevient disponible
move
Quand un appareil (habituellement une interface réseau) est renommée,
idéalement jamais
L'action KOBJ_CHANGE
Le type d'action "change" est particulier, étant donné que les pilotes ne s'en servent pas tous de la même manière, voire pas du tout. L'évènement "change" est uniquement émis lorsqu'un pilote lève un évènement vers l'espace utilisateur (
userspace event
, ou uevent) de type
KOBJ_CHANGE
. Cela signale qu'il est arrivé
quelque-chose
à l'appareil, mais il faut davantage de contexte pour déterminer quoi exactement.
Puisque cet évènement est seulement lancé dans un nombre fini de circonstances, voici un tableau (pas encore exhaustif) contenant la liste des sous-systèmes qui peuvent émettre un évènement de type "change", et dans quelles conditions.
SUBSYSTEM
Déclencheur
Propriétés spécifiques à l'évènement
Documentation
typec
Changement du alt-mode, du rôle USB-PD ou du sens de la connexion
Aucun
usb_role
Changement du sens de la connexion (pour les appareils USB OTG ou Type-C)
USB_ROLE_SWITCH=
avec la valeur
none
,
host
ou
device
, selon le nouveau rôle de l'ordinateur
block
Changement de carte ou de disque dans un lecteur
DISK_MEDIA_CHANGE=1
quand le contenu change ou
DISK_EJECT_REQUEST=1
juste avant l'éjection
drm
Appareil détecté comme "coincé" (le pilote ne peut plus rien faire car l'appareil ne répond plus)
WEDGED=
avec une liste de méthodes disponibles pour réinitialiser l'appareil, comme
rebind
ou
bus-reset
Device wedging
drm
Écran connecté ou déconnecté
HOTPLUG=1
, parfois aussi
CONNECTOR=
avec l'ID interne du connecteur
drm
Changement d'une des propriétés du connecteur (comme l'état HDCP)
CONNECTOR=
et
PROPERTY=
avec leurs ID internes respectifs
backlight
Changement de luminosité
SOURCE=
avec comme valeur
sysfs
,
hotkey
ou
unknown
selon ce qui a déclanché le changement
power_supply
Changement dans l'état de la source d'alimentation (chargent branché ou débranché, batterie en charge ou en décharge, etc.)
Aucun
rfkill
Radio (Wi-Fi, Bluetooth, LTE, etc.) allumée ou éteinte par sa "killswitch" ou par un menu
Aucun
thunderbolt
Changement de mode de tunnelage
TUNNEL_EVENT=
avec l'état du tunnel, possiblement aussi
TUNNEL_DETAILS=
Thunderbolt tunneling events
N'importe quel appareil avec un groupe d'attributs
power/
Recevoir ou perdre la capacité de sortir le système de veille
1
(c-à-d: lorsque les attributs
power/wakeup*
apparaissent ou disparaissent)
Aucun
Device Power Management Basics
, mais ce uevent n'est pas documenté
Tous (uevent synthétique)
Écrire
change $(uuidgen) MACHIN=TOTO
dans le fichier uevent de n'importe quel appareil dans sysfs
2
SYNTH_UUID=
avec l'UUID écrit dans le fichier, et aussi
SYNTH_ARG_MACHIN=TOTO
pour toute paire de clé et de valeur écrite après l'UUID
sysfs-uevent
Recevoir ou perdre la capacité de sortir le système de veille est intéressant pour des cas comme USB, puisque les appareils USB ne peuvent pas réveiller le système lorsqu'ils sont en attente d'être (re)configurés.
La directive
OPTIONS+="watch"
dans une règle udev ainsi que la commande
udevadm trigger
vont faire lever un évènement systhétique par le biais de ce méchanisme, dans les deux cas avec
ENV{SYNTH_UUID}=="0"
.
udisks
Consultez
udisks
.
Trucs et astuces
Montage de lecteurs dans les règles
Pour monter des disques amovibles, n'appelez pas
mount
à partir des règles
udev
. Ceci est déconseillé pour deux raisons :
systemd exécute par défaut
systemd-udevd.service
avec un "espace de noms mount" séparé (consultez
namespaces(7)
), ce qui signifie que les montages ne seront pas visibles pour le reste du système.
Même si vous changez les paramètres du service pour résoudre ce problème (en commentant les lignes
PrivateMounts
et
MountFlags
), il y a un autre problème qui est que les processus démarrés depuis Udev sont tués après quelques secondes. Dans le cas des systèmes de fichiers FUSE, tels que
NTFS-3G
,
mount
démarre un processus en espace utilisateur pour gérer les internes du système de fichiers ; lorsque celui-ci est tué, vous obtiendrez des erreurs
Transport endpoint not connected
si vous essayez d'accéder au système de fichiers.
Il existe quelques options qui fonctionnent :
Démarrer un service systemd personnalisé à partir de la règle Udev ; le service systemd peut invoquer un script qui peut démarrer un nombre quelconque de processus longs (comme FUSE). Un exemple concis qui monte automatiquement les disques USB sous
/media
est
udev-media-automount
. Une variante de la même idée est expliquée dans
ce post de blog
.
Utilisez
systemd-mount
au lieu de
mount
dans votre règle Udev. Ceci est
recommandé par les développeurs de systemd
. Par exemple, cette règle Udev devrait monter les disques USB sous
/media
:
ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ENV{ID_FS_USAGE}=="filesystem", RUN{program}+="/usr/bin/systemd-mount --no-block --automount=yes --collect $devnode /media"
Utilisez un paquet comme
udisks
ou
udiskie
. Ils sont très puissants, mais difficiles à mettre en place. De plus, ils sont destinés à être utilisés dans des sessions mono-utilisateur, car ils rendent certains systèmes de fichiers disponibles sous la propriété de l'utilisateur non privilégié dont la session est actuellement active.
Permettre aux utilisateurs normaux d'utiliser les périphériques
Warning
N'appliquez pas l'étiquette
uaccess
sur des des prériphériques d'entrée ou des appareils de stockage; ceux-ci ont leur propres méthodes de controle d'accès et les utilisateurs ne devraient pas en recevoir un accès brût. Par exemple, un accès direct non-privilégié au clavier permettrait à n'importe quelle application lancée par l'utilisateur d'écouter tout ce qui est entré sur le clavier, et un accès direct non-privilégié à un disque pourrait contourner toute méthode de sécurité du système de fichier.
Lorsqu'un pilote
noyau
initialise un périphérique, l'état par défaut du nœud de périphérique est d'être la propriété de
root:root
, avec les permissions
600
.
[1]
Cela rend les périphériques inaccessibles aux utilisateurs normaux, à moins que le pilote ne modifie la valeur par défaut, ou qu'une règle udev dans l'espace utilisateur ne modifie les permissions.
Les valeurs udev
OWNER
,
GROUP
, et
MODE
peuvent être utilisées pour fournir un accès, bien que l'on rencontre le problème de savoir comment rendre un périphérique utilisable par tous les utilisateurs sans être trop permissif. L'approche d'Ubuntu consiste à créer un groupe
plugdev
auquel les périphériques sont ajoutés, mais cette pratique est non seulement déconseillée par les développeurs de systemd,
[2]
mais considérée comme un bogue lorsqu'elle est livrée dans les règles udev sur Arch (
FS#35602
).
L'approche recommandée est d'utiliser un
MODE
de
660
pour laisser le groupe utiliser le périphérique, puis d'attacher une
TAG
nommée
uaccess
. Cette balise spéciale permet à udev d'appliquer une
dynamic user ACL
au noeud du périphérique, qui se coordonne avec
systemd-logind(8)
pour rendre le périphérique utilisable par les utilisateurs connectés. Exemple de règle udev implémentant ceci :
/etc/udev/rules.d/71-device-name.rules
SUBSYSTEMS=="usb", ATTRS{idVendor}=="
vendor_id
", ATTRS{idProduct}=="
product_id
", MODE="0660", TAG+="uaccess"
Lancer des processus à long terme
Les programmes lancés par udev bloqueront les autres événements provenant de ce périphérique, et toutes les tâches créées à partir d'une règle udev seront tuées une fois le traitement des événements terminé. Si vous devez lancer un processus à long terme avec udev, la manière reccomandée est d'utiliser un service
systemd
pour lancer la commande proprement-dite, et une règle udev qui ne fait que signaler au service de se lancer. Il est toutefois découragé d'utiliser
systemctl
dans une règle udev, puisqu'il s'agit d'un outil destiné à un usage interactif qui peut entre autres se bloquer.
La bonne façon de faire est d'utiliser la règle pour marquer que l'appareil doit recevoir une unité "device" de systemd (voir
systemd.device(5)
) avec
TAG+="systemd"
et d'ajouter une propriété de soit
ENV{SYSTEMD_WANTS}+=
pour les services qui fonctionneraient normalement avec
systemctl --system
ou bien
ENV{SYSTEMD_USER_WANTS}+=
pour ceux qu'on lancerait avec
systemctl --user
. Par exemple:
SUBSYSTEM=="tty", ACTION=="add", ATTRS{manufacturer}=="Pulse-Eight", ATTRS{product}=="CEC Adapter", TAG+="systemd", ENV{SYSTEMD_WANTS}+="inputattach-cec@$devnode.service"
/etc/systemd/system/inputattach-cec@.service
[Unit]
Description=Configure une interface série USB pour %I

[Service]
Type=simple
ExecStart=/usr/bin/inputattach --pulse8-cec %I
SYSTEMD_WANTS
est équivalent à la directive
Wants=
dans les unités systemd, donc l'appareil n'est pas affecté si jamais le service plante, n'existe pas ou si sa tâche se termine correctement.
Exécution lorsque le câble HDMI est branché ou débranché
Créez la règle
/etc/udev/rules.d/95-hdmi-plug.rules
avec le contenu suivant :
ACTION=="change", SUBSYSTEM=="drm", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/
username
/.Xauthority", RUN+="
/path/to/script.sh
"
Note
Si la règle se déclenche avant le démarrage du serveur X, elle peut ne pas fonctionner comme prévu. Voir
#Les programmes graphiques dans les règles RUN se bloquent lorsqu'aucun serveur X n'est présent
.
Exécuter sur le branchement du câble VGA
Créez la règle
/etc/udev/rules.d/95-monitor-hotplug.rules
avec le contenu suivant pour lancer
arandr
lors du branchement d'un câble de moniteur VGA :
KERNEL=="card0", SUBSYSTEM=="drm", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/
username
/.Xauthority", RUN+="/usr/bin/arandr"
Certains gestionnaires d'affichage stockent le
.Xauthority
en dehors du répertoire personnel de l'utilisateur. Vous devrez mettre à jour
ENV{XAUTHORITY
} en conséquence. Par exemple,
GNOME Display Manager
se présente comme suit :
$ printenv XAUTHORITY
/run/user/1000/gdm/Xauthority
Détecter les nouveaux lecteurs eSATA
Si votre lecteur eSATA n'est pas détecté lorsque vous le branchez, vous pouvez essayer plusieurs choses. Vous pouvez redémarrer avec le eSATA branché. Ou vous pouvez essayer :
# echo 0 0 0 > /sys/class/scsi_host/host*/scan
Ou vous pouvez installer
scsiadd
AUR
(à partir de l'AUR) et essayer :
# scsiadd -s
Avec un peu de chance, votre disque est maintenant dans
/dev
. Si ce n'est pas le cas, vous pouvez essayer les commandes ci-dessus en cours d'exécution :
# udevadm monitor
pour consulter si quelque chose se passe réellement.
Marquer les ports SATA internes comme eSATA
Si vous avez connecté une baie eSATA ou un autre adaptateur eSATA, le système reconnaîtra toujours ce disque comme un lecteur SATA interne.
GNOME
et
KDE
vous demanderont en permanence votre mot de passe root. La règle suivante marquera le port SATA spécifié comme un port eSATA externe. Avec cela, un utilisateur normal de GNOME peut connecter ses disques eSATA à ce port comme une clé USB, sans mot de passe root et ainsi de suite.
/etc/udev/rules.d/10-esata.rules
DEVPATH=="/devices/pci0000:00/0000:00:1f.2/host4/*", ENV{UDISKS_SYSTEM}="0"
Note
La
DEVPATH
peut être trouvée après la connexion du lecteur eSATA avec les commandes suivantes (remplacez
sdb
en conséquence) :
$ udevadm info --query=path /dev/sdb
/devices/pci0000:00/0000:00:1f.2/host4/target4:0:0/4:0:0:0/block/sdb
$ find /sys/devices/ -name sdb
/sys/devices/pci0000:00/0000:00:1f.2/host4/target4:0:0/4:0:0:0/block/sdb
Définition de noms de périphériques statiques
Comme
udev
charge tous les modules de manière asynchrone, ils sont initialisés dans un ordre différent. Cela peut entraîner un changement aléatoire des noms des périphériques. Une règle
udev
peut être ajoutée pour utiliser des noms de périphériques statiques.
Consultez également
Nommage persistant des périphériques
pour les périphériques de type bloc et
Network configuration#Change interface name
pour les périphériques réseau.
Périphérique vidéo
Pour configurer la webcam en premier lieu, reportez-vous à
Webcam setup
.
L'utilisation de plusieurs webcams affectera les périphériques vidéo comme
/dev/video*
de manière aléatoire au démarrage. La solution recommandée est de créer des liens symboliques en utilisant une règle
udev
comme dans
#Exemple de règle udev
:
/etc/udev/rules.d/83-webcam.rules
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="05a9", ATTRS{idProduct}=="4519", SYMLINK+="video-cam1"
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="08f6", SYMLINK+="video-cam2"
Note
L'utilisation de noms autres que
/dev/video*
brisera le préchargement de
v4l1compat.so
et peut-être de
v4l2convert.so
Imprimante
Si vous utilisez plusieurs imprimantes, les périphériques
/dev/lp[0-9]
seront attribués de manière aléatoire au démarrage, ce qui perturbera par exemple la configuration de
CUPS
.
Vous pouvez créer la règle suivante, qui créera des liens symboliques sous
/dev/lp/by-id
et
/dev/lp/by-path
, de manière similaire au schéma du
nommage persistant des périphériques
:
/etc/udev/rules.d/60-persistent-printer.rules
ACTION=="remove", GOTO="persistent_printer_end"
# Ceci ne devrait pas être nécessaire
#KERNEL!="lp*", GOTO="persistent_printer_end"

SUBSYSTEMS=="usb", IMPORT{builtin}="usb_id"
ENV{ID_TYPE}!="imprimante", GOTO="persistent_printer_end"

ENV{ID_SERIAL}=="?*", SYMLINK+="lp/by-id/$env{ID_BUS}-$env{ID_SERIAL}"

IMPORT{builtin}="path_id"
ENV{ID_PATH}=="?*", SYMLINK+="lp/by-path/$env{ID_PATH}"

LABEL="persistent_printer_end"
Identifier un disque par son numéro de série
Pour effectuer une action sur un périphérique disque spécifique
/dev/sd
X
identifié de manière permanente par son numéro de série unique
ID_SERIAL_SHORT
tel qu'affiché avec
udevadm info /dev/sd
X
, on peut utiliser la règle suivante. Elle passe comme paramètre le nom du périphérique trouvé s'il y en a un pour illustrer :
/etc/udev/rules.d/69-disk.rules
ACTION=="add", KERNEL=="sd[a-z]", ENV{ID_SERIAL_SHORT}=="
X5ER1ALX
", RUN+="/path/to/script /dev/%k"
Réveil de la suspension avec un périphérique USB
Une règle udev peut être utile pour activer la fonctionnalité de réveil d'un périphérique USB, comme une souris ou un clavier, afin de pouvoir l'utiliser pour sortir la machine de la veille.
Note
Par défaut, les contrôleurs hôtes USB sont tous activés pour le réveil. L'état peut être vérifié en utilisant
cat /proc/acpi/wakeup
. La règle ci-dessous n'est dans ce cas pas nécessaire mais peut être utilisée comme modèle pour effectuer d'autres actions, comme la désactivation de la fonctionnalité de réveil par exemple.
Tout d'abord, identifiez les identifiants du fournisseur et du produit du périphérique USB. Ils seront utilisés pour le reconnaître dans la règle udev. Par exemple :
$ lsusb | grep Logitech
Bus 007 Device 002: ID
046d
:
c52b
Logitech, Inc. Unifying Receiver
Ensuite, trouvez l'endroit où le périphérique est connecté en utilisant :
$ grep
c52b
/sys/bus/usb/devices/*/idProduct
/sys/bus/usb/devices/
1-1.1.1.4/
idProduct:c52b
Créez maintenant la règle pour modifier l'attribut
power/wakeup
du périphérique et du contrôleur USB auquel il est connecté à chaque fois qu'il est ajouté :
/etc/udev/rules.d/50-wake-on-device.rules
ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="
046d
", ATTRS{idProduct}=="
c52b
", ATTR{power/wakeup}="enabled", ATTR{driver/
1-1.1.1.4
/power/wakeup}="enabled"
Forcer les fonctionnalités d'un appareil USB à être réinitialisées en sortie de veille
Les appareils USB doivent être réinitialisés après avoir été suspendus (soit parce que le système sort de veille ou parce que le port a été éteint pour conserver de l'énergie quand l'appareil est devenu inactif), chose que le noyau Linux gère
de façon généralement transparente
avec une procédure nommée
reset-resume
, pour que les appareils USB ne se comportent pas comme s'ils avaient été déconnectés puis reconnectés à chaque fois. C'est habituellement ce qu'on recharche, mais certains appareils comme les interfaces USB qui se comportent en port série, ont bel et bien besoin d'être reconfigurées lorsqu'on les rallume, ce qui n'est pas signallé par les pilotes en charge de ces appareils.
Il y a toutefois un évènement qui survient dans ces conditions, et c'est celui qui indique que l'appareil a pertu et regagné la capacité de sortir le système de veille, puisqu'un appareil USB est inutilisable lorsqu'il est en attende d'être configuré et ne pourrait pas réveiller le système dans cet état. Ces deux évènements n'ont pas de propriétés uniques permettant de les distinguer, mais le permier peut quand-même être identifié facilement car
DEVNUM
est mis à zéro (alors que ce n'est pas pas un numéro d'appareil valide)
juste avant
que l'appareil soit déconfiguré et ne perde
power/wakeup
, ce qui fait survenir l'évènement. Lorsque cela se produit, on peut simplement assigner à l'attribut sysfs
bConfigurationValue
la même valeur qu'il avait déjà pour
forcer le système à reconfigurer
l'appareil de manière
non transparante
, comme s'il avait été déconnecté durant la veille, ce qui dissocie tous les pilotes et enlève tous les périphériques en aval avant des les rajouter quand l'appareil est à nouveau prêt.
# La règle qu'on cherche vraiment à faire fonctionner
ACTION=="add" SUBSYSTEM=="tty" SUBSYSTEMS="usb" ATTRS{manufacturer}=="Machin" ATTRS{product}=="Toto" TAG+="systemd" ENV{SYSTEMD_WANTS}="setup-usb-tty@$devnode.service"

# Une seconde règle pour relancer la règle plus haut en sortie de veille.
# On ne peut pas utiliser $attr{bConfigurationValue} dans la directive ATTR{},
# donc assurez-vous de changer "1" aux deux endroits par le numéro de configuration
# utilisé par l'appareil quand il est fonctionnel
ACTION=="change" SUBSYSTEM=="usb" ENV{DEVNUM}=="000" ATTR{manufacturer}=="Machin" ATTR{product}=="Toto" ATTR{bConfigurationValue}=="1" ATTR{bConfigurationValue}="1"
Déclenchement d'événements
Il peut être utile de déclencher divers événements
udev
. Par exemple, vous pourriez vouloir simuler la déconnexion d'un périphérique USB sur une machine distante. Dans ce cas, utilisez
udevadm trigger
:
# udevadm trigger --verbose --type=subsystems --action=remove --subsystem-match=usb --attr-match="idVendor=abcd"
Cette commande déclenchera un événement de suppression USB sur tous les périphériques USB avec l'ID du fournisseur
abcd
.
Dépannage
Liste noire de modules
Dans de rares cas,
udev
peut faire des erreurs et charger les mauvais modules. Pour l'empêcher de le faire, vous pouvez
mettre sur liste noire
les modules. Une fois mis sur liste noire,
udev
ne chargera jamais ce module - ni au démarrage, ni plus tard lorsqu'un événement hot-plug est reçu (par exemple, lorsque vous branchez votre clé USB).
Sortie de débogage
Pour obtenir des informations sur le matériel
débogage
, utilisez le
paramètre du noyau
udev.log-priority=debug
. Vous pouvez également définir
/etc/udev/udev.conf
udev_log="debug"
Cette option peut également être compilée dans votre initramfs en ajoutant le fichier de configuration à votre tableau
FILES
/etc/mkinitcpio.conf
FILES="... /etc/udev/udev.conf"
et ensuite
régénérez l'initramfs
.
udevd se bloque au démarrage
Après la migration vers LDAP ou la mise à jour d'un système basé sur LDAP,
udevd
peut se bloquer au démarrage avec le message "Starting UDev Daemon". Cela est généralement dû au fait que
udevd
essaie de rechercher un nom dans LDAP mais échoue, car le réseau n'est pas encore opérationnel. La solution est de s'assurer que tous les noms de groupes du système sont présents localement.
Extrayez les noms de groupes référencés dans les règles de
udev
et les noms de groupes réellement présents sur le système :
# grep -Fr GROUP /etc/udev/rules.d/ /usr/lib/udev/rules.d/ | sed 's :.*GROUP="\([-a-z_]\{1,\}\)".*:\1:' | sort -u >udev_groups
# cut -d : -f1 /etc/gshadow /etc/group | sort -u >present_groups
Pour consulter les différences, faites une comparaison côte à côte :
# diff -y present_groups udev_groups
...
network <
nobody <
ntp <
optique optique
puissance < pcscd
rfkill <
root root
scanner scanner
smmsp <
stockage stockage
...
Dans ce cas, le groupe
pcscd
est pour une raison quelconque absent du système.
Ajouter les groupes manquants
. Assurez-vous également que les ressources locales sont recherchées avant de recourir à LDAP.
/etc/nsswitch.conf
devrait contenir la ligne suivante :
group : files ldap
Certains périphériques, qui devraient être traités comme amovibles, ne le sont pas
Vous devez créer une règle
udev
personnalisée pour ce périphérique particulier. Pour obtenir des informations définitives sur le périphérique, vous pouvez utiliser soit
ID_SERIAL
, soit
ID_SERIAL_SHORT
. (n'oubliez pas de modifier
/dev/sdb
si nécessaire) :
$ udevadm info /dev/sdb | grep ID_SERIAL
Ensuite, définissez
UDISKS_AUTO="1"
pour marquer le périphérique pour le montage automatique et
UDISKS_SYSTEM="0"
pour marquer le périphérique comme "amovible". Consultez
udisks(8)
pour plus de détails.
/etc/udev/rules.d/99-removable.rules
ENV{ID_SERIAL_SHORT}== "
serial_number
", ENV{UDISKS_AUTO}="1", ENV{UDISKS_SYSTEM}="0"
N'oubliez pas de recharger les règles
udev
avec
udevadm control --reload
. La prochaine fois que vous brancherez votre périphérique, il sera traité comme un disque externe.
Problèmes de son avec certains modules non chargés automatiquement
Certains utilisateurs ont attribué ce problème à d'anciennes entrées dans
/etc/modprobe.d/sound.conf
. Essayez de nettoyer ce fichier et réessayez.
Note
Depuis
udev>=171
, les modules d'émulation OSS (
snd_seq_oss
,
snd_pcm_oss
,
snd_mixer_oss
) ne sont pas chargés automatiquement par défaut.
Prise en charge des lecteurs de CD/DVD IDE
À partir de la version 170,
udev
ne prend pas en charge les lecteurs de CD-ROM/DVD-ROM qui sont chargés comme des lecteurs IDE traditionnels avec le module
ide_cd_mod
et qui apparaissent sous la forme
/dev/hd*
. Le lecteur reste utilisable pour les outils qui accèdent directement au matériel, comme
cdparanoia
, mais est invisible pour les programmes supérieurs en espace utilisateur, comme KDE.
Une cause pour le chargement du module ide_cd_mod avant les autres, comme sr_mod, pourrait être par exemple que vous avez pour une raison quelconque le module piix chargé avec votre
initramfs
. Dans ce cas, vous pouvez simplement le remplacer par ata_piix dans votre
/etc/mkinitcpio.conf
.
Les lecteurs optiques ont un ID de groupe défini sur "disk"
Si l'ID de groupe de votre lecteur optique est défini sur
disk
et que vous souhaitez qu'il soit défini sur
optical
, vous devez créer une règle
udev
personnalisée :
/etc/udev/rules.d
# Permissions pour les périphériques CD IDE
SUBSYSTEMS=="ide", KERNEL=="hd[a-z]", ATTR{removable}=="1", ATTRS{media}=="cdrom*", GROUP="optical"

# permissions pour les périphériques CD SCSI
SUBSYSTEMS=="scsi", KERNEL=="s[rg][0-9]*", ATTRS{type}=="5", GROUP="optical"
Les programmes graphiques dans les règles RUN se bloquent lorsqu'aucun serveur X n'est présent
Lorsque
xrandr
ou un autre programme basé sur X tente de se connecter à un serveur X, il se rabat sur une connexion TCP en cas d'échec. Cependant, à cause de
IPAddressDeny
dans la
systemd-udev service configuration
, cela se bloque. Finalement, le programme sera tué et le traitement des événements reprendra.
Si la règle est destinée à un périphérique drm et que le blocage entraîne la fin du traitement des événements après le démarrage du serveur X, l'accélération 3D peut cesser de fonctionner avec une erreur
failed to authenticate magic
.
Voir aussi
udev(7)
Une introduction à udev
Informations sur la liste de diffusion d'udev
Scripting with udev
(en anglais)
Écriture de règles udev
Gestion des périphériques et modules sur un système LFS
Exécution de l'interface graphique ou accès aux variables d'affichage à partir des règles udev