systemd est le système init et le gestionnaire de services qui alimente pratiquement toutes les distributions Linux modernes, y compris Ubuntu, Debian, Fedora, CentOS et Arch Linux. Il a remplacé le système traditionnel SysVinit pour fournir un démarrage parallèle des services, une gestion des dépendances, une activation à la demande et une journalisation centralisée. Que vous gériez un serveur unique ou une flotte de machines en production, comprendre systemd est essentiel pour une administration efficace de Linux. Ce guide couvre les commandes systemctl, les fichiers d’unité personnalisés, les minuteries, la gestion du journal, l’analyse du démarrage et le contrôle des ressources avec les cgroups.

Prérequis

Avant de commencer, assurez-vous d’avoir :

  • Ubuntu Server 20.04, 22.04 ou 24.04 (ou toute distribution basée sur systemd)
  • Accès au terminal avec des privilèges sudo
  • Familiarité de base avec la ligne de commande Linux
  • Un éditeur de texte (nano, vim ou votre préférence)

Qu’est-ce que systemd ?

systemd est un gestionnaire de système et de services pour Linux. Il s’exécute en tant que PID 1 — le premier processus démarré par le noyau — et est responsable de l’amorçage de tout l’espace utilisateur, de la gestion des services tout au long de leur cycle de vie et de l’arrêt propre du système.

Les composants principaux de systemd incluent :

  • systemctl — l’outil principal en ligne de commande pour contrôler les services et inspecter l’état du système
  • journald — un système de journalisation structuré qui collecte les journaux de tous les services, du noyau et du démarrage initial
  • systemd-analyze — un outil pour profiler et optimiser les performances de démarrage
  • systemd-resolved — un service de résolution DNS
  • systemd-networkd — un gestionnaire de configuration réseau
  • systemd-logind — un gestionnaire de connexion et de sessions
  • systemd-tmpfiles — un outil pour gérer les fichiers et répertoires temporaires

Vérifiez que votre système exécute systemd :

systemctl --version

Sortie attendue :

systemd 252 (252.22-1ubuntu1)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT ...

Vérifiez l’état général du système :

systemctl status

Cela affiche une arborescence des services en cours d’exécution, leurs PIDs et l’utilisation de la mémoire.

systemd vs SysVinit

Comprendre ce qui a changé par rapport à SysVinit aide à clarifier pourquoi systemd fonctionne comme il le fait :

CaractéristiqueSysVinitsystemd
Définition de serviceScripts shell dans /etc/init.d/Fichiers d’unité déclaratifs dans /etc/systemd/system/
Ordre de démarrageSéquentiel (l’un après l’autre)Parallèle (basé sur les dépendances)
Gestion des dépendancesManuelle avec les scripts de runlevelAutomatique avec Requires, After, Wants
Suivi des processusFichiers PID (peu fiable)cgroups (suivi au niveau du noyau)
Journalisationsyslog / fichiers de log séparésjournald (journal binaire structuré)
Activation à la demandeNon intégréeActivation par socket, activation D-Bus
Contrôle des ressourcesAucuncgroups (limites CPU, mémoire, E/S)
Cibles de démarrageRunlevels (0-6)Targets (multi-user.target, graphical.target)

L’avantage clé de systemd est la fiabilité : il suit les processus via les cgroups pour toujours savoir quels processus appartiennent à un service, même s’ils effectuent un fork. Les fichiers PID utilisés par SysVinit étaient une source courante d’état obsolète et de défaillances dans la gestion des services.

Gestion des Services avec systemctl

systemctl est la commande que vous utiliserez le plus souvent. Elle communique avec le gestionnaire systemd pour contrôler les services, inspecter leur état et gérer leur comportement au démarrage.

Démarrer et Arrêter des Services

# Démarrer un service
sudo systemctl start nginx

# Arrêter un service
sudo systemctl stop nginx

# Redémarrer un service (arrêter puis démarrer)
sudo systemctl restart nginx

# Recharger la configuration sans redémarrer (si supporté)
sudo systemctl reload nginx

# Recharger ou redémarrer (recharger si supporté, sinon redémarrer)
sudo systemctl reload-or-restart nginx

Vérifier l’État du Service

sudo systemctl status nginx

