systemd-run : lancer des tâches ponctuelles avec limites et journalisation
Utilisez systemd-run pour isoler une tâche ponctuelle, limiter ses ressources, suivre ses logs et éviter les scripts shell fragiles.
systemd-run lance une commande ponctuelle comme une unité systemd transitoire, avec un nom, des journaux et des limites. Utilisez-le pour des tâches non interactives d’import, de maintenance ou de nettoyage ; choisissez plutôt un fichier .service ou un timer si l’exécution devient régulière.
Lancer et suivre la tâche
Par défaut, systemd-run crée un service transitoire et rend la main après son démarrage. Ajoutez --wait si vous devez attendre la fin de la tâche et récupérer son résultat ; donnez un nom distinct à chaque opération importante pour éviter tout conflit avec une unité encore active.
sudo systemd-run --unit=import-clients-20260930 --wait /usr/local/bin/import-clients /srv/inbox/clients.csv
Le suffixe .service est ajouté automatiquement. Consultez ensuite l’état et les journaux sur la machine qui exécute la tâche :
sudo systemctl status import-clients-20260930.service
sudo journalctl -u import-clients-20260930.service
--scope rattache le processus à un cgroup tout en le laissant enfant du client qui lance la commande ; pour une tâche d’administration classique, le mode service par défaut est généralement plus simple. --user cible le gestionnaire systemd de l’utilisateur courant ; utilisez le gestionnaire système avec les privilèges nécessaires pour les répertoires ou services système.
Limiter les ressources et les accès
Ajoutez les propriétés avec --property ou -p. Pour une commande lourde, les plus utiles sont CPUQuota=, MemoryMax= et RuntimeMaxSec= :
sudo systemd-run --unit=import-limite --wait -p CPUQuota=150% -p MemoryMax=2G -p RuntimeMaxSec=45min /usr/local/bin/import-clients /srv/inbox/clients.csv
CPUQuota=100% correspond à la capacité d’un cœur logique ; 150 % autorise donc davantage qu’un cœur, dans la limite de ce quota moyen. L’application effective dépend des contrôleurs cgroup disponibles : vérifiez le comportement sur l’hôte réel, notamment en machine virtuelle, conteneur ou distribution ancienne.
Une durée maximale évite qu’une tâche bloquée se poursuive indéfiniment, mais ne rend pas l’opération sûre à elle seule. Le programme doit supporter une interruption ; consultez le journal après un arrêt forcé.
Pour restreindre les écritures, combinez ProtectSystem=strict avec ReadWritePaths= pour le seul répertoire nécessaire. PrivateTmp=yes isole les fichiers temporaires et NoNewPrivileges=yes empêche l’acquisition de privilèges supplémentaires ; ces protections doivent rester compatibles avec le programme et ne remplacent ni la validation des arguments ni les permissions Linux.
Exemple de nettoyage contrôlé
Exécutez d’abord find sans -delete pour vérifier les fichiers sélectionnés. Une fois le périmètre validé, limitez les écritures au répertoire visé :
sudo systemd-run --unit=purge-uploads --wait -p ProtectSystem=strict -p ReadWritePaths=/srv/uploads -p PrivateTmp=yes -p NoNewPrivileges=yes -p RuntimeMaxSec=20min /usr/bin/find /srv/uploads -xdev -type f -mtime +30 -delete
-xdev évite de descendre dans un éventuel système de fichiers monté sous le répertoire ciblé. Validez néanmoins le chemin absolu, la rétention choisie et les droits du compte qui lance l’opération.
Les options et propriétés disponibles sont documentées dans les pages de manuel de systemd-run et de systemd.resource-control.