Démarrer et diagnostiquer un service Linux avec systemctl

systemctl est la commande centrale pour gérer les services sous Linux. Elle permet de démarrer, arrêter, redémarrer et activer au boot n’importe quel service géré par systemd. Associée à journalctl pour les logs, elle couvre l’essentiel de l’administration des services sur un serveur moderne.

Ce que vous allez apprendre

• Comprendre les états d’un service (active, inactive, failed, masked)
• Utiliser les commandes systemctl pour contrôler le cycle de vie d’un service
• Activer un service au démarrage et vérifier sa persistance
• Diagnostiquer un échec avec systemctl status et journalctl
• Créer une unité de service personnalisée
• Appliquer les options de sécurité systemd (sandboxing)

Dans quel contexte ?

La gestion des services avec systemctl intervient quotidiennement en administration Linux :

• Installer un serveur web et s’assurer qu’il redémarre automatiquement après un reboot
• Diagnostiquer pourquoi un service de base de données ne démarre plus
• Appliquer un changement de configuration et recharger le service sans interruption
• Créer un service personnalisé pour une application métier
• Durcir un service exposé sur le réseau en limitant ses privilèges

LFCS / RHCSA

La gestion des services avec systemctl est un objectif majeur des deux certifications. Vous devez savoir démarrer, arrêter, activer un service, lire son statut et diagnostiquer un échec.

Les états d’un service

Un service systemd passe par plusieurs états au cours de son cycle de vie :

État	Signification
active (running)	Le service tourne normalement
active (exited)	Le service a terminé son exécution avec succès (Type=oneshot)
inactive (dead)	Le service est arrêté
failed	Le service a échoué — consulter les logs
activating	Le service est en cours de démarrage
deactivating	Le service est en cours d’arrêt
masked	Le service est bloqué — impossible de le démarrer

Glissez pour voir

Enabled vs active

Deux notions distinctes et complémentaires :

Concept	Question	Commande
enabled	Le service démarre-t-il automatiquement au boot ?	systemctl is-enabled nginx
active	Le service tourne-t-il en ce moment ?	systemctl is-active nginx

Glissez pour voir

Un service peut être enabled mais inactive (il sera lancé au prochain reboot). Il peut être active mais disabled (il tourne mais ne survivra pas au reboot).

Commandes systemctl essentielles

Contrôle immédiat (runtime)

# Démarrer un service
sudo systemctl start nginx

# Arrêter un service
sudo systemctl stop nginx

# Redémarrer un service (arrêt + démarrage)
sudo systemctl restart nginx

# Recharger la configuration sans redémarrer
sudo systemctl reload nginx

reload vs restart

reload demande au service de relire sa configuration sans interrompre les connexions en cours. restart arrête puis redémarre le processus. Préférez reload quand le service le supporte (Nginx, Apache, PostgreSQL).

Activation au démarrage

# Activer le démarrage automatique au boot
sudo systemctl enable nginx

# Activer ET démarrer immédiatement
sudo systemctl enable --now nginx

# Désactiver le démarrage automatique
sudo systemctl disable nginx

Vérifier l’état

systemctl status nginx

● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Sat 2026-06-28 06:32:15 CEST; 6h ago
       Docs: man:nginx(8)
    Process: 1234 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; ... (code=exited, status=0/SUCCESS)
   Main PID: 1235 (nginx)
      Tasks: 3 (limit: 4644)
     Memory: 8.2M
        CPU: 123ms
     CGroup: /system.slice/nginx.service
             ├─1235 "nginx: master process /usr/sbin/nginx ..."
             └─1236 "nginx: worker process"

Chaque ligne apporte une information :

Ligne	Signification
Loaded	Chemin du fichier unité + état d’activation (enabled/disabled)
Active	État actuel + depuis quand
Main PID	PID du processus principal
Tasks	Nombre de tâches/threads
Memory	Consommation mémoire
CGroup	Arborescence des processus dans le cgroup

Glissez pour voir

Commandes de vérification rapide

# Le service est-il actif ?
systemctl is-active nginx
# active

# Le service démarre-t-il au boot ?
systemctl is-enabled nginx
# enabled

# Le service a-t-il échoué ?
systemctl is-failed nginx
# active (pas d'échec)

Inspecter la configuration d’un service

# Afficher le fichier unité complet
systemctl cat nginx

# Afficher des propriétés spécifiques
systemctl show nginx --property=MainPID,ActiveState,SubState

MainPID=1235
ActiveState=active
SubState=running

Lister les services

