Linux : services systemd, timers et règles udev

La douane écrit pour la troisième fois : plus aucune déclaration n'est arrivée au guichet unique depuis trois jours, et des conteneurs sont bloqués au port. Le même matin, le chef de quai signale que l'étiqueteuse n'imprime plus rien depuis que le poste a été rebranché. Au lab 1, vous aviez rangé le script de collecte dans la colonne des risques : lancé au démarrage par cron, détaché par nohup, sa sortie jetée dans /dev/null. Le risque s'est réalisé. Vous commencez par l'enquête : le journal qui s'arrête sans un mot, l'onduleur qui révèle que seules les coupures de courant relançaient la collecte, puis le script lancé à la main qui meurt sous vos yeux au premier refus du guichet. Avant de toucher à quoi que ce soit, vous mettez la configuration sous Git. Vous confiez ensuite la collecte à systemd : une unité qui la relance sans s'épuiser, sous son propre compte, avec une mémoire bornée et un journal où plus rien ne se perd. Le récapitulatif de nuit, que cron oubliait les nuits de coupure, devient un timer qui rattrape les passages manqués. Reste la douchette. Le noyau numérote les appareils dans l'ordre où ils arrivent, et le logiciel d'étiquetage écoute désormais le clavier. Vous lisez ce que le noyau et udev savent d'un appareil, vous croisez les modules qui le pilotent, et vous écrivez la règle udev qui le nomme par ce qu'il est, pas par son rang d'arrivée. Pour finir, un collègue « simplifie » la configuration un vendredi soir, et Git vous dit en dix secondes ce qui a changé. Le guichet des douanes et le matériel du quai sont simulés sur la machine, et se comportent comme les vrais. À la fin, l'état du serveur et votre historique Git sont vérifiés, et le résultat compte pour votre classement.