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 partout, et on s'appuie sur les outils systemd quand ils sont plus lisibles que l'héritage. La présence des commandes a été vérifiée le 1er octobre 2026 sur Debian 13, Ubuntu 24.04 et AlmaLinux 10.2, de même que les sorties d'os-release et de needs-restarting ; les autres exemples viennent d'un relevé plus ancien sur Ubuntu 24.04, où seuls les numéros de version diffèrent.

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

Savoir quelle distribution tourne sur une machine conditionne tout le reste : le gestionnaire de paquets à employer, le nom exact des services et la documentation à ouvrir. 3 sources répondent à la question, et elles ne se valent pas. La première est un fichier standardisé présent partout, la deuxième une commande systemd qui en dit davantage, la troisième un vestige qui n'est plus installé partout. Prenez-les dans cet ordre.

/etc/os-release, canonique moderne

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

cat /etc/os-release

Sortie relevée sur Ubuntu 24.04 (extrait) :

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

Sur AlmaLinux 10.2, de la famille RHEL (Rocky Linux affiche de même ID="rocky") :

NAME="AlmaLinux"
VERSION="10.2 (Lavender Lion)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="10.2"

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

La ligne Virtualization de cette sortie mérite une attention particulière : hostnamectl détecte seul s'il tourne sur une machine physique, dans une VM KVM ou QEMU, dans un conteneur Docker ou LXC, ou chez un hyperviseur cloud. C'est souvent la première chose à établir sur un serveur inconnu, parce qu'elle décide de ce qui est possible : on ne change pas un paramètre de noyau ni un réglage matériel depuis un conteneur.

lsb_release, héritage

Historiquement la commande de référence, lsb_release n'est plus présente partout, et c'est ce qui la disqualifie dans un script : sur Debian 13, son paquet lsb-release est de priorité optional, donc absent d'une installation standard ; sur RHEL 10, aucun paquet ne la fournit plus. Ubuntu 24.04 l'installe encore, le paquet étant de priorité important et requis par ubuntu-minimal. Un script qui fonctionne sur Ubuntu échoue donc ailleurs :

lsb_release -a   # peut renvoyer "command not found"

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

Identifier l'hôte

Le nom d'hôte se lit avec hostname, et ses options se confondent facilement : -A liste les noms complets (FQDN), -I les adresses IP, comme le confirme l'aide de la commande :

hostname          # nom court
hostname -f       # FQDN (Fully Qualified Domain Name)
hostname -A       # tous les FQDN de la machine
hostname -I       # toutes les adresses IP de la machine

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'authentification) 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, chaque famille a son outil :

Ubuntu

# Fichier créé par le paquet update-notifier-common quand un reboot est requis
test -f /var/run/reboot-required && echo "Reboot requis" || echo "OK"

Debian

# Debian ne fournit pas update-notifier-common : needrestart fait ce travail
sudo apt install needrestart
sudo needrestart -k

RHEL / Fedora / Rocky

# needs-restarting est fourni par dnf-utils (paquet yum-utils sur RHEL 10)
sudo dnf install -y dnf-utils
sudo needs-restarting -r

Mesuré sur AlmaLinux 10.2, la commande répond No core libraries or services have been updated since boot-up. puis Reboot should not be necessary. avec le code retour 0 ; elle rend le code 1 quand un redémarrage est requis.

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

Ces 4 informations tiennent en une ligne, et chacune répond à une question différente : depuis quand la machine est en service, combien de sessions y sont ouvertes, et si elle est en train de souffrir. Les deux sous-sections ci-dessous détaillent la plus trompeuse des quatre, la charge moyenne, puis donnent les variantes de commande utiles quand uptime ne suffit pas.

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

Quand seule la durée de fonctionnement vous intéresse, deux options d'uptime évitent d'avoir à lire la ligne complète. -p donne une phrase lisible, -s donne l'horodatage exact du dernier démarrage, pratique pour recouper un incident avec l'heure d'un reboot.

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, avec la commande last. Sur Debian 13, elle ne vient plus d'util-linux mais du paquet wtmpdb, de priorité standard, donc présent sur une installation complète mais pas dans une image minimale ; sur Ubuntu 24.04 et AlmaLinux 10, util-linux la fournit toujours :

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

Ces réflexes transforment les commandes de ce guide en une routine d'état des lieux reproductible. Le principe est de privilégier les outils systemd modernes (hostnamectl, systemctl, timedatectl) et les fichiers standardisés (/etc/os-release) plutôt que les commandes héritées qui ne sont plus installées partout. Deux d'entre eux se lancent au tout début d'une intervention, avant de rien modifier, pour photographier l'état de départ.

• 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

Les problèmes rencontrés en identifiant une machine sont rarement des pannes : ce sont le plus souvent des commandes absentes ou une configuration incomplète (FQDN, NTP). Lisez le tableau en partant du message exact affiché. La ligne la plus instructive concerne lscpu qui rapporte Vulnerable sur certaines CVE matérielles : ce n'est pas un faux positif, c'est un noyau dont les mitigations ne sont pas à jour, à traiter comme un vrai écart de durcissement sur un serveur exposé.

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 13, absent de RHEL 10)	Ne pas l'utiliser, lire /etc/os-release à la place
last: command not found sur Debian 13	last vient désormais du paquet wtmpdb	sudo apt install wtmpdb, ou journalctl --list-boots
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 | tail pour voir le boot précédent
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 absentes ou désactivées	Mettre à jour le noyau et le microcode, puis vérifier que /proc/cmdline ne contient pas mitigations=off

Glissez pour voir

À retenir

• /etc/os-release est la source canonique pour distribution + version, à préférer à 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.
• hostname -A liste les FQDN, hostname -I les adresses IP.
• 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.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% 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

×

📖 Voir la documentation →