# Tous les services chargés
systemctl list-units --type=service

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

# Tous les services installés (y compris désactivés)
systemctl list-unit-files --type=service

Masquer un service

Masquer un service empêche toute tentative de démarrage — même manuelle :

# Masquer un service
sudo systemctl mask bluetooth

# Démasquer
sudo systemctl unmask bluetooth

mask vs disable

disable retire le démarrage automatique mais permet de lancer le service manuellement. mask l’empêche totalement — un systemctl start échouera. Utilisez mask pour les services qui ne doivent jamais tourner sur un serveur (Bluetooth, Avahi, CUPS).

Diagnostiquer un service en échec

Quand un service est en état failed, suivez cette démarche :

1. Lire le statut

   systemctl status mon-service

   Les dernières lignes de log apparaissent directement.

2. Consulter les logs détaillés

   journalctl -xeu mon-service

   • -x : ajoute des explications contextuelles
   • -e : saute à la fin du journal
   • -u : filtre par unité

3. Filtrer par niveau d’erreur

   journalctl -u mon-service -p err -b

   • -p err : uniquement les erreurs et au-dessus
   • -b : depuis le dernier démarrage

4. Corriger et relancer

   # Corriger la configuration puis :
   sudo systemctl daemon-reload   # si le fichier unité a changé
   sudo systemctl restart mon-service
   systemctl status mon-service

Créer un service personnalisé

Pour exécuter une application métier comme un service systemd :

sudo systemctl edit --full --force mon-app.service

[Unit]
Description=Mon application métier
After=network.target postgresql.service
Wants=postgresql.service

[Service]
Type=simple
User=appuser
Group=appuser
WorkingDirectory=/opt/mon-app
ExecStart=/opt/mon-app/bin/start.sh
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

Les sections d’un fichier unité

Section	Rôle
[Unit]	Description, dépendances, ordre de démarrage
[Service]	Type, commandes, utilisateur, redémarrage
[Install]	Quand activer le service (target)

Glissez pour voir

Types de services

Type	Comportement
simple	Le processus lancé par ExecStart est le processus principal (défaut)
forking	Le processus se détache (fork) — systemd suit le PID fils
oneshot	Exécute une commande puis se termine (scripts, tâches ponctuelles)
notify	Le processus signale à systemd qu’il est prêt via sd_notify()
idle	Attend que tous les jobs soient terminés avant de démarrer

Glissez pour voir

Directives de redémarrage

Directive	Valeur	Effet
Restart	on-failure	Redémarre uniquement en cas d’échec (code retour ≠ 0)
Restart	always	Redémarre dans tous les cas
Restart	no	Ne redémarre jamais (défaut)
RestartSec	5s	Attend 5 secondes avant le redémarrage
StartLimitBurst	3	Nombre max de redémarrages dans la fenêtre
StartLimitIntervalSec	60s	Fenêtre de temps pour les redémarrages

Glissez pour voir

Activer et démarrer

Après avoir créé un nouveau service :

sudo systemctl daemon-reload
sudo systemctl enable --now mon-app.service
systemctl status mon-app.service

Sécurité : durcir un service

systemd offre des options de sandboxing pour limiter ce qu’un service peut faire :

[Service]
# Système de fichiers en lecture seule
ProtectSystem=strict
ReadWritePaths=/var/lib/mon-app /var/log/mon-app

# Répertoire /home inaccessible
ProtectHome=true

# Pas d'accès aux périphériques
PrivateDevices=true

# Pas de changement d'heure
ProtectClock=true

# Pas de modification du hostname
ProtectHostname=true

# Pas de chargement de modules noyau
ProtectKernelModules=true

# Pas de modification des paramètres noyau
ProtectKernelTunables=true

# Pas d'accès réseau (pour les tâches locales)
# PrivateNetwork=true

# Pas de nouveaux privilèges (suid)
NoNewPrivileges=true

# Auditer le niveau de sécurité d'un service
systemd-analyze security mon-app.service

Cette commande attribue un score de 0 à 10 (plus bas = plus sécurisé) et liste les protections manquantes.

Tester avant de durcir

Certaines options de sécurité peuvent empêcher un service de fonctionner (accès fichiers bloqué, réseau coupé). Activez les options une par une et testez entre chaque modification.

Optimiser le temps de démarrage

# Voir les services les plus lents au boot
systemd-analyze blame

3.456s NetworkManager-wait-online.service
1.234s docker.service
0.987s systemd-journal-flush.service
0.654s nginx.service

