Les commandes que j'exécute avant de dépanner tout système Linux

Résumé rapide

• Avant de dépanner tout système Linux, exécutez un petit ensemble de commandes en lecture seule pour capturer l'état actuel du système avant que toute intervention ne perturbe les preuves.
• Les contrôles essentiels sont : identité du système (hostnamectl, uname -a), pression sur les ressources (top, free -h, df -h, df -i), erreurs récentes (journalctl -p 3 -xb), services en échec (systemctl --failed) et état du réseau (ip a, ss -tulnp).
• Observez d'abord, ne changez rien, et laissez le système vous dire ce qui ne va pas.

Introduction

Après des années à gérer des systèmes Linux en production, j'ai appris que la plupart des problèmes ne sont pas complexes. Ils sont simplement mal observés.

Lorsqu'un système arrive pour un dépannage, je ne cherche pas immédiatement des solutions. Je jette d'abord un coup d'œil rapide au système. En une minute ou deux, je sais généralement où se situe le problème. Pas la solution exacte, mais la direction.

Avant de commencer

Votre système utilise-t-il systemd ?

La plupart des distributions Linux modernes, telles qu'Ubuntu 16.04+, Debian 8+, RHEL/CentOS 7+, Fedora 15+, utilisent systemd comme leur système d'initialisation.

Pour vérifier, exécutez :

ps -p 1 -o comm=

Exemple de sortie :

Si la sortie est systemd, vous êtes sur un système basé sur systemd et toutes les commandes de ce guide s'appliquent. Si elle affiche init ou sysvinit, utilisez les commandes de secours indiquées dans chaque section.

Besoin d'accès root ?

Certaines commandes renvoient une sortie incomplète pour les utilisateurs réguliers. En cas de doute, préfixez les commandes par sudo. Les membres des groupes systemd-journal, adm ou wheel peuvent lire les journaux système sans accès root complet.

Référence rapide : L'ensemble complet des commandes

Pour les administrateurs qui veulent les commandes sans les explications. Si vous êtes nouveau dans l'administration Linux, ignorez ce bloc et lisez le guide complet ci-dessous — le contexte compte plus que la rapidité.

# 1. System identity
hostnamectl; uname -a; cat /etc/os-release; whoami; uptime; date
# 2. Resource pressure
top -b -n1 | head -20
free -h && df -h && df -i
# 3. Logs — errors from current boot
journalctl -p 3 -xb
# 4. Service failures
systemctl --failed
journalctl -p 3 -b -1     # also check previous boot
# 5. Disk layout and mounts
lsblk && mount | column -t
# 6. Network
ip a; ip route
ss -tulnp
ping -c 3 8.8.8.8
# 7. Recent activity
last -n 5; who
ps aux --sort=-%cpu | head
# 8. Session logging — run this FIRST on production systems
script troubleshoot.log
# ... run your diagnostic commands ...
# When finished, type: exit
# Then immediately set permissions:
chmod 600 troubleshoot.log

Étape 1 : Établir l'identité du système

La première chose que je veux, c'est une idée de ce à quoi j'ai affaire.

hostnamectl
uname -a
cat /etc/os-release
whoami
uptime
date

Cela prend trente secondes.

La commande hostnamectl fournit le système d'exploitation, le noyau et le nom d'hôte en une seule fois.

uname -a confirme l'architecture du processeur.

Et la commande cat /etc/os-release remplit le nom et la version de la distribution.

Ces trois éléments ensemble vous indiquent dans quel environnement vous vous engagez avant de supposer quoi que ce soit.

uptime montre depuis combien de temps le système fonctionne et sa charge moyenne actuelle. date confirme que l'horloge du système est correcte.

Ce qu'il faut rechercher :

• Un horodatage de redémarrage très récent dans uptime est une constatation en soi — quelque chose a causé ce redémarrage.
• Des moyennes de charge supérieures au nombre de cœurs CPU (indiqué dans nproc) indiquent que le système est en situation de stress.
• Une sortie date qui est en retard ou en avance de quelques minutes ou heures par rapport à l'heure réelle signifie qu'un dérive du temps est présente. Même quelques minutes de dérive perturbent silencieusement la validation des certificats TLS, l'authentification Kerberos, la planification des tâches cron et les horodatages des journaux sur les systèmes.

Exemple d'une sortie uptime préoccupante :