Exemple de sortie :

● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2026-01-29 10:15:30 UTC; 2h ago
       Docs: man:nginx(8)
   Main PID: 1241 (nginx)
      Tasks: 3 (limit: 4647)
     Memory: 8.2M
        CPU: 52ms
     CGroup: /system.slice/nginx.service
             ├─1241 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             ├─1242 "nginx: worker process"
             └─1243 "nginx: worker process"

Champs importants :

  • Loaded — si le fichier d’unité est chargé et où il se trouve
  • Active — l’état actuel (active, inactive, failed)
  • Main PID — l’identifiant du processus principal du service
  • CGroup — tous les processus appartenant à ce service

Activer et Désactiver des Services

Activer un service signifie qu’il démarrera automatiquement au démarrage. Désactiver supprime ce comportement.

# Activer un service au démarrage
sudo systemctl enable nginx

# Désactiver un service du démarrage automatique
sudo systemctl disable nginx

# Activer et démarrer en une seule commande
sudo systemctl enable --now nginx

# Désactiver et arrêter en une seule commande
sudo systemctl disable --now nginx

Vérifier l’État d’Activation

systemctl is-enabled nginx
# Sortie : enabled

systemctl is-active nginx
# Sortie : active

systemctl is-failed nginx
# Sortie : active (pas en échec)

Lister les Services

# Lister tous les services actifs
systemctl list-units --type=service

# Lister tous les services (y compris inactifs)
systemctl list-units --type=service --all

# Lister les services activés
systemctl list-unit-files --type=service --state=enabled

# Lister les services en échec
systemctl list-units --type=service --state=failed

Comprendre les Fichiers d’Unité

systemd gère tout à travers des fichiers d’unité — des fichiers de configuration déclaratifs qui décrivent les services, les points de montage, les périphériques, les sockets, les minuteries et plus encore.

Types d’Unité

Type d’UnitéExtensionFonction
Service.serviceGère un démon ou un processus ponctuel
Timer.timerPlanifie l’activation des services (remplacement de cron)
Socket.socketGère l’activation basée sur les sockets
Mount.mountGère les points de montage du système de fichiers
Target.targetRegroupe les unités pour la synchronisation
Path.pathSurveille les chemins du système de fichiers pour les modifications
Slice.sliceGère les partitions de ressources des cgroups
Device.deviceGère les nœuds de périphériques du noyau

Emplacements des Fichiers d’Unité

Les fichiers d’unité sont chargés depuis plusieurs répertoires avec une priorité spécifique :

RépertoireFonctionPriorité
/etc/systemd/system/Surcharges de l’administrateur localPlus haute
/run/systemd/system/Unités d’exécution (non persistantes)Moyenne
/lib/systemd/system/Unités fournies par la distributionPlus basse

Créez ou modifiez toujours les unités dans /etc/systemd/system/. Ne modifiez jamais directement les fichiers dans /lib/systemd/system/, car les mises à jour de paquets écraseront vos modifications.

Inspecter les Fichiers d’Unité

# Voir le fichier d'unité complet d'un service
systemctl cat nginx.service

# Afficher toutes les propriétés d'un service (configuration effective)
systemctl show nginx.service

# Afficher une propriété spécifique
systemctl show nginx.service -p MainPID
systemctl show nginx.service -p ActiveState

# Lister toutes les dépendances d'un service
systemctl list-dependencies nginx.service

Créer des Unités de Service Personnalisées

L’une des compétences les plus pratiques de systemd est l’écriture de vos propres fichiers d’unité de service. Cela vous permet de gérer n’importe quelle application — d’un serveur Node.js à un binaire Go ou un script Python — comme un service système.

Unité de Service de Base

Créez un fichier dans /etc/systemd/system/myapp.service :

[Unit]
Description=My Custom Application
Documentation=https://example.com/docs
After=network.target
Wants=network-online.target

[Service]
Type=simple
User=myapp
Group=myapp
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/bin/myapp --config /etc/myapp/config.yaml
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal
SyslogIdentifier=myapp

[Install]
WantedBy=multi-user.target

Détail des Sections

