Linux : corriger failed to execute /hal/udev_event

Après une mise à jour Linux ou sur une vieille installation, vous pouvez tomber sur une erreur de ce type dans les logs :

failed to execute '/hal/udev_event'Code language: JavaScript (javascript)

Ou une variante plus longue :

systemd-udevd: failed to execute '/lib/udev/socket:@/org/freedesktop/hal/udev_event'Code language: JavaScript (javascript)

Ce message indique qu’une règle ou un composant udev tente encore d’appeler HAL, l’ancien Hardware Abstraction Layer. Sur une distribution moderne, c’est généralement un reliquat historique. Un vieux fantôme dans la tuyauterie matérielle.

La correction consiste à identifier ce qui appelle encore HAL, puis à supprimer le paquet ou la règle obsolète. Il ne faut pas bricoler udev au hasard : c’est lui qui gère une bonne partie de la détection matérielle du système.

Kinsta: Premium Managed WordPress hosting

HAL, c’était quoi ?

HAL, pour Hardware Abstraction Layer, était une ancienne couche permettant aux applications de découvrir et d’utiliser le matériel : disques, périphériques amovibles, batteries, boutons, lecteurs optiques, cartes réseau et autres composants.

À l’époque, HAL servait d’intermédiaire entre le noyau Linux, les périphériques et les applications de bureau. Mais son architecture monolithique a progressivement été remplacée par des outils plus spécialisés.

Aujourd’hui, sur la plupart des distributions Linux, la détection dynamique des périphériques passe par udev, souvent intégré à systemd via systemd-udevd.

udev, c’est quoi ?

udev reçoit les événements du noyau quand un périphérique est ajouté, retiré ou modifié. Il applique ensuite des règles pour créer des nœuds dans /dev, définir des permissions, créer des liens symboliques ou déclencher certaines actions.

Exemples d’événements gérés par udev :

branchement d’une clé USB ;
apparition d’un disque externe ;
détection d’une carte réseau ;
ajout d’un périphérique série ;
création d’un lien stable vers un périphérique ;
attribution de permissions à un périphérique précis.

Sur les systèmes utilisant systemd, le service concerné est généralement :

systemd-udevd.serviceCode language: CSS (css)

Vous pouvez vérifier son état avec :

systemctl status systemd-udevd --no-pager

BigScoots: Premium WordPress and WooCommerce hosting

Pourquoi cette erreur apparaît encore ?

L’erreur failed to execute /hal/udev_event apparaît généralement quand une ancienne règle udev ou un vieux paquet tente encore de notifier HAL lors d’un événement matériel.

Les causes les plus fréquentes :

ancienne installation mise à jour plusieurs fois ;
paquet hal encore installé ;
ancienne règle udev laissée dans /etc/udev/rules.d/ ;
paquet tiers qui installe encore des règles historiques ;
migration incomplète depuis un vieux système ;
copie manuelle d’anciennes règles udev depuis un autre serveur.

Sur une installation fraîche d’une distribution moderne, cette erreur ne devrait normalement pas apparaître.

Le plus lu : Créer un enregistrement BIMI pour afficher votre logo dans vos emails clients et prospects

Étape 1 : lire les logs udev

Commencez par lire les logs du service udev :

journalctl -u systemd-udevd -b --no-pager

Pour suivre les événements en direct :

journalctl -u systemd-udevd -f

Si votre distribution envoie aussi des messages dans le journal noyau, vérifiez :

dmesg -T | grep -i udev

Vous pouvez aussi chercher directement les traces HAL :

journalctl -b --no-pager | grep -i hal

Cette première étape permet de confirmer que l’erreur vient bien d’un appel à HAL, et pas d’une autre règle udev cassée.

Étape 2 : vérifier si HAL est installé

Sur Debian, Ubuntu ou dérivées, vérifiez si le paquet hal est encore présent :

dpkg -l | grep -E '^ii\s+hal\s'Code language: JavaScript (javascript)

Vous pouvez aussi utiliser :

apt policy hal

Si HAL est installé sur une distribution moderne, il y a de fortes chances qu’il soit inutile, sauf cas très spécifique lié à une vieille application.

Pour le supprimer :

sudo apt remove hal

Puis nettoyez les dépendances devenues inutiles :

sudo apt autoremove

Redémarrez ensuite, ou rechargez udev si vous voulez tester sans redémarrer.

Étape 3 : chercher les anciennes règles udev liées à HAL

Si le paquet hal n’est pas installé, une règle udev ancienne peut encore contenir une référence à HAL.

Cherchez les références dans les règles système et locales :

grep -RIn "hal" /etc/udev/rules.d /lib/udev/rules.d /usr/lib/udev/rules.d 2>/dev/nullCode language: JavaScript (javascript)

Selon la distribution, les règles udev peuvent se trouver dans :

/etc/udev/rules.d/ pour les règles locales ;
/lib/udev/rules.d/ sur certaines distributions ;
/usr/lib/udev/rules.d/ sur d’autres systèmes.

Si une règle locale dans /etc/udev/rules.d/ appelle encore /hal/udev_event, vérifiez d’abord pourquoi elle existe. Si elle vient d’un ancien bricolage ou d’un vieux paquet supprimé, archivez-la puis retirez-la.

Par exemple :

sudo mkdir -p /root/udev-rules-backup
sudo mv /etc/udev/rules.d/99-old-hal.rules /root/udev-rules-backup/

Adaptez évidemment le nom du fichier à votre cas. Ne copiez-collez pas ce chemin comme si votre serveur avait la même vie sentimentale que le mien.

Étape 4 : recharger les règles udev

Après modification des règles, demandez à udev de les recharger :