up 3 minutes, 1 user, load average: 0.02, 0.08, 0.03

Trois minutes de fonctionnement sur un serveur qui devrait fonctionner en continu — quelque chose a provoqué un redémarrage récent.

Étape 2 : Vérifier la pression des ressources système

Avant de plonger dans les logs, je veux éliminer immédiatement les causes profondes les plus courantes.

top -b -n1 | head -20
free -h
df -h
df -i

Ce que chaque commande vous indique :

top -b -n1 | head -20 exécute top en mode batch (non interactif), prend un instantané et affiche les 20 premières lignes.

Jetez un œil à ce qui suit :

• %Cpu(s) : si sy (système) ou wa (attente E/S) est élevé, le noyau est sous stress.
• charge moyenne : trois nombres montrant le nombre moyen de processus en attente d'exécution au cours des 1, 5 et 15 dernières minutes. Une valeur constamment supérieure au nombre de cœurs de votre CPU est un problème.
• La liste des processus : tout ce qui consomme un %CPU ou un %MEM anormalement élevé.

free -h affiche l'utilisation de la RAM et de la mémoire swap en tailles lisibles par l'homme (Mo/Go).

              total        used        free      shared  buff/cache   available
Mem:           15Gi        12Gi       512Mi       256Mi       2.5Gi       2.8Gi
Swap:           2Gi         2Gi          0B

L'utilisation du swap à 100 % avec presque aucune RAM disponible signifie que le système est à court de mémoire et échange tout sur le disque - une cause courante de lenteur extrême.

df -h montre l'espace disque pour chaque système de fichiers monté.

Filesystem      Size  Used Avail Use%  Mounted on
/dev/sda1        20G   20G     0  100% /

Un système de fichiers à 100 % est l'une des causes les plus courantes de pannes en cascade. Les services qui ne peuvent pas écrire de journaux, de fichiers temporaires ou d'enregistrements de base de données vont planter ou se comporter de manière imprévisible.

df -i affiche l'utilisation des inodes. Un inode est une structure de données que le système de fichiers utilise pour suivre les métadonnées de chaque fichier. Sur les systèmes de fichiers ext4, le nombre d'inodes est fixé au moment du formatage. Lorsque tous les inodes sont utilisés, le système ne peut pas créer de nouveaux fichiers — même si des gigaoctets d'espace disque restent libres. Cela produit la même erreur « espace insuffisant sur le périphérique » qu'un disque plein, sans cause évidente dans df -h.

Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda1      1310720 1310720      0  100% /

Utilisation de % à 100 % avec un espace disque libre=épuisement des inodes. Remarque : cela n'affecte que ext4. XFS et btrfs allouent les inodes de manière dynamique et n'ont pas cette limite.

Si top n'est pas disponible, utilisez plutôt cette commande :

ps aux --sort=-%cpu | head

Lecture recommandée :

• Analyse de l'espace disque simplifiée : Comprendre les commandes df et du sous Linux
• Pourquoi chaque administrateur Linux devrait surveiller le répertoire /var

Étape 3 : Lire d'abord les journaux

Une fois que je sais que le système n'est pas manifestement à court de ressources, je vais directement aux journaux. C'est là que proviennent la plupart des réponses.

systemd est le système d'init et le gestionnaire de services utilisé par la plupart des distributions Linux modernes. Il conserve un journal structuré appelé le journal, consultable avec journalctl.

journalctl -p 3 -xb

Décomposer les drapeaux :

• -p 3 — filtrer par niveau de priorité 3 (erreur) et supérieur. Linux utilise les niveaux de priorité syslog où un nombre plus bas=une gravité plus élevée : 0=emerg, 1=alert, 2=crit, 3=err. Ce paramètre affiche uniquement les quatre niveaux les plus graves.
• -x — ajouter un contexte explicatif aux entrées de journal lorsque disponible.
• -b — afficher uniquement les entrées du démarrage actuel. Sans cela, vous voyez tout l’historique.

À quoi ressemble une entrée préoccupante :

Apr 10 14:32:01 hostname kernel: Out of memory: Killed process 1234
Apr 10 14:32:01 hostname systemd[1]: nginx.service: Main process exited
Apr 10 14:32:01 hostname systemd[1]: nginx.service: Failed with result