[Unit] — métadonnées et dépendances :

  • Description — description lisible affichée dans la sortie d’état
  • Documentation — URL de la documentation
  • After — démarrer cette unité après les unités listées
  • Wants — dépendance faible (n’échoue pas si la dépendance échoue)
  • Requires — dépendance forte (échoue si la dépendance échoue)

[Service] — comportement du service :

  • Type — comment systemd détermine que le service est prêt (simple, forking, oneshot, notify, idle)
  • User / Group — exécuter le service en tant que cet utilisateur/groupe
  • WorkingDirectory — définir le répertoire de travail
  • ExecStart — la commande pour démarrer le service
  • ExecStartPre — commandes à exécuter avant le processus principal
  • ExecStartPost — commandes à exécuter après le démarrage du processus principal
  • ExecStop — la commande pour arrêter le service (par défaut SIGTERM)
  • ExecReload — la commande pour recharger la configuration
  • Restart — quand redémarrer (no, on-success, on-failure, on-abnormal, on-watchdog, on-abort, always)
  • RestartSec — temps d’attente avant le redémarrage

[Install] — comportement d’installation :

  • WantedBy — le target qui doit inclure ce service (habituellement multi-user.target)

Types de Service Expliqués

# Simple (par défaut) : ExecStart est le processus principal
Type=simple

# Forking : le processus effectue un fork et le parent quitte (démons traditionnels)
Type=forking
PIDFile=/run/myapp.pid

# Oneshot : le processus s'exécute jusqu'à la fin puis quitte
Type=oneshot
RemainAfterExit=yes

# Notify : le processus envoie une notification lorsqu'il est prêt
Type=notify

# Idle : comme simple mais attend que tous les travaux soient distribués
Type=idle

Activer le Service

Après avoir créé ou modifié un fichier d’unité, rechargez le démon systemd et gérez le service :

# Recharger systemd pour lire les fichiers d'unité nouveaux/modifiés
sudo systemctl daemon-reload

# Démarrer le service
sudo systemctl start myapp

# Vérifier l'état
sudo systemctl status myapp

# Activer au démarrage
sudo systemctl enable myapp

Surcharger des Unités Existantes

Au lieu de modifier les fichiers d’unité fournis par le distributeur, utilisez des surcharges drop-in :

# Créer un répertoire et un fichier de surcharge
sudo systemctl edit nginx.service

Cela ouvre un éditeur pour /etc/systemd/system/nginx.service.d/override.conf. Ajoutez uniquement les directives que vous souhaitez modifier :

[Service]
LimitNOFILE=65535

Pour voir la configuration effective après les surcharges :

systemctl cat nginx.service

Minuteries systemd

Les minuteries systemd sont un remplacement moderne des tâches cron. Elles offrent une planification persistante (rattrapage des exécutions manquées), une journalisation par minuterie et une intégration avec le contrôle des ressources des cgroups.

Structure de l’Unité de Minuterie

Une minuterie nécessite deux fichiers : une unité .timer et une unité .service correspondante avec le même nom.

Créez /etc/systemd/system/backup.timer :

[Unit]
Description=Run backup every day at 2:00 AM

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=300

[Install]
WantedBy=timers.target

Créez /etc/systemd/system/backup.service :

[Unit]
Description=System Backup Service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
User=root
StandardOutput=journal
StandardError=journal

Types de Minuterie

Basées sur le calendrier (OnCalendar) :

# Tous les jours à minuit
OnCalendar=daily

# Tous les lundis à 3h du matin
OnCalendar=Mon *-*-* 03:00:00

# Toutes les 6 heures
OnCalendar=*-*-* 00/6:00:00

# Premier jour de chaque mois
OnCalendar=*-*-01 00:00:00

# Toutes les 15 minutes
OnCalendar=*-*-* *:00/15:00

Monotones (relatives à un événement) :

# 5 minutes après le démarrage
OnBootSec=5min

# 1 heure après l'activation de la minuterie
OnActiveSec=1h

# 30 minutes après la fin de la dernière exécution
OnUnitActiveSec=30min

Gérer les Minuteries

# Recharger, activer et démarrer la minuterie
sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer

# Lister toutes les minuteries actives
systemctl list-timers --all

# Vérifier l'état de la minuterie
systemctl status backup.timer

# Tester le service associé manuellement
sudo systemctl start backup.service

Vérifier les Expressions Calendaires

