Identifier son système Linux

Vous arrivez sur une machine Linux inconnue et vous devez vous repérer. Quelle distribution ? Quelle version de noyau ? Depuis quand tourne-t-elle ? Des services en échec ? Quel CPU, quelle RAM ? Ce guide aligne les commandes modernes qui répondent à ces questions en quelques minutes. On préfère hostnamectl et /etc/os-release aux vieux lsb_release / arch qui ne sont plus installés par défaut, et on s’appuie sur les outils systemd quand ils sont plus lisibles que l’héritage.

Ce que vous allez apprendre

• Identifier la distribution et sa version avec os-release et hostnamectl
• Lire le noyau, l’architecture et le nom d’hôte
• Mesurer l’uptime et interpréter le load average
• Vérifier l’état global systemd et les services en échec
• Faire l’inventaire matériel de base (CPU, mémoire, disques, PCI, USB)
• Analyser le dernier boot avec journalctl et systemd-analyze

Dans quel contexte ?

Trois scénarios concrets :

• Onboarding d’un serveur existant — vous reprenez une machine que vous n’avez pas installée. Premier réflexe : un état des lieux.
• Diagnostic d’incident — un service est lent, un reboot s’est mal passé. Avant tout debug, savoir sur quoi on travaille.
• Audit ou inventaire — écrire un script qui collecte distribution + version kernel + uptime sur un parc hétérogène.

C’est une compétence LFCS (Essential Commands) et RHCSA (Understand and use essential tools).

Prérequis

• Un shell avec droits utilisateur (la plupart des commandes n’exigent pas sudo)
• Un système avec systemd (Ubuntu 16.04+, Debian 8+, RHEL 7+, Rocky, Fedora) — pour les commandes hostnamectl, timedatectl, systemctl
• Les outils util-linux (présent par défaut partout) pour lscpu, lsblk

Identifier la distribution

Trois sources, dans l’ordre de préférence.

/etc/os-release — canonique moderne

Présent sur toutes les distributions systemd. Standardisé par systemd, lisible et parsable :

cat /etc/os-release

Sortie typique sur Ubuntu 24.04 :

PRETTY_NAME="Ubuntu 24.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.2 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian

Sur RHEL / Rocky :

NAME="Rocky Linux"
VERSION="9.4 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.4"

Les champs ID, VERSION_ID et ID_LIKE sont ce qu’on utilise dans les scripts pour écrire du code conditionnel par distribution.

hostnamectl — la vue systemd

hostnamectl donne une synthèse plus large : distribution, noyau, architecture, virtualisation, hôte — le tout en une commande :

hostnamectl

 Static hostname: master2
       Icon name: computer-vm
         Chassis: vm
      Machine ID: e84a5b...
         Boot ID: 3f21a0...
  Virtualization: kvm
Operating System: Ubuntu 24.04.2 LTS
          Kernel: Linux 6.8.0-58-generic
    Architecture: x86-64

Le champ Virtualization

hostnamectl détecte automatiquement si vous êtes sur du bare metal, dans une VM KVM/QEMU, un conteneur Docker/LXC ou un hyperviseur cloud. Pratique pour savoir où on est en une commande.

lsb_release — héritage

Historiquement la commande de référence, mais plus installée par défaut sur Debian 12, Ubuntu 24.04 ou RHEL 10. À éviter dans les scripts modernes :

lsb_release -a   # peut renvoyer "command not found"

Remplacez-le par cat /etc/os-release partout où vous le croisez.

Identifier l’hôte

hostname          # nom court
hostname -f       # FQDN (Fully Qualified Domain Name)
hostname -A       # toutes les adresses IP associées au FQDN

Modifier le nom d’hôte de façon persistante (systemd) :

sudo hostnamectl set-hostname admin-prod-01

Trois variantes utiles :

sudo hostnamectl set-hostname admin-prod-01 --static    # permanent (défaut)
sudo hostnamectl set-hostname "Poste Admin Stéphane" --pretty  # libellé humain
sudo hostnamectl set-hostname admin-prod-01 --transient # éphémère, réinitialisé au reboot

Persistance de l'ancien hostname

Après un changement de hostname, vérifiez /etc/hosts — des entrées en dur pointant vers l’ancien nom peuvent casser des services (Nginx, Postfix, outils d’auth) tant qu’elles ne sont pas mises à jour.