Cela vous indique que le noyau a manqué de mémoire, a tué un processus, et que nginx est tombé en conséquence. C'est votre cause principale en trois lignes.

Lisez quelques lignes avant et après chaque erreur. Les motifs comptent plus que les messages isolés. Une erreur à 3 heures du matin est différente de la même erreur qui se répète toutes les 30 secondes.

Messages du noyau (matériel, erreurs de disque, problèmes de pilote) :

# Note: -T timestamps may be inaccurate on systems
# that have been suspended or resumed since last boot.
dmesg -T | tail -50

Le drapeau -T convertit les horodatages bruts relatifs au démarrage en dates et heures lisibles par l'homme. Cependant, cette conversion peut être inexacte sur toute machine qui a été suspendue depuis son dernier démarrage complet — la source de temps du noyau n'est pas mise à jour pendant la suspension/reprise. Si vous diagnostiquez un ordinateur portable ou tout système qui se met en veille, utilisez journalctl pour des horodatages fiables à la place.

Sur les systèmes sans systemd, lisez directement les fichiers journaux :

cat /var/log/syslog      # Debian / Ubuntu
cat /var/log/messages    # RHEL / CentOS / Fedora

Que faire avec ce que vous trouvez : Si le journal indique qu’un service spécifique plante, qu’il y a une erreur de disque ou un échec de permission — c’est votre point de départ. Passez à l’Étape 4. Si le journal ne montre rien du tout, élargissez le filtre avec journalctl -p 5 -xb (inclut les avertissements) ou vérifiez les journaux spécifiques aux applications sous /var/log/.

Lecture recommandée :

• Comprendre les journaux système Linux : Guide du débutant

Étape 4 : Identifier les services défaillants

systemd suit l'état de chaque service. Lorsqu'un service plante et ne se rétablit pas, il entre dans un état échec et y reste jusqu'à ce qu'il soit réinitialisé manuellement. Cette commande liste tous les services actuellement dans cet état.

systemctl --failed

Sortie système saine :

0 loaded units listed.

Sortie du système malsaine :

  UNIT                 LOAD   ACTIVE SUB    DESCRIPTION
● nginx.service        loaded failed failed A high performance web server
● postgresql.service   loaded failed failed PostgreSQL RDBMS
LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state.
SUB    = The low-level unit activation state.
2 loaded units listed.

Deux services ont échoué avec une seule commande. Cela vous indique immédiatement où chercher.

Mise en garde importante : L'état d'échec est effacé lorsqu'un service est redémarré avec succès ou lorsque quelqu'un exécute systemctl reset-failed. Sur un système que vous héritez, la liste peut déjà être vide même si des échecs se sont produits auparavant. Vérifiez toujours le journal du démarrage précédent également :

journalctl -p 3 -b -1

(-b -1 signifie "le démarrage avant celui en cours.")

Une fois que vous identifiez un service défaillant, allez directement à ses journaux :

journalctl -u nginx.service -b

Remplacez nginx.service par le nom de l'unité en échec. Cela montre tout ce que ce service a enregistré lors du démarrage actuel — beaucoup plus utile que la vue système globale.

Pour avoir une vue plus large de ce qui est actuellement en cours, utilisez cette commande :

systemctl list-units --type=service --state=running

Sur les systèmes sans systemd :

service --status-all

Ensuite, examinez les fichiers pertinents sous /var/log/.

Étape 5 : Inspecter la disposition du disque et les montages

Même si l'espace disque semblait correct à l'étape 2, je regarde de plus près comment le stockage est physiquement organisé.

lsblk
mount | column -t

lsblk liste tous les périphériques de bloc (disques physiques, partitions et volumes logiques) sous forme d'arborescence.

Un serveur en bonne santé pourrait ressembler à :

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   50G  0 disk
├─sda1   8:1    0   49G  0 part /
└─sda2   8:2    0    1G  0 part [SWAP]

Recherchez : des disques manquants (disparus de la liste), des partitions sans point de montage, ou des appareils inattendus.

mount | column -t affiche tous les systèmes de fichiers actuellement montés avec leurs options. Recherchez tout système de fichiers monté avec ro (lecture seule) dans la colonne des options :

/dev/sda1  /  ext4  ro,relatime  0 0