Utilisez systemd-analyze calendar pour tester vos expressions de minuterie :

systemd-analyze calendar "Mon *-*-* 03:00:00"

Sortie :

  Original form: Mon *-*-* 03:00:00
Normalized form: Mon *-*-* 03:00:00
    Next elapse: Mon 2026-02-02 03:00:00 UTC
       (in UTC): Mon 2026-02-02 03:00:00 UTC
       From now: 3 days left

Gestion du Journal et des Logs avec journalctl

journald est le composant de journalisation de systemd. Il collecte les journaux de tous les services, du noyau et du processus de démarrage initial dans un journal binaire structuré qui prend en charge les recherches rapides, le filtrage et l’exportation.

Utilisation de Base de journalctl

# Voir tous les journaux (les plus anciens d'abord)
journalctl

# Voir les entrées les plus récentes (les plus récentes d'abord)
journalctl -r

# Suivre les journaux en temps réel
journalctl -f

# Afficher les journaux depuis le dernier démarrage
journalctl -b

# Afficher les journaux du démarrage précédent
journalctl -b -1

Filtrer par Service

# Journaux d'un service spécifique
journalctl -u nginx.service

# Suivre un service spécifique en temps réel
journalctl -u nginx.service -f

# Journaux de plusieurs services
journalctl -u nginx.service -u php-fpm.service

Filtrer par Temps

# Journaux depuis un moment spécifique
journalctl --since "2026-01-29 10:00:00"

# Journaux dans une plage horaire
journalctl --since "2026-01-29 10:00:00" --until "2026-01-29 12:00:00"

# Journaux de la dernière heure
journalctl --since "1 hour ago"

# Journaux d'aujourd'hui
journalctl --since today

Filtrer par Priorité

journalctl prend en charge les niveaux de priorité syslog :

# Afficher uniquement les erreurs et au-dessus
journalctl -p err

# Afficher les avertissements et au-dessus
journalctl -p warning

# Afficher les critiques et au-dessus
journalctl -p crit
Niveau de PrioritéMot-cléNumérique
Urgenceemerg0
Alertealert1
Critiquecrit2
Erreurerr3
Avertissementwarning4
Noticenotice5
Informationinfo6
Débogagedebug7

Formats de Sortie

# Sortie JSON (pour le traitement)
journalctl -u nginx.service -o json-pretty

# Sortie courte avec des horodatages précis
journalctl -u nginx.service -o short-precise

# Sortie détaillée avec tous les champs
journalctl -u nginx.service -o verbose

Gérer la Taille du Journal

# Vérifier l'utilisation actuelle du disque
journalctl --disk-usage

# Conserver uniquement les 2 dernières semaines de journaux
sudo journalctl --vacuum-time=2weeks

# Limiter la taille du journal à 500 Mo
sudo journalctl --vacuum-size=500M

# Supprimer les journaux archivés
sudo journalctl --rotate
sudo journalctl --vacuum-time=1s

Pour une configuration persistante, modifiez /etc/systemd/journald.conf :

[Journal]
SystemMaxUse=500M
SystemMaxFileSize=50M
MaxRetentionSec=2week

Puis redémarrez journald :

sudo systemctl restart systemd-journald

Analyse des Performances de Démarrage

systemd fournit des outils intégrés pour mesurer et optimiser les temps de démarrage.

Temps de Démarrage Global

systemd-analyze

Sortie :

Startup finished in 3.245s (kernel) + 8.712s (userspace) = 11.957s
graphical.target reached after 8.510s in userspace.

Détail par Service

# Lister les services triés par temps de démarrage
systemd-analyze blame

Sortie :

5.012s NetworkManager-wait-online.service
1.234s snapd.service
  892ms docker.service
  456ms nginx.service
  234ms ssh.service
  ...

Chaîne Critique

La chaîne critique montre la séquence d’unités qui a déterminé le temps total de démarrage :

systemd-analyze critical-chain

Sortie :

graphical.target @8.510s
└─multi-user.target @8.508s
  └─nginx.service @8.052s +456ms
    └─network-online.target @8.050s
      └─NetworkManager-wait-online.service @3.038s +5.012s
        └─NetworkManager.service @2.890s +145ms
          └─basic.target @2.880s