sudo udevadm control --reload-rules

Puis déclenchez à nouveau les règles si nécessaire :

sudo udevadm trigger

Sur un serveur en production, utilisez udevadm trigger avec prudence. Cela peut relancer beaucoup d’événements udev. Si le problème n’est pas urgent, un redémarrage planifié peut être plus propre.

Le plus lu : Redémarrer la machine virtuelle de Local by Flywheel

Étape 5 : tester les événements udev en direct

Pour voir ce que le noyau et udev reçoivent lors du branchement d’un périphérique :

udevadm monitor

Pour afficher aussi les propriétés d’environnement :

udevadm monitor --environment

Branchez ensuite le périphérique concerné, puis observez les événements. Cette commande est très utile pour distinguer un vrai problème udev d’un vieux message sans conséquence.

Cas moderne : une règle udev exécute un script qui échoue

L’erreur historique liée à HAL n’est pas la seule forme possible de failed to execute. Aujourd’hui, le problème vient souvent d’une règle udev personnalisée qui lance un script introuvable, non exécutable ou mal écrit.

Exemple de règle fragile :

ACTION=="add", SUBSYSTEM=="usb", RUN+="script.sh"Code language: JavaScript (javascript)

Le problème : udev n’utilise pas votre shell interactif, votre PATH, votre session graphique ou vos variables utilisateur. Utilisez des chemins absolus.

Version plus propre :

ACTION=="add", SUBSYSTEM=="usb", RUN+="/usr/local/bin/mon-script-udev.sh"Code language: JavaScript (javascript)

Le script doit être exécutable :

sudo chmod 0755 /usr/local/bin/mon-script-udev.sh

Et commencer par un shebang correct :

#!/usr/bin/env bashCode language: JavaScript (javascript)

ou, si vous voulez rester POSIX :

#!/bin/shCode language: JavaScript (javascript)

Tester une règle udev sans tout casser

Pour tester les règles appliquées à un périphérique, commencez par identifier son chemin udev.

Exemple avec un périphérique bloc :

udevadm info --query=path --name=/dev/sdbCode language: JavaScript (javascript)

Puis testez les règles :

udevadm test /sys/block/sdb

Adaptez le chemin à votre périphérique. La commande udevadm test est utile pour le diagnostic, mais elle ne reproduit pas toujours exactement toutes les conditions d’un événement réel.

Ne lancez pas de tâches longues directement dans udev

Les règles udev doivent rester rapides. Elles ne sont pas faites pour lancer des traitements longs, monter des systèmes de fichiers complexes, démarrer des interfaces graphiques ou exécuter des scripts réseau lourds.

Pour une action plus complexe, déclenchez plutôt un service systemd depuis udev.

Exemple de règle udev :

ACTION=="add", SUBSYSTEM=="block", TAG+="systemd", ENV{SYSTEMD_WANTS}+="mon-traitement.service"Code language: JavaScript (javascript)

Exemple de service systemd :

[Unit]
Description=Traitement déclenché par udev

[Service]
Type=oneshot
ExecStart=/usr/local/bin/mon-traitement.shCode language: JavaScript (javascript)

C’est plus propre, plus observable, et plus facile à déboguer avec journalctl.

Commandes utiles pour diagnostiquer udev

État du service udev :

systemctl status systemd-udevd --no-pager

Logs udev depuis le dernier démarrage :

journalctl -u systemd-udevd -b --no-pager

Suivi en direct :

journalctl -u systemd-udevd -f

Recherche de références à HAL :

grep -RIn "hal" /etc/udev/rules.d /lib/udev/rules.d /usr/lib/udev/rules.d 2>/dev/nullCode language: JavaScript (javascript)

Rechargement des règles :

sudo udevadm control --reload-rules

Déclenchement manuel :

sudo udevadm trigger

Surveillance des événements :

udevadm monitor --environment

Faut-il redémarrer après suppression de HAL ?

Après suppression du paquet hal ou retrait d’une ancienne règle udev, vous pouvez recharger les règles et tester. Mais si l’erreur apparaissait au démarrage, un redémarrage reste le test le plus clair.

sudo reboot

Après redémarrage, vérifiez que l’erreur a disparu :

journalctl -b --no-pager | grep -i "hal\|udev_event"Code language: JavaScript (javascript)

Si la commande ne retourne rien, le vieux crochet HAL a probablement disparu.

Le plus lu : Optimisation du thème WordPress : 30 requêtes SQL gagnées

Checklist de correction

Confirmez l’erreur exacte dans journalctl.
Vérifiez si le paquet hal est encore installé.
Supprimez HAL s’il n’est plus nécessaire.
Cherchez les anciennes règles contenant hal.
Archivez puis retirez les règles locales obsolètes.
Rechargez les règles avec udevadm control --reload-rules.
Utilisez udevadm monitor --environment pour observer les événements.
Pour les scripts udev modernes, utilisez toujours des chemins absolus.
Pour les actions longues, déclenchez un service systemd plutôt qu’un gros script dans udev.

À retenir

L’erreur failed to execute /hal/udev_event vient presque toujours d’un reliquat HAL sur une installation ancienne ou mise à jour plusieurs fois.

Sur un système moderne, HAL n’est généralement plus nécessaire. Supprimez le paquet s’il est encore installé, cherchez les anciennes règles udev qui l’appellent, puis rechargez les règles udev.

Pour les erreurs udev actuelles, raisonnez différemment : vérifiez les chemins absolus, les permissions, les scripts, les logs systemd-udevd et utilisez systemd pour les tâches longues. udev doit réagir vite. Il n’est pas là pour lancer une symphonie shell au branchement d’une clé USB.