Un système de fichiers monté en lecture seule signifie généralement que le noyau a détecté des erreurs et l'a remonté pour éviter des dommages supplémentaires. Le système semblera fonctionnel jusqu'à ce que quelque chose tente d'écrire — puis tout échoue en même temps sans cause évidente. Vérifiez dmesg -T | tail -50 pour l'erreur de disque sous-jacente. Il peut être nécessaire de préfixer cette commande avec sudo.

Lecture recommandée :

• Comment vérifier l'état du disque sous Linux : Un guide pour débutants

Étape 6 : Vérifier la connectivité réseau (le cas échéant)

Je ne commence pas par le réseautage à moins que les symptômes ne l'indiquent. Quand je le fais :

ip a
ip route
ss -tulnp
ping -c 3 8.8.8.8

ip a liste toutes les interfaces réseau et leurs adresses IP. Cherchez les interfaces qui sont DOWN alors qu'elles devraient être actives, ou les interfaces qui n'ont pas du tout d'adresse IP.

ip route affiche la table de routage. La ligne importante est la route par défaut :

default via 192.168.1.1 dev eth0

L'absence de route par défaut signifie que le système ne peut rien atteindre en dehors de son réseau local.

ss -tulnp liste tous les sockets réseau en écoute avec le processus qui les possède. Cela répond à une question courante : le service est-il réellement à l'écoute sur le port qu'il devrait?

Netid  State   Local Address:Port   Process
tcp    LISTEN  0.0.0.0:80          users:(("nginx",pid=1234))
tcp    LISTEN  0.0.0.0:22          users:(("sshd",pid=5678))

Si nginx est supposé servir sur le port 80 mais n'apparaît pas ici, il ne fonctionne pas — peu importe ce que systemctl status pourrait indiquer.

ping -c 3 8.8.8.8 envoie trois paquets au serveur DNS de Google. Important : un ping échoué ne signifie pas toujours que le réseau est en panne. ICMP (le protocole utilisé par ping) peut être bloqué par un pare-feu tandis que le trafic TCP circule normalement. Utilisez ping pour confirmer la connectivité sortante de base, pas pour diagnostiquer des défaillances spécifiques d'application.

Si les tests de connectivité réussissent mais que rien ne se connecte, vérifiez ensuite les règles de pare-feu et le DNS — pas d'autres tests ping :

iptables -L -n      # Traditional iptables (most systems)
nft list ruleset    # nftables (modern systems — check which applies)

Pour vérifier si votre système utilise iptables ou nftables :

iptables -V         # shows version if present
nft -v              # shows version if present

Pour les problèmes de DNS :

resolvectl status       # Only if systemd-resolved is running
cat /etc/resolv.conf    # Always works — shows configured DNS servers

Lecture recommandée :

• Comment trouver quel service écoute sur un port particulier

Étape 7 : Rechercher des causes humaines ou procédurales

Tous les problèmes ne sont pas matériels ou liés à la configuration. Parfois, quelque chose a changé, ou un processus se comporte mal en ce moment.

last -n 5
who
ps aux --sort=-%cpu | head

last -n 5 affiche les cinq dernières connexions. Si un utilisateur inattendu s'est connecté peu de temps avant que le problème ne commence, c'est un indice qui vaut la peine d'être suivi.

who montre qui est actuellement connecté. Plusieurs sessions actives sur un serveur qui devrait être inoccupé peuvent indiquer un accès non autorisé ou un script de maintenance incontrôlé.

ps aux --sort=-%cpu | head affiche les dix processus consommant le plus de CPU. Un processus légitime devrait être reconnaissable par son nom. Un processus inconnu en haut de cette liste mérite enquête.

Étape 8 : Enregistrez votre session avant d'agir

Si vous êtes sur le point de passer du temps réel à diagnostiquer un problème de production, enregistrez d'abord tout.

script troubleshoot.log

Cela démarre un enregistreur de session. Tout ce que vous tapez et chaque ligne de sortie sont écrits dans troubleshoot.log. Travaillez normalement. Lorsque vous avez terminé, terminez la session en tapant :

exit

Immédiatement après, verrouillez le fichier :

chmod 600 troubleshoot.log

Le journal contiendra tout ce qui est tapé pendant la session, y compris les mots de passe saisis aux invites. Sur un système partagé ou multi-utilisateur, le laisser lisible par tous représente un risque pour la sécurité.

Si un journal de session complet n'est pas pratique, capturez plutôt un instantané de l'état actuel :