Graphique de Démarrage SVG

Générez une chronologie visuelle du processus de démarrage :

systemd-analyze plot > boot-chart.svg

Ouvrez le fichier SVG dans un navigateur web pour voir une représentation graphique détaillée des temps de démarrage des services et des dépendances.

Identifier les Services Lents

# Trouver les services lents au démarrage
systemd-analyze blame | head -20

# Vérifier si un service spécifique retarde le démarrage
systemd-analyze critical-chain nginx.service

Stratégies courantes d’optimisation du démarrage :

  • Désactiver les services dont vous n’avez pas besoin (sudo systemctl disable nom_du_service)
  • Masquer les services que vous ne voulez jamais exécuter (sudo systemctl mask nom_du_service)
  • Investiguer NetworkManager-wait-online.service (une source courante de retard au démarrage)
  • Utiliser l’activation par socket pour les services qui ne sont pas nécessaires immédiatement

Contrôle des Ressources avec les Cgroups

systemd utilise les groupes de contrôle Linux (cgroups) pour gérer et limiter les ressources disponibles pour chaque service. Cela empêche un service défaillant de consommer toutes les ressources du système.

Voir l’Utilisation Actuelle des Ressources

# Afficher l'utilisation des ressources par slice
systemd-cgtop

Définir des Limites de Mémoire

Ajoutez des directives de ressources à la section [Service] d’un fichier d’unité :

[Service]
MemoryMax=512M
MemoryHigh=400M
  • MemoryMax — limite stricte ; le OOM killer intervient si dépassée
  • MemoryHigh — limite souple ; le noyau ralentit le service lorsqu’elle est dépassée

Définir des Limites de CPU

[Service]
CPUQuota=50%
CPUWeight=100
  • CPUQuota — limite le service à un pourcentage d’un seul cœur CPU (200% = deux cœurs)
  • CPUWeight — poids relatif pour le partage du temps CPU (par défaut 100)

Définir des Limites d’E/S

[Service]
IOWeight=50
IOReadBandwidthMax=/dev/sda 10M
IOWriteBandwidthMax=/dev/sda 5M

Appliquer des Limites en Temps d’Exécution

Vous pouvez appliquer des limites de ressources temporairement sans modifier les fichiers d’unité :

# Limiter la mémoire pour un service en cours d'exécution
sudo systemctl set-property nginx.service MemoryMax=512M

# Limiter le CPU pour un service en cours d'exécution
sudo systemctl set-property nginx.service CPUQuota=50%

# Rendre le changement persistant
sudo systemctl set-property nginx.service MemoryMax=512M --runtime=false

Voir les Limites Effectives

systemctl show nginx.service -p MemoryMax -p CPUQuota -p IOWeight

Référence des Commandes systemctl

CommandeDescription
systemctl start <unité>Démarrer une unité
systemctl stop <unité>Arrêter une unité
systemctl restart <unité>Redémarrer une unité
systemctl reload <unité>Recharger la configuration de l’unité
systemctl enable <unité>Activer l’unité au démarrage
systemctl disable <unité>Désactiver l’unité au démarrage
systemctl enable --now <unité>Activer et démarrer immédiatement
systemctl status <unité>Afficher l’état de l’unité
systemctl is-active <unité>Vérifier si l’unité est en cours d’exécution
systemctl is-enabled <unité>Vérifier si l’unité est activée
systemctl is-failed <unité>Vérifier si l’unité a échoué
systemctl list-unitsLister toutes les unités chargées
systemctl list-unit-filesLister tous les fichiers d’unité
systemctl list-timersLister les minuteries actives
systemctl daemon-reloadRecharger les modifications des fichiers d’unité
systemctl cat <unité>Afficher le contenu du fichier d’unité
systemctl show <unité>Afficher toutes les propriétés de l’unité
systemctl edit <unité>Créer une surcharge drop-in
systemctl mask <unité>Empêcher l’unité de démarrer
systemctl unmask <unité>Retirer le masque de l’unité
systemctl list-dependencies <unité>Afficher les dépendances de l’unité
systemctl set-property <unité> <clé>=<val>Définir une propriété en temps d’exécution
journalctl -u <unité>Voir les journaux de l’unité
journalctl -u <unité> -fSuivre les journaux de l’unité
systemd-analyze blameAfficher le temps de démarrage par service
systemd-analyze critical-chainAfficher le chemin critique de démarrage

