Activité d’un système Linux

Quand une VM du lab rame, qu’un service ne répond plus, ou qu’un cron n’a « rien fait », je ne commence pas par l’application. Je regarde d’abord ce que le système a écrit dans ses journaux, puis la charge CPU/mémoire/disque, puis qui écoute sur le réseau. Sur Debian et Proxmox, ça tient en un petit jeu de commandes — toujours les mêmes — qui évitent de perdre une heure sur un symptôme alors que le disque est plein ou que SSH a rejeté la clé. Cette page les regroupe dans l’ordre où je les enchaîne.

Lire les journaux

La plupart des traces vivent sous /var/log. Sur Debian/Ubuntu, /var/log/syslog concentre les messages généraux et /var/log/auth.log les connexions, sudo et SSH ; sur les familles RedHat, les équivalents s’appellent souvent /var/log/messages et /var/log/secure. Avec systemd, journalctl est souvent plus direct qu’un grep sur un fichier : on filtre par unité (-u ssh), on demande les dernières lignes, on suit en direct. dmesg reste utile pour le matériel au boot (carte réseau absente, disque qui proteste). last / last reboot et who / w situent qui s’est connecté et ce qui tourne en session.

sudo grep Accepted /var/log/auth.log
sudo journalctl -u ssh -n 50 --no-pager
dmesg | tail
last
w

Sur le lab, c’est typiquement comme ça que je vois qu’un arrêt Proxmox a bien enchaîné les VM, ou qu’un essai SSH depuis le mauvais VLAN a été refusé — avant d’ouvrir UniFi.

Charge, mémoire, disque

top (ou htop s’il est installé) donne une vue live des processus. ps aux | grep … cible un service. uptime affiche la load average ; free -h et df -h répondent à la question bête mais fréquente : est-ce que la machine swap à mort ou que le disque est plein ? J’ai déjà « débogué » une appli pendant vingt minutes alors qu’il ne restait plus d’inode ou d’espace sur /var — depuis, ces deux commandes passent avant les hypothèses savantes.

top
ps aux | grep nom
uptime
free -h
df -h

Qui écoute sur le réseau

Pour voir les ports ouverts et les processus associés, ss -tulpn remplace l’ancien netstat dans mon usage. Couplé à ping et curl -I, ça permet de savoir si le service écoute localement avant d’accuser le firewall ou le DNS. La page Réseau détaille interfaces et routes ; celle-ci ferme la boucle diagnostic : logs → ressources → sockets.

ss -tulpn
ping -c 3 192.168.50.1
curl -I https://…

Retour au parcours Linux ou au homelab selon que tu consolidais le socle ou que tu enchaînes sur UniFi / Proxmox.