Gérer Linux ne consiste pas seulement à mémoriser des commandes. De nombreuses différences entre résoudre une panne en dix minutes ou passer une heure à essayer diverses solutions résident dans de petits comportements : regarder avant d’agir, vérifier ce qui a changé, sauvegarder des preuves avant de redémarrer, et vérifier le résultat de chaque action. Ce sont des pratiques simples qui sont utiles aussi bien pour la gestion d’un serveur domestique que pour des équipes responsables de systèmes en production.

Les clés des bonnes habitudes sous Linux en 20 secondes

• Avant de redémarrer un service, il est conseillé de vérifier son état et ses derniers logs.
• journalctl, ss, findmnt ou vmstat aident à comprendre ce qui se passe réellement.
• Les commandes destructives devraient être d’abord testées avec des options comme --dry-run.
• Lors de l’automatisation, il faut vérifier les erreurs et ne pas dépendre uniquement de l’environnement terminal.
• Documenter les incidents évite d’investiguer deux fois le même problème.

Il n’est pas nécessaire d’installer une plateforme d’observabilité pour appliquer ces pratiques. Beaucoup des outils indispensables font partie de toute distribution moderne.

L’idée centrale est de changer une habitude très humaine : arrêter de tester des solutions avant d’avoir compris le problème.

Avant de réparer Linux, il faut lui demander ce qui se passe

Lorsque qu’une page web ne répond plus, qu’une base de données semble bloquée ou qu’un service tombe, il est souvent tentant de simplement le redémarrer, car cela paraît la solution la plus rapide.

Par exemple :

systemctl restart nginx

Parfois, cela fonctionne.

Mais cela change aussi l’état du système et peut faire disparaître des informations utiles pour comprendre ce qui s’est passé.

Avant de redémarrer, il est beaucoup plus pertinent d’exécuter :

systemctl status nginx

Puis, d’examiner les derniers messages :

journalctl -u nginx --since "-15 min"

Et de vérifier si un processus écoute réellement sur les ports attendus :

ss -lntp

Une vérification supplémentaire du stockage et de la mémoire offre une première image :

df -h

free -h

En moins d’une minute, on dispose déjà de renseignements précieux.

Ce mode de travail engage une règle simple : observer d’abord, intervenir ensuite.

Poser la question “qu’est-ce qui a changé” fait gagner beaucoup de temps

Un serveur qui fonctionnait hier et ne fonctionne plus aujourd’hui n’a pas changé par magie.

Il peut y avoir eu une mise à jour, un déploiement, une modification de certificat, un changement de configuration ou une nouvelle règle de pare-feu.

Il est donc pertinent de commencer par :

git status

git diff

Si la configuration est versionnée, on peut aussi examiner les commits récents :

git log --since="2 days ago" --oneline

Sur les serveurs Debian ou Ubuntu, il est aussi utile de consulter les logs d’APT et dpkg ; pour les distributions basées sur RPM, des historiques équivalents existent.

Dans un contexte professionnel, l’historique des déploiements via CI/CD, Ansible ou autres plateformes automatisées est encore plus révélateur.

Poser la question “qu’est-ce qui a changé ?” est souvent une meilleure stratégie que de chercher immédiatement une cause complexe.

journalctl est encore plus utile quand il est filtré

Une erreur fréquente est d’exécuter :

journalctl -xe

et de se retrouver avec des centaines ou des milliers de lignes.

Le problème peut s’y cacher, mais c’est seulement une partie de l’histoire.

Il est souvent plus judicieux de cibler la recherche :

Logs uniquement pour nginx :

journalctl -u nginx

Les vingt dernières minutes :

journalctl -u nginx --since "-20 min"

Les erreurs du dernier démarrage :

journalctl -p err -b

Les messages du kernel :

journalctl -k -b

Et, particulièrement utile si le serveur vient de redémarrer :

journalctl -b -1

qui permet d’accéder au démarrage précédent et d’investiguer ce qui s’est passé avant que le système ne reprenne son activité.