Dépannage des Services en Échec

Lorsqu’un service échoue, suivez cette approche systématique pour diagnostiquer et résoudre le problème.

Étape 1 : Vérifier l’État

sudo systemctl status myapp.service

Recherchez la ligne Active. États courants :

  • active (running) — le service fonctionne normalement
  • inactive (dead) — le service est arrêté
  • failed — le service a planté ou n’a pas réussi à démarrer
  • activating (auto-restart) — le service est en cours de redémarrage

Étape 2 : Lire les Journaux

# Journaux complets du service
journalctl -u myapp.service --no-pager

# 50 dernières lignes
journalctl -u myapp.service -n 50

# Erreurs uniquement
journalctl -u myapp.service -p err

Étape 3 : Valider le Fichier d’Unité

# Vérifier les erreurs de syntaxe
systemd-analyze verify /etc/systemd/system/myapp.service

Étape 4 : Tester la Commande Manuellement

Exécutez la commande ExecStart manuellement en tant qu’utilisateur du service pour vérifier si l’application fonctionne :

sudo -u myapp /opt/myapp/bin/myapp --config /etc/myapp/config.yaml

Étape 5 : Vérifier les Problèmes Courants

Erreurs de permissions :

# Vérifier que le binaire est exécutable
ls -la /opt/myapp/bin/myapp

# Vérifier que l'utilisateur existe
id myapp

# Vérifier les permissions du répertoire
ls -la /opt/myapp/

Dépendances manquantes :

# Vérifier les bibliothèques partagées manquantes
ldd /opt/myapp/bin/myapp

Conflits de ports :

# Vérifier si le port est déjà utilisé
ss -tlnp | grep :8080

Étape 6 : Réinitialiser un Service en Échec

# Réinitialiser l'état d'échec
sudo systemctl reset-failed myapp.service

# Essayer de démarrer à nouveau
sudo systemctl start myapp.service

Modèles d’Erreur Courants

SymptômeCause ProbableSolution
code=exited, status=203/EXECBinaire non trouvé ou non exécutableVérifier le chemin ExecStart et les permissions
code=exited, status=217/USERL’utilisateur du service n’existe pasCréer l’utilisateur avec useradd
code=exited, status=200/CHDIRWorkingDirectory n’existe pasCréer le répertoire
code=exited, status=1/FAILUREErreur d’applicationVérifier les journaux avec journalctl
Le service redémarre sans cesseBoucle de plantageVérifier RestartSec, examiner les journaux de l’application
code=killed, signal=KILLOOM killerAugmenter MemoryMax ou optimiser l’application

Résumé

systemd est la colonne vertébrale de la gestion des services sur les systèmes Linux modernes. Il fournit une approche unifiée et déclarative pour gérer les services, planifier des tâches, contrôler les ressources et analyser le comportement du système. Maîtriser systemctl, les fichiers d’unité, les minuteries et journalctl vous donne un contrôle total sur le fonctionnement de vos serveurs Linux.

Points clés :

  • Utilisez systemctl pour toutes les tâches de gestion de services : démarrer, arrêter, activer, désactiver et vérifier l’état
  • Écrivez des fichiers d’unité personnalisés dans /etc/systemd/system/ pour gérer vos propres applications comme des services système
  • Remplacez les tâches cron par des minuteries systemd pour une planification persistante, une journalisation par tâche et un contrôle des ressources
  • Utilisez journalctl pour un filtrage puissant des journaux par service, plage horaire et niveau de priorité
  • Analysez les performances de démarrage avec systemd-analyze et désactivez les services inutiles pour accélérer le démarrage
  • Appliquez des limites de ressources avec les cgroups (MemoryMax, CPUQuota) pour empêcher les services d’épuiser le système
  • Utilisez les surcharges drop-in (systemctl edit) au lieu de modifier les fichiers d’unité du distributeur

Pour une approche plus large de la sécurisation de vos serveurs Linux, consultez notre Liste de Vérification de Sécurité pour Serveurs Linux et Guide de Configuration du Pare-feu UFW.