Identifier le noyau et l’architecture

La commande uname expose tout ce qu’il faut en une ligne :

uname -a

Linux master2 6.8.0-58-generic #60-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar 14 18:29:48 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Options ciblées :

Option	Ce qu’elle affiche	Cas d’usage
-r	Version du noyau (6.8.0-58-generic)	Vérifier si un reboot post-upgrade est nécessaire
-m	Architecture (x86_64, aarch64)	Choisir la bonne image Docker, le bon binaire
-n	Nom d’hôte court	Alternative à hostname
-v	Date de compilation du noyau	Vérifier l’âge du noyau installé

Glissez pour voir

La commande arch (qui affiche uniquement l’équivalent de uname -m) existe encore mais n’apporte rien — préférer uname -m.

Pour vérifier si un reboot est nécessaire après une mise à jour de noyau :

Debian / Ubuntu

# Un fichier est créé par APT quand un reboot est requis
test -f /var/run/reboot-required && echo "Reboot requis" || echo "OK"

RHEL / Fedora / Rocky

# needs-restarting est fourni par dnf-utils
sudo dnf install -y dnf-utils
sudo needs-restarting -r

Uptime et charge

uptime

 18:29:45 up 5 days,  2:15,  1 user,  load average: 0.00, 0.01, 0.05

La ligne expose :

• heure courante
• uptime (durée depuis le dernier boot)
• nombre de sessions ouvertes
• load average sur 1, 5 et 15 minutes

Interpréter le load average

Le load average indique le nombre moyen de processus en attente d’un CPU ou d’une ressource (I/O). Divisez-le par le nombre de cœurs (nproc) pour obtenir un ratio :

echo "Cores: $(nproc)   Load: $(uptime | awk -F'load average:' '{print $2}')"

Ratio load / nproc	Interprétation
< 0.7	Marge confortable
0.7 – 1.0	Chargé mais OK
> 1.0 soutenu	Contention — des processus attendent

Glissez pour voir

Pour un diagnostic complet, enchaîner avec Évaluer les performances système qui détaille la méthode USE.

Variantes utiles

uptime -p       # format humain : "up 5 days, 2 hours"
uptime -s       # date de boot exacte : "2026-04-20 16:14:30"

État global systemd

Une commande dit si la machine va bien :

systemctl is-system-running

Sorties possibles : running (tout va bien), degraded (au moins un service en échec), starting, stopping, maintenance, offline.

En cas de degraded, lister les fautifs :

systemctl list-units --failed

Sessions utilisateur ouvertes :

loginctl list-sessions
loginctl list-users

Configuration date et fuseau horaire :

