Sujet : systemd
-
cgroups v2 sur l'hôte : vérifier le mode et lire les limites de ressources par unité
Les runtimes de conteneurs modernes et systemd s'appuient sur cgroups v2 (la hiérarchie unifiée) pour appliquer des limites de mémoire et de CPU. Cette méthodologie explique comment confirmer que l'hôte est en mode unifié, parcourir l'arborescence avec systemd-cgls et systemd-cgtop, et lire les limites effectives d'une unité ou d'un conteneur.
-
Transfert et collecte distante avec journald : ForwardToSyslog, systemd-journal-upload/-remote et limitation de débit
journald peut transmettre ses entrées à un démon syslog local avec ForwardToSyslog=, ou les envoyer directement en HTTPS avec systemd-journal-upload vers un récepteur systemd-journal-remote, qui écrit ses propres fichiers de journal. Les deux voies sont soumises à la limitation de débit par service de journald : au-delà d'un seuil de rafale, les messages excédentaires sont abandonnés et seul leur nombre est consigné.
-
Timers systemd en remplacement de cron : OnCalendar, Persistent= et RandomizedDelaySec
Une unité systemd .timer associée à un service .service de type oneshot peut remplacer une entrée crontab, tout en ajoutant le rattrapage des exécutions manquées après une indisponibilité et un décalage aléatoire au sein d'un parc de machines. Cette méthodologie décrit l'écriture, la validation et l'activation d'une telle paire, et explique ce que font réellement Persistent= et RandomizedDelaySec=.
-
« Too many open files » (EMFILE) et la limite de descripteurs de fichiers
EMFILE, signalé par « Too many open files », indique qu'un processus a atteint sa propre limite de descripteurs de fichiers ouverts simultanément, documentée sous le nom RLIMIT_NOFILE. L'article explique comment distinguer une vraie fuite de descripteurs d'une limite simplement trop basse, et comment la relever au niveau du shell, de PAM et de l'unité systemd.
-
Dialectes d'analyse des fichiers .env : guillemets, export, valeurs multilignes et expansion dans cinq chargeurs
Docker Compose, docker run --env-file, python-dotenv, le dotenv de Node, EnvironmentFile de systemd et le sourcing du fichier dans un shell acceptent des fichiers d'apparence semblable, mais divergent sur les guillemets, le mot-clé export, les valeurs multilignes et l'expansion de ${VAR}.
-
Exécuter des conteneurs Podman comme services systemd avec Quadlet
Quadlet permet à systemd de gérer directement des conteneurs Podman à partir de fichiers d'unité déclaratifs .container, en remplacement du workflow obsolète podman generate systemd. Cette méthodologie couvre les emplacements de fichiers pour les services système et utilisateur, l'activation et le label de mise à jour automatique.
-
La chaîne de démarrage Linux pour le dépannage : firmware, chargeur d'amorçage, noyau, initramfs et systemd
Un démarrage Linux traverse le firmware, un chargeur d'amorçage, le noyau, un initramfs puis le gestionnaire système, chaque étape passant la main à la suivante. Savoir ce que fait chaque étape et où elle journalise permet de circonscrire un échec de démarrage à une seule étape avant de modifier quoi que ce soit.
-
Tâches planifiées comparées : cron, timers systemd, launchd, Planificateur de tâches Windows et cron/at sous AIX
Chaque planificateur répond différemment à une même question : que devient une tâche dont l'heure prévue est passée alors que la machine était éteinte ou en veille ? La comparaison de cron, des timers systemd, des clés de calendrier de launchd et du Planificateur de tâches Windows montre que seul launchd rattrape par défaut après une veille ; les autres ne le font que s'ils sont configurés en ce sens.
-
rescue.target et emergency.target de systemd : y accéder et revenir à un fonctionnement normal
rescue.target démarre le système de base et un shell mono-utilisateur ; emergency.target ignore presque tout et lance un shell sur la console, le système de fichiers racine pouvant encore être en lecture seule. On accède aux deux via le paramètre noyau systemd.unit=, et dans les deux cas il faut ensuite revenir explicitement à default.target.
-
Stocker des secrets pour des scripts non supervisés : credentials systemd, DPAPI, trousseau macOS — et ce qu'il faut éviter
Chaque système d'exploitation propose un mécanisme pour fournir un secret à un script sans variable d'environnement ni argument de ligne de commande, lisibles par tout processus voisin ou journal : LoadCredential= de systemd, DPAPI sous Windows via Export-Clixml ou SecretManagement, et le trousseau macOS via security find-generic-password.
-
Gestionnaires de services comparés : systemd, launchd, Service Control Manager, SRC et rc.d/OpenRC
Tout système d'exploitation généraliste dispose d'un composant qui démarre, arrête, supervise et relance les services au boot, mais les commandes et le modèle de persistance diffèrent. Cette référence met en correspondance démarrage, arrêt, statut, activation au boot et accès aux journaux pour systemd, launchd, le Service Control Manager de Windows, le SRC d'AIX, ainsi que rc.d de FreeBSD et OpenRC d'Alpine.
-
Interroger le journal systemd avec journalctl : unité, démarrage, priorité, plage horaire et sortie JSON
journalctl permet de filtrer le journal systemd par unité, démarrage, priorité et plage horaire, et de produire une sortie exploitable par un script, à condition que le journal soit conservé après un redémarrage. Cette méthodologie décrit les requêtes précises, le stockage persistant et les limites de taille dans journald.conf.
-
Identifier un hôte Linux inconnu avant d'y modifier quoi que ce soit
Avant de modifier la configuration d'une machine Linux qu'il n'a pas installée, un agent ou un opérateur devrait établir la distribution, le noyau, l'état de virtualisation ou de conteneur, le système d'init, le gestionnaire de paquets et l'état du contrôle d'accès obligatoire, chacun avec une commande simple et non destructive.
-
Modifier /etc/fstab en toute sécurité : UUID, nofail, options x-systemd et findmnt --verify
Une ligne erronée dans /etc/fstab peut faire basculer le système dans un shell d'urgence au démarrage suivant. Cette méthode recourt à UUID= plutôt qu'aux noms de périphériques, à nofail et x-systemd.device-timeout= pour les montages facultatifs, puis à findmnt --verify et mount -a pour tester le fichier avant de redémarrer.
-
Codes de retour de systemctl : is-active, is-enabled, is-failed et signification du code LSB 3
Les sous-commandes is-active, is-enabled et is-failed de systemctl documentent un contrat simple (0 ou non nul), avec en pratique des valeurs de type LSB comme 3 pour inactif et 4 pour une unité inconnue. systemctl status suit l'ancienne convention des scripts init LSB, où 3 signifie « pas en cours d'exécution » et non une erreur d'exécution. Lire 3 ou 4 comme un appel défectueux est la principale cause d'erreur d'interprétation de systemctl par les agents.
-
Chaînes de durée et d'intervalle : ISO 8601, ParseDuration de Go, systemd, Prometheus, PostgreSQL et TimeSpan de .NET
PT1H30M, 1h30m, « 1h 30min » et 01:30:00 peuvent désigner la même durée, mais chaque analyseur accepte un jeu différent de suffixes d'unité et rejette tout le reste : une chaîne de durée copiée d'un système à l'autre échoue donc souvent tout simplement à l'analyse.
-
Lire la pression mémoire sous Linux : free, swap, OOM killer et OOMScoreAdjust
Le chiffre qui indique la marge mémoire réelle est la colonne « available » de free, et non « free » ; un processus tué sous pression mémoire laisse une trace dans le journal du noyau ou dans le journal systemd, il ne disparaît pas silencieusement. Cet article explique quoi lire et comment influencer le choix de l'OOM killer.
-
Diagnostiquer la résolution de noms sur un hôte systemd : resolvectl, resolv.conf, nsswitch et getent face à dig
Sur un hôte avec systemd-resolved, /etc/resolv.conf ne fait généralement que pointer vers un écouteur stub local, les vrais serveurs DNS par lien se trouvent dans resolvectl, et /etc/nsswitch.conf détermine si getent hosts interroge le DNS ou non. Confondre ces couches explique la plupart des cas où « dig fonctionne mais pas l'application ».
-
Définir des paramètres du noyau Linux avec sysctl : modifications à chaud ou via /etc/sysctl.d
`sysctl -w` modifie un paramètre du noyau jusqu'au prochain redémarrage ; pour le rendre persistant, il faut déposer un fichier dans /etc/sysctl.d/ et comprendre l'ordre de chargement entre /usr/lib, /etc et /run. `sysctl --system` applique tous les fichiers configurés et indique lequel l'emporte en cas de conflit.
Lisible par machine : JSON