( set -x; uname -a; uptime; df -h; df -i; free -h; systemctl --failed ) &> snapshot.txt

Ceci est votre référence horodatée. Si le système plante en cours de diagnostic, vous avez un enregistrement de son état au moment où vous avez commencé.

$ cat snapshot.txt 
+ uname -a
Linux debian13desktop 6.12.74+deb13+1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.74-2 (2026-03-08) x86_64 GNU/Linux
+ uptime
 19:02:23 up  8:02,  2 users,  load average: 0.00, 0.00, 0.00
+ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G     0  3.9G   0% /dev
tmpfs           795M  1.3M  794M   1% /run
/dev/sda1        47G  8.9G   36G  21% /
tmpfs           3.9G   12K  3.9G   1% /dev/shm
tmpfs           5.0M  8.0K  5.0M   1% /run/lock
tmpfs           1.0M     0  1.0M   0% /run/credentials/systemd-journald.service
tmpfs           3.9G   16K  3.9G   1% /tmp
tmpfs           795M  104K  795M   1% /run/user/1001
+ df -i
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
udev           1008030    407 1007623    1% /dev
tmpfs          1017316    743 1016573    1% /run
/dev/sda1      3106880 264616 2842264    9% /
tmpfs          1017316      4 1017312    1% /dev/shm
tmpfs          1017316      4 1017312    1% /run/lock
tmpfs             1024      1    1023    1% /run/credentials/systemd-journald.service
tmpfs          1048576     35 1048541    1% /tmp
tmpfs           203463    148  203315    1% /run/user/1001
+ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       1.4Gi       5.7Gi       6.1Mi       881Mi       6.3Gi
Swap:          2.6Gi          0B       2.6Gi
+ systemctl --failed
  UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.

Ce que vous dit le premier passage

Au moment où vous aurez parcouru ces huit étapes, vous ne devinez plus. Vous avez une direction. Voici comment les conclusions se traduisent en actions suivantes :

Trois cas typiques

Cas 1 : "Le serveur est lent"

Vérifiez df -h. Le système de fichiers racine est à 100 %.

Vérifiez journalctl -p 3 -xb. Le journal est rempli d'erreurs d'écriture et de tentatives de redémarrage du service.

Conclusion : disque plein. Tout le reste — la lenteur, les redémarrages, les erreurs d'application — est un effet en aval. Libérez d'abord de l'espace sur le disque. La « lenteur » se résoudra d'elle-même.

Cas 2 : « Le site web est en panne »

Vérifiez systemctl --failed. nginx.service apparaît dans la liste.

Vérifiez journalctl -u nginx.service -b. Le journal montre :

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

Quelque chose d'autre écoute déjà sur le port 80. Vérifiez ss -tulnp | grep :80 pour le trouver. Résolvez le conflit de port avant de redémarrer nginx.

Cas 3 : « Personne ne peut atteindre le serveur »

Le ping depuis une autre machine échoue. Mais le serveur lui-même semble en bon état.

Vérifiez iptables -L -n. Une règle trop large bloque tout le trafic entrant sauf SSH. Un changement de sécurité récent a introduit la règle sans la tester.

Conclusion : mauvaise configuration du pare-feu. Le serveur est sain — le trafic est supprimé avant d'atteindre un quelconque service.

Ce que les administrateurs expérimentés ne font pas

• Ne redémarrez pas les services sans comprendre le problème. Un service planté laisse des journaux, des vidages mémoire et des fichiers de verrouillage qui expliquent ce qui s'est passé. Un redémarrage efface ces preuves.
• Ne redémarrez pas "juste pour voir si cela aide." Un redémarrage efface la portée du journal du démarrage actuel, donc journalctl -b devient inutile pour ce qui vient de se passer. Lisez toujours les journaux avant de redémarrer.
• Ne modifiez pas la configuration avant de lire les journaux. Vous pourriez résoudre complètement le mauvais problème et aggraver les choses.

Chacune de ces actions détruit des preuves. Une fois qu'elles sont parties, vous devinez au lieu de diagnostiquer.

Le seul processus qui compte

Avec le temps, cela s'est installé dans un schéma simple :

1. Observer : Lisez le système avant de le toucher
2. Réduire le champ : Écartez d'abord les causes courantes
3. Agir : Faites un changement, vérifiez l'effet, répétez