Vérifier rapidement les services en panne

Une autre commande simple peut révéler des problèmes oubliés :

systemctl --failed

Elle liste les unités systemd dans l’état failed.

Ce peut être un service secondaire, un montage, une tâche de démarrage ou un composant qui n’a pas encore signalé de problème visible.

Il est prudent de l’inspecter avant de l’effacer avec :

systemctl reset-failed

Encore une fois, la règle est de ne pas effacer une piste sans l’avoir comprise.

Réseau, disques et performances : vérifier ce qui se passe réellement

ss confirme quels ports sont à l’écoute

Si une application doit fonctionner sur le port 443, il est possible de vérifier :

ss -lntp

Cette commande montre les sockets TCP en écoute, avec, si autorisé, les processus associés.

Pour UDP :

ss -lunp

Pour des connexions TCP actives :

ss -tnp

Ces commandes aident à distinguer plusieurs types de problèmes.

Si rien ne s’affiche pour :443, cela signifie probablement que le service n’écoute pas.

Si cela affiche :

127.0.0.1:443

alors que l’accès doit se faire depuis une autre machine, peut-être le service est-il lié uniquement à localhost.

Avant de suspecter des routeurs, pare-feux externes ou fournisseurs cloud, il vaut mieux vérifier ce qui se passe sur le serveur lui-même.

df ne donne pas toute l’histoire du stockage

Presque tout administrateur connaît :

df -h

Cela permet de connaître l’espace utilisé. Mais un système moderne peut avoir des partitions, volumes LVM, disques cloud, NFS, montages bind ou stockage via des conteneurs.

Pour voir tous les appareils :

lsblk

Pour inspecter les montages :

findmnt

Et pour répondre à une question précise, comme où se trouve réellement /var/lib/docker :

findmnt --target /var/lib/docker

Ce qui aide à distinguer disque physique, partition, système de fichiers et point de montage. Ce sont des concepts liés mais non identiques.

Cela permet également d’éviter des erreurs graves lorsque plusieurs disques portent des noms similaires.

Une image ponctuelle du CPU ne suffit pas toujours à expliquer un problème

top montre l’état actuel.

Mais une machine peut avoir un problème qui apparaît seulement pendant cinq secondes toutes les minutes.

C’est là qu’utilisent des outils comme :

vmstat 1

Chaque seconde, ils donnent des informations sur le CPU, la mémoire, les processus, le swap et l’activité d’entrée/sortie.

Si sysstat est installé, une autre commande utile est :

iostat -xz 1

Elle permet d’observer en détail l’activité des dispositifs de stockage.

Les différences sont simples :

top indique ce qui se passe maintenant.

Une série de mesures peut révéler le motif qui cause le problème.

Quand l’application ne donne pas d’indication, il faut regarder le noyau

Il existe des situations où le service ne signale qu’une erreur, sans expliquer la cause.

Dans ce cas, le noyau peut fournir la pièce manquante.

Par exemple :

journalctl -k -b

Ce qui peut révéler des problèmes sur les disques, la mémoire, les pilotes ou les interfaces réseau.

Si un processus disparaît sans explication apparente, il peut aussi être utile de vérifier la pression mémoire ou la présence de l’OOM killer.

Un dysfonctionnement apparemment lié à l’application pourrait en réalité être causé par le système d’exploitation.

Les habitudes les plus importantes se prennent avant d’appuyer sur Entrée

Linux permet beaucoup avec une seule ligne de commande.

C’est une force, mais aussi un risque.

Par exemple :

find /backup -type f -mtime +30 -delete

cette ligne supprime directement tous les fichiers correspondant.

Il est conseillé de tester la sélection sans supprimer qu’au préalable :

find /backup -type f -mtime +30 -print

Si le résultat est correct, alors on peut ajouter -delete.

Ceci s’applique aussi à rsync.

Avant d’exécuter :