timedatectl

               Local time: Fri 2026-04-25 14:30:12 CEST
           Universal time: Fri 2026-04-25 12:30:12 UTC
                 RTC time: Fri 2026-04-25 12:30:12
                Time zone: Europe/Paris (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Les lignes System clock synchronized et NTP service sont ce qu’on vérifie après un reboot pour confirmer que l’heure est d’aplomb.

Logs et analyse du dernier boot

journalctl permet d’isoler les logs d’un boot spécifique :

# logs du boot courant
journalctl -b

# logs du boot précédent
journalctl -b -1

# liste des boots disponibles avec leurs IDs
journalctl --list-boots

systemd-analyze donne le temps de démarrage détaillé :

# vue globale
systemd-analyze

# Startup finished in 3.481s (kernel) + 41.225s (initrd) + 1min 14.060s (userspace) = 1min 58.766s

# top 10 des services les plus lents au boot
systemd-analyze blame | head -10

# graphique SVG des dépendances (utile post-mortem)
systemd-analyze plot > boot.svg

Historique des reboots :

last reboot | head -5
last -x shutdown | head -5

Inventaire matériel rapide

Cinq commandes pour balayer le matériel d’une machine en 30 secondes.

CPU — lscpu

lscpu

Expose architecture, modèle de processeur, nombre de cœurs, fréquence, cache, mitigations CPU (Spectre/Meltdown). Les lignes à retenir :

• Architecture : x86_64, aarch64, armv7l…
• CPU(s) : total logique (cœurs × threads/cœur)
• Core(s) per socket, Thread(s) per core : topologie réelle
• Model name : modèle précis
• Vulnerabilities: : état des mitigations par CVE

Mémoire — free -h

free -h

Détaillé dans Diagnostiquer la mémoire sous Linux. Pour un premier coup d’œil, la colonne available est la bonne métrique — pas free.

Disques — lsblk

lsblk

Arbre des périphériques bloc (disques, partitions, LVM, LUKS). Complété par :

lsblk -f   # avec systèmes de fichiers et UUID
df -hT     # espace utilisé par point de montage

PCI — lspci

lspci | head -20

Cartes réseau, contrôleurs disque, GPU, tout le matériel PCI. Pour les détails d’un périphérique :

lspci -v -s 00:1f.6   # mode verbose sur un slot précis

USB — lsusb

lsusb

Périphériques USB actuellement connectés. Utile pour vérifier la détection d’une clé, d’un lecteur de carte ou d’un Yubikey.

Virtualisation — systemd-detect-virt

systemd-detect-virt

Retourne kvm, qemu, vmware, docker, lxc, oracle (VirtualBox), ou none si bare metal. Équivalent rapide du champ Virtualization de hostnamectl.

Bonnes pratiques

• hostnamectl avant tout sur un système systemd — c’est la vue synthétique la plus rapide.
• os-release dans les scripts, jamais lsb_release. Il est présent partout et parsable avec . /etc/os-release puis $ID, $VERSION_ID.
• systemctl is-system-running au début de chaque intervention — vous voyez tout de suite si un service est déjà tombé avant que vous ne touchiez quoi que ce soit.
• Comparer uname -r avec le dernier kernel installé après une mise à jour — si différents, un reboot est nécessaire.
• timedatectl systématique après un reboot ou un changement de fuseau : heure synchro, NTP actif.
• lscpu et free -h dans un script de baseline déposent un inventaire plat utile pour l’audit.

Dépannage rapide

Symptôme	Cause probable	Action
hostnamectl: command not found	Système sans systemd ou shell restreint	Fallback : uname -n + cat /etc/os-release
lsb_release: command not found	Paquet non installé (défaut sur Debian 12+, RHEL 10)	Ne pas l’utiliser, lire /etc/os-release à la place
hostname -f ne renvoie rien	FQDN non configuré dans /etc/hosts ou DNS	Ajouter une ligne dans /etc/hosts avec le FQDN
uptime montre up 0:01 après un reboot inattendu	La machine a été redémarrée (panne ou OOM killer)	`journalctl -b -1
systemctl is-system-running retourne degraded	Un service ou un mount a échoué	systemctl --failed pour la liste
timedatectl indique NTP service: inactive	Pas de synchro NTP active	sudo systemctl enable --now systemd-timesyncd ou chronyd
lscpu affiche Vulnerable sur plusieurs CVE	Mitigations kernel non activées	Mettre à jour le kernel ; pour un serveur exposé, ajouter les kernelParams ANSSI-BP-028

Glissez pour voir

À retenir

• /etc/os-release est la source canonique pour distribution + version — préfère à lsb_release partout.
• hostnamectl donne en une commande : hôte, noyau, architecture, virtualisation, OS.
• uname -r / -m / -n pour lire le noyau, l’architecture et le nom court.
• uptime : divisez le load average par nproc pour l’interpréter.
• systemctl is-system-running puis --failed sont le duo pour vérifier la santé globale.
• timedatectl vérifie heure, fuseau et synchro NTP en une commande.
• journalctl -b -1 donne les logs du boot précédent — essentiel après un crash.
• systemd-analyze blame liste les services les plus lents au démarrage.
• Inventaire matériel : lscpu, free -h, lsblk, lspci, lsusb.

Prochaines étapes

Évaluer les performances système Approfondir après la vue d'ensemble : méthode USE, diagnostic CPU / mémoire / disque / réseau.

Diagnostiquer la mémoire Aller plus loin sur la mémoire : `available`, OOM killer, swap, pression mémoire.

Arrêter et redémarrer Commandes shutdown, reboot, rescue mode, récupération du mot de passe root.

Gérer les logs avec journald Lire journalctl en détail : filtres, persistance, rotation.

×

📖 Voir la documentation →