# Graphe SVG du démarrage
systemd-analyze plot > boot.svg

Dépannage

Symptôme	Cause probable	Solution
Service failed au démarrage	Erreur de configuration	journalctl -xeu mon-service pour lire l’erreur
Service actif mais pas enabled	Oubli de enable	sudo systemctl enable mon-service
start échoue avec masked	Service masqué	sudo systemctl unmask mon-service
Service redémarre en boucle	StartLimitBurst atteint	systemctl reset-failed mon-service puis corriger la cause
Modification du fichier unité ignorée	Cache systemd	sudo systemctl daemon-reload
Permission denied dans les logs	Utilisateur sans droits	Vérifier User= et les permissions des fichiers
Service ne survit pas au reboot	Non activé au boot	sudo systemctl enable mon-service

Glissez pour voir

À retenir

• systemctl gère le cycle de vie complet des services : start, stop, restart, reload, enable, disable
• Un service enabled démarre au boot ; un service active tourne en ce moment — les deux sont indépendants
• systemctl status et journalctl -xeu sont les outils de diagnostic essentiels
• Un fichier unité comporte trois sections : [Unit] (dépendances), [Service] (exécution), [Install] (activation)
• Restart=on-failure et RestartSec permettent un redémarrage automatique en cas d’échec
• Les options de sandboxing (ProtectSystem, ProtectHome, NoNewPrivileges) durcissent un service
• mask empêche totalement le lancement d’un service — plus strict que disable

Quiz

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Prochaines étapes

Comprendre systemd en profondeur Architecture, targets, dépendances : les concepts avancés de systemd

Journaux système avec journald Maîtriser journalctl pour diagnostiquer vos services

Rotation des logs avec logrotate Gérer la taille des fichiers de log automatiquement

Timers systemd Planifier des tâches avec les timers systemd

Questions fréquentes

Qu'est-ce que systemd et pourquoi a-t-il remplacé les anciens systèmes d'init ?

**systemd** est le système d'initialisation et de gestion de services utilisé par la majorité des distributions Linux mo…

Quelles sont les commandes systemctl essentielles à connaître ?

Voici les **commandes systemctl les plus utilisées** au quotidien : ### Gestion d'un service ```bash # Démarrer un ser…

Comment créer un service systemd personnalisé ?

Pour créer un **service personnalisé**, il faut créer un fichier `.service` dans `/etc/systemd/system/`. ### Étape 1 :…

Quelle est la différence entre enable, start, restart et reload ?

Ces commandes ont des **rôles très différents** : ### Comparaison | Commande | Action | Effet immédiat | Au reboot | |…

Comment diagnostiquer un service qui ne démarre pas ?

Quand un service échoue, voici la **méthode de diagnostic** : ### Étape 1 : Vérifier l'état ```bash systemctl status m…

Comment voir les logs d'un service avec journalctl ?

**journalctl** est l'outil de consultation des logs systemd. ### Commandes essentielles ```bash # Logs d'un service sp…

Qu'est-ce qu'un target systemd et comment ça fonctionne ?

Un **target** systemd est un groupe de services qui définit un **état du système** (équivalent des runlevels SysVinit).…

Comment masquer un service pour l'empêcher de démarrer ?

**Masquer** un service (`mask`) est plus strict que le désactiver (`disable`). ### Différence mask vs disable | Action…

Comment limiter les ressources d'un service (CPU, mémoire) ?

systemd utilise les **cgroups** pour limiter les ressources des services. ### Dans le fichier .service ```ini [Service…

Comment sécuriser un service systemd ?

systemd offre des **options de durcissement** pour isoler les services. ### Options de sécurité recommandées ```ini [S…

Comment analyser le temps de démarrage du système ?

**systemd-analyze** permet d'identifier les services qui ralentissent le boot. ### Temps total de démarrage ```bash sy…

Comment redémarrer automatiquement un service qui plante ?

systemd peut **redémarrer automatiquement** les services en échec. ### Configuration dans le fichier .service ```ini […

Comment programmer une tâche planifiée avec systemd timer ?

Les **timers systemd** remplacent avantageusement cron pour les tâches planifiées. ### Créer un timer **1. Le service…

Quels sont les types de services systemd (simple, forking, oneshot) ?

Le **Type** définit comment systemd détecte que le service est "prêt". ### Types principaux | Type | Comportement | Ex…

Comment gérer les dépendances entre services ?

systemd gère les **dépendances** via des directives dans la section `[Unit]`. ### Directives principales | Directive |…

×

📖 Voir la documentation →