rsync -a --delete /source/ /destination/

il est prudent de faire une simulation :

rsync -a --delete --dry-run /source/ /destination/

--dry-run permet de voir ce qui serait modifié sans appliquer réellement.

Ce petit réflexe évite de perdre des données importantes.

Valider une configuration avant de la recharger

Supposons qu’on modifie la configuration de nginx.

Plutôt que de modifier directement puis de redémarrer, il est plus sûr de tester :

nginx -t

Et, en cas de succès :

systemctl reload nginx

Ceci permet une autre séquence de travail recommandée :

modifier
valider
comparer
recharger
vérifier

plutôt que :

modifier
redémarrer
attendre

Et, dans la mesure où un service supporte la commande reload sans problème, il est préférable de l’utiliser plutôt qu’un redémarrage complet.

kill -9 doit être considéré en dernier recours

Quand un processus semble bloqué, il peut être tentant d’utiliser directement :

kill -9 PID

Mais SIGKILL termine le processus immédiatement, sans possibilité de nettoyage.

Il vaut mieux commencer par :

kill PID

qui envoie SIGTERM.

Et, avant d’utiliser l’une ou l’autre commande, il est utile de vérifier le processus concerné avec :

ps -fp PID

Il est aussi possible d’obtenir des détails complémentaires :

cat /proc/PID/status

Il y a des moments où kill -9 est nécessaire, mais il faut se souvenir que c’est une solution de dernier recours.

L’habitude est de ne pas utiliser l’action la plus brutale en premier.

Automatiser efficacement, c’est plus que rédiger un script

De nombreux scripts fonctionnent parfaitement lorsqu’on les exécute manuellement, mais échouent lorsqu’ils sont lancés via cron ou systemd.

La cause réside souvent dans l’environnement d’exécution.

Une fenêtre de terminal peut disposer d’un PATH, de variables, de clés SSH ou d’un répertoire de travail qui n’existent pas quand ils sont lancés automatiquement.

Au lieu de :

python backup.py

il est plus sûr de spécifier le chemin complet :

/usr/bin/python3 /opt/scripts/backup.py

Il est également essentiel de définir explicitement l’environnement dont le script a besoin, sans dépendre d’aliases personnels.

Vérifier si une commande a réussi

Bash utilise les codes de sortie pour cela.

À la suite d’une commande, on peut consulter :

echo $?

La valeur 0 indique généralement le succès.

Dans un script, il est préférable de vérifier directement la réussite :

if rsync -a /data/ /backup/data/; then
    echo "Sauvegarde terminée"
else
    echo "Échec de la sauvegarde" >&2
    exit 1
fi

Ainsi, le résultat fait partie intégrante de la logique du script.

Une sauvegarde n’est considérée comme correcte que si le script se termine sans erreur.

set -e ne résout pas tous les problèmes

On trouve fréquemment :

set -e

pour faire arrêter un script en cas d’échec.

Cela peut être utile, mais Bash comporte plusieurs exceptions.

Une configuration courante est :

set -Eeuo pipefail

Le paramètre pipefail est particulièrement intéressant dans les pipelines.

Par exemple :

grep "error" fichier-inexistant | sort

Sans pipefail, cette commande peut ne pas signaler d’erreur si sort réussit alors que grep a échoué.

Malgré tout, aucune option ne remplace une gestion explicite des erreurs dans des automatisations importantes.

Mieux vaut automatiser la vérification que la réparation

L’automatisation ne doit pas toujours viser à corriger automatiquement.

Parfois, il suffit simplement d’envoyer une alerte.

Par exemple :

systemctl is-active --quiet nginx || echo "nginx n’est pas actif"

Ensuite, il est possible de vérifier automatiquement :

• l’espace disque disponible ;
• les sauvegardes récentes ;
• les certificats proches de l’expiration ;
• les montages obligatoires ;
• les services en panne ;
• les ports en écoute ;
• l’état du RAID ;
• l’heure de synchronisation.