Si la première étape est bien faite, le reste suit naturellement. Sinon, tout devient plus lent et moins fiable.

Questions Fréquemment Posées (FAQ)

Q : Les journaux ne montrent rien d'utile.

A : Élargissez le filtre de priorité. journalctl -p 5 -xb inclut les avertissements (niveaux de gravité 0-5). Si cela ne montre toujours rien, vérifiez les journaux spécifiques aux applications dans /var/log/ — tous les logiciels n’écrivent pas dans le journal systemd. Vérifiez également le démarrage précédent : journalctl -p 3 -b -1.

Q : Le système est lent mais le processeur, la mémoire et le disque semblent tous corrects.

A : Le goulot d'étranglement est probablement l'E/S disque — le système attend que les lectures ou écritures se terminent plutôt que de manquer de CPU ou de RAM.

Installez iostat si ce n'est pas déjà fait :

sudo apt install sysstat # Debian/Ubuntu
sudo dnf install sysstat # RHEL/Fedora

Puis exécutez :

iostat -xz 1 5

Le premier des cinq rapports montre les moyennes depuis le démarrage — ignorez-le. Concentrez-vous sur les rapports 2 à 5. Dans la sortie, la colonne await (mesurée en millisecondes) montre la latence moyenne des E/S par périphérique. Des valeurs supérieures à 20-30 ms sur un disque dur indiquent un problème de stockage.

Sur les SSD et NVMe, concentrez-vous sur await plutôt que sur %util — les disques NVMe peuvent gérer de nombreuses requêtes E/S en parallèle, donc un %util proche de 100 % ne signifie pas nécessairement que le périphérique est saturé.

Q : systemctl --failed est vide mais quelque chose est encore cassé.

A : L'état échoué est réinitialisé par systemctl reset-failed ou un redémarrage réussi. Vérifiez le service directement :

journalctl -u <nom-du-service> -b

Vérifiez également le démarrage précédent : journalctl -p 3 -b -1. Sur les systèmes hérités, quelqu'un a peut-être effacé les échecs avant votre arrivée.

Q : Le disque n'est pas plein mais les écritures échouent toujours.

A : Exécutez df -i. Sur ext4, l'épuisement des inodes produit des erreurs identiques à un disque plein mais n'apparaît pas dans df -h. XFS et btrfs ne sont pas affectés, ils allouent les inodes dynamiquement.

Q : Le réseau semble en ordre mais rien ne se connecte.

A : Les tests de connectivité de base ne racontent pas toute l'histoire. Vérifiez les règles du pare-feu et le DNS :

iptables -L -n # Iptables traditionnel
nft list ruleset # Nftables (systèmes modernes)
resolvectl status # Seulement si systemd-resolved est en cours d'exécution
cat /etc/resolv.conf # Toujours disponible — montre les serveurs DNS

Q : dmesg -T affiche des horodatages qui semblent incorrects.

A : Limitation documentée. La source de temps du noyau n'est pas mise à jour après la suspension et la reprise du système. Sur toute machine suspendue depuis son dernier démarrage complet, les horodatages après le point de reprise seront décalés. Se référer à journalctl pour un chronométrage précis.

Q : Ces commandes peuvent-elles aggraver le problème ?

A : Les étapes 1 à 7 sont entièrement en lecture seule. Elles ne produisent aucun effet secondaire. L'étape 8 (script) écrit un fichier journal sur le disque. Vérifiez simplement que vous disposez d'espace avec df -h d'abord sur un système où le disque pourrait poser problème.

Q : Dois-je exécuter cela en tant que root ?

A : La plupart des commandes fonctionnent en tant qu'utilisateur normal, mais journalctl, ss -tulnp et certaines informations de lsblk renvoient des résultats incomplets sans privilèges élevés. Utilisez sudo en cas de doute.

Q : Que se passe-t-il si le système n’a pas systemd ?

A : Remplacez journalctl -p 3 -xb par cat /var/log/syslog (Debian/Ubuntu) ou cat /var/log/messages (RHEL/CentOS). Remplacez systemctl --failed par service --status-all et examinez manuellement les fichiers sous /var/log/.

Références :

• journalctl(1)
• systemctl(1)
• dmesg(1)
• iostat(1)
• resolvectl(1)
• Gentoo Wiki : Plus d'espace disponible sur le périphérique alors qu'il y a beaucoup d'espace disponible