systemd d'aujourd'hui lit sa configuration d'initialisation pour chaque démon à partir d'une collection de fichiers unitaires , souvent appelées simplement unités . Avec unités de chemin , vous pouvez surveiller les fichiers et les répertoires pour certains événements. Si un événement spécifié se produit, une unité de service est exécuté et il porte généralement le même nom que l'unité de chemin. Je vais montrer comment cela fonctionne avec un exemple simple.
Supposons que nous voudrions surveiller un fichier. Chaque fois que le fichier est fermé après une écriture, un script spécifique doit démarrer.
L'unité de chemin :example.path
Dans le répertoire /etc/systemd/system/ nous créons le fichier example.path avec le contenu suivant :
[Unit]
Description=Monitor the file for changes
[Path]
PathChanged=/home/john/testfile
Unit=example.service
[Install]
WantedBy=multi-user.target
Dans le [Path] section, PathChanged= spécifie le chemin absolu vers le fichier à surveiller, tandis que Unit= indique quelle unité de service exécuter si le fichier change. Cette unité (example.path ) doit être lancé lorsque le système est en mode multi-utilisateurs.
Ensuite, nous créons l'unité de service correspondante example.service dans /etc/systemd/system/ .
L'unité de service :example.service
Si le fichier testfile modifications (ce qui signifie qu'il est à la fois écrit et fermé), l'unité de service suivante sera appelée pour exécuter le script spécifié :
[Unit]
Description=Executes script when a file has changed.
[Service]
Type=simple
ExecStart=/home/john/script.sh
[Install]
WantedBy=multi-user.target
Dans cet exemple, le fichier script.sh contient uniquement le code suivant :
#!/bin/bash
echo "file changed" >/home/john/output.txt
Pour tester l'unité de chemin, ces deux nouvelles unités doivent être activées, alors exécutez :
$ sudo systemctl enable example.{path,service}
$ sudo systemctl start example.path
Si vous réécrivez ou écrivez dans le fichier testfile , l'unité de service correspondante est exécutée, et le fichier output.txt est créé dans l'utilisateur john répertoire personnel de.
La liste incomplète et non exhaustive suivante donne quelques exemples où les unités de chemin pourraient rendre votre Sysadmin Day un peu plus facile :
- Démarrez le traitement des données basé sur les événements.
- Surveiller les fichiers sous
/etc, et envoyer une notification en cas de modification. - Surveiller l'
importdossier pour les nouveaux fichiers, et commencez le traitement.
Éléments à connaître
Lors de mes tests avec les unités de chemin, j'ai remarqué que tous les événements ne sont pas capturés dans certaines circonstances. Par exemple, configurez une unité de chemin pour surveiller les modifications d'un chemin, puis exécutez la commande suivante :
$ touch /path/file && rm /path/file
Je m'attendrais à ce que l'unité de service soit exécutée deux fois, ici :la première fois pour le touch commande, et la seconde fois pour le rm commande. J'ai rempli un rapport Bugzilla pour voir si ce problème est dû à la conception ou à un problème qui peut être corrigé.
Sources et liens connexes
Si vous souhaitez en savoir plus sur systemd unités, y compris les unités de chemin et de service, consultez les pages de manuel suivantes :
- systemd.unit (5)
- systemd.path (5)
- systemd.service (5)
De plus, si vous êtes intéressé par les résultats de mon rapport de bogue, vous pouvez le suivre ici :
Bogue 1722627 - L'unité de chemin n'attrape pas tous les événements