Redémarrer automatiquement un service à chaque alerte peut masquer une panne pendant des mois.

Le fait de la détecter et d’enregistrer son état permet de mieux analyser la cause.

Prendre un instantané du système avant d’intervenir

Un script de diagnostic peut rapidement collecter des informations essentielles :

date
hostname
uptime
free -h
df -h
lsblk
systemctl --failed
ss -lntp
journalctl -p err -b --no-pager

Et puis, en sauvegardant ces données :

/opt/tools/capture-state.sh > "/var/tmp/state-$(date +%Y%m%d-%H%M%S).log" 2>&1

Si besoin, un redémarrage du service ou même du serveur entier laissera une trace de l’état antérieur, très utile en cas de problèmes complexes.

L’habitude qui ne nécessite pas de terminal : consigner ce qui a été appris

Chaque problème résolu peut devenir une ressource de référence future.

Une simple fiche devrait comporter :

• ce qui est arrivé ;
• quand cela a commencé ;
• ce qui a changé ;
• les logs consultés ;
• les commandes qui ont aidé ;
• la cause ;
• la solution ;
• comment détecter le problème plus tôt la prochaine fois.

Il n’est pas nécessaire d’utiliser une plateforme particulière. Un dépôt privé Git avec des documents Markdown peut devenir, avec le temps, une petite base de connaissances sur les problèmes concrets rencontrés dans une infrastructure.

Ce qui a un grand avantage : éviter que, six mois plus tard, quelqu’un doive redécouvrir la même solution.

L’expérience d’un bon administrateur repose aussi sur ses procédures consignées.

Linux privilégie la méthode plutôt que la rapidité

Deux personnes peuvent connaître exactement les mêmes commandes.

L’une agit ainsi :

redémarrer
tester
changer quelque chose
retester

Et l’autre :

observer
sauvegarder les preuves
délimiter
formuler une hypothèse
la tester
changer le moins possible
vérifier

Ce dernier mode de faire ne présume pas une meilleure connaissance de Linux, mais définit une méthode plus efficace.

Ce mode d’administration reste pertinent même avec Prometheus, Grafana, OpenTelemetry, Kubernetes ou d’autres plateformes sophistiquées d’observabilité en arrière-plan.

Lorsque quelque chose ne tourne pas rond, il faut toujours poser des questions concrètes : quels processus tournent, quels ports sont ouverts, qu’est-ce qui a changé, quelle partition est remplie, ou que le noyau a écrit avant que tout commence à dysfonctionner.

Les commandes facilitent ces réponses.

Les bonnes habitudes permettent de se poser les bonnes questions avant de modifier le système.

Questions fréquentes

Que faut-il vérifier en premier quand un serveur Linux ne fonctionne plus ?

Cela dépend du problème, mais consulter systemctl status, journalctl, systemctl --failed, ss, df, free et findmnt permet d’obtenir rapidement une vision d’ensemble de l’état du système.

Pourquoi ne pas redémarrer immédiatement un service ?

Parce que cela modifie l’état et peut masquer certains éléments, ce qui complique la recherche de la cause initiale. Il faut d’abord recueillir des preuves.

À quoi sert --dry-run ?

Il permet de simuler certaines opérations sans réellement appliquer leurs modifications, comme dans le cas de rsync, pour voir quels fichiers seraient copiés ou supprimés.

Est-ce que set -e suffit pour sécuriser les scripts Bash ?

Non. Bien qu’il puisse arrêter un script en cas d’erreur, Bash comporte plusieurs exceptions. Il est conseillé de vérifier explicitement les résultats et d’utiliser aussi des options comme pipefail.

Sources :

• Documentation officielle de systemd : systemctl, journalctl, systemd-analyze.
• Guide de référence de GNU Bash.
• Projet util-linux : documentation de lsblk et findmnt.
• iproute2 : documentation de ss.
• Procps-ng et sysstat : outils pour le diagnostic et la surveillance des performances.