Comandi Linux per vedere le informazioni di sistema da terminale

Quando devi capire che macchina hai davanti, il terminale è più affidabile del pannello grafico e spesso anche più veloce. Su Linux le informazioni di sistema non arrivano da un solo comando: vanno lette per layer, perché CPU, memoria, storage, kernel, rete e servizi raccontano problemi diversi. L’errore tipico è partire da strumenti “belli” ma poco mirati; il metodo corretto è invece raccogliere prima i dati base e poi scendere nel dettaglio dove serve.

Qui sotto trovi una sequenza pratica di comandi Linux per vedere le informazioni di sistema da terminale. L’obiettivo non è fare una lista sterile, ma darti una traccia operativa: cosa guardare, come interpretarlo e quali output confrontare quando qualcosa non torna.

1. Identificare subito macchina, kernel e architettura

Il primo blocco serve a rispondere a domande banali solo in apparenza: che kernel gira, su quale architettura, con quale hostname e su quale release della distribuzione. Sono dati fondamentali quando devi aprire un ticket, leggere una guida o capire se un problema dipende dal kernel, dalla distro o da un package specifico.

Il comando più rapido è uname:

uname -a

Output atteso: nome kernel, hostname, versione del kernel, data di compilazione, architettura. Se vedi un kernel vecchio rispetto al resto dello stack, hai già un indizio da non ignorare.

Per una vista più leggibile della release Linux, usa anche:

cat /etc/os-release

Qui trovi campi come NAME, VERSION, ID e VERSION_ID. È il modo più pulito per distinguere, per esempio, una Debian 12 da una Ubuntu 22.04 senza interpretare stringhe ambigue.

Se vuoi un riepilogo compatto del sistema, spesso utile in supporto o documentazione interna, puoi usare:

hostnamectl

In un colpo solo ottieni hostname, kernel, architettura, virtualizzazione e spesso informazioni aggiuntive sulla macchina. Su sistemi moderni è uno dei primi comandi da lanciare perché riduce il rischio di interpretare male il contesto.

2. Capire CPU, load average e pressione reale

La CPU non si valuta solo guardando se è “alta” o “bassa”. In Linux devi distinguere fra numero di core, carico medio e saturazione effettiva. Un load average elevato non significa automaticamente CPU al 100%; può voler dire anche attesa I/O o processi bloccati.

Per vedere quanti core e quali caratteristiche hardware sono disponibili:

lscpu

Ti mostra socket, core per socket, thread per core, modello CPU, flag e virtualizzazione. È il comando da usare quando devi capire se una VM ha davvero le risorse che ti aspetti o se stai lavorando con un oversubscription pesante.

Per un dettaglio ancora più grezzo, ma molto utile in troubleshooting hardware o containerizzazione, puoi leggere:

cat /proc/cpuinfo

Qui trovi ogni CPU logica con le sue proprietà. Non è il comando più comodo da leggere a occhio, ma è utile quando vuoi verificare flag specifici, frequenze o mappe NUMA.

Per il carico istantaneo e la visibilità sui processi, il classico è top o, meglio ancora, htop se installato:

top

Con top osserva almeno tre valori: load average, %us/%sy e %wa. Se %wa sale, il collo di bottiglia non è per forza la CPU: spesso è disco o storage remoto. Se il load è alto ma la CPU resta bassa, c’è un problema altrove nel sistema.

Quando vuoi una fotografia rapida del consumo per processo senza entrare subito in sessione interattiva, usa:

ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head

Questo elenco è molto pratico perché ti mostra subito chi consuma CPU e memoria. Se un servizio web sta degradando, spesso il processo responsabile emerge qui prima ancora di aprire i log applicativi.

3. Memoria RAM, swap e segnali di pressione

Per la memoria non basta sapere quanta RAM è installata. Quello che conta è quanta è realmente disponibile, quanta è occupata da cache e quanta swap viene usata. Su Linux la cache non è un problema: è memoria usata bene. Il problema vero è la memoria disponibile che scende e la swap che cresce in modo persistente.

Il comando più utile è:

free -h

Guarda soprattutto available, non solo used. Se available è basso e la swap è attiva, il sistema sta probabilmente entrando in pressione. Se invece la RAM sembra quasi piena ma la cache è alta e la swap è zero, non hai per forza un problema.

Per capire quali processi occupano più RAM, il comando più diretto è:

ps -eo pid,ppid,cmd,%mem,rss --sort=-rss | head

Qui rss è la memoria residente reale. È più utile del solo %mem quando devi confrontare processi lunghi, demoni o worker PHP, Java, Node o database.

Se vuoi una vista per processo ancora più dettagliata, smem è spesso superiore, ma non sempre installato. Quando manca, il passaggio successivo è leggere /proc/<pid>/status o usare strumenti del pacchetto procps. Un esempio rapido:

cat /proc/1234/status

Da lì puoi verificare VmRSS, VmSize e altri indicatori utili. Se un servizio cresce nel tempo senza tornare giù, hai probabilmente un leak o un carico non gestito.

4. Disco, filesystem e spazio reale disponibile

Il disco è uno dei punti in cui Linux inganna più facilmente chi guarda solo la percentuale di utilizzo. Un filesystem può sembrare “quasi pieno” ma avere ancora inode liberi, oppure può risultare pieno per colpa di file cancellati ma ancora aperti da un processo. Devi quindi controllare sia spazio sia inode, poi verificare eventuali file bloccati.

Il comando base è:

df -hT

-h rende leggibile, -T mostra il tipo filesystem. Se vedi una partizione al 100%, non fermarti lì: potrebbe essere un problema di log, backup, cache o database cresciuto fuori controllo.

Per gli inode, che spesso vengono dimenticati:

df -i

Se gli inode sono esauriti, anche con spazio libero il filesystem non può creare nuovi file. È un problema classico su directory con milioni di piccoli oggetti, cache mal gestite o mail spool molto frammentate.

Per trovare dove si sta consumando spazio, il comando pratico è du:

du -xh /var --max-depth=1 | sort -h

Su server applicativi, /var è il primo punto da controllare: log, cache, queue, database, container runtime. Se il problema è in un path specifico, restringi la ricerca con lo stesso approccio.

Per i file cancellati ma ancora aperti, utile quando lo spazio non torna nonostante la rimozione dei file:

lsof +L1

Se compare un processo che tiene aperto un file con link count zero, lo spazio non viene liberato finché quel processo non rilascia il descrittore. In questo caso il fix corretto non è cancellare altro: devi riaprire i log o riavviare il servizio coinvolto, con il dovuto rollback se serve.

5. Rete, interfacce e routing di base

Quando un server “sembra vivo” ma non risponde, spesso il problema è nella rete o in un firewall locale. Devi verificare interfacce, indirizzi, route e socket in ascolto. Anche qui il trucco è non saltare subito alla configurazione: prima osserva lo stato reale del sistema.

Per vedere interfacce e indirizzi IP:

ip addr

Per la tabella di routing:

ip route

Se l’host ha più NIC, VLAN o tunnel, qui capisci subito se la route di default è corretta o se il traffico sta uscendo dall’interfaccia sbagliata.

Per verificare quali porte sono in ascolto e da quali processi:

ss -tulpn

Questo comando è più attuale di netstat e mostra TCP, UDP, listening socket e PID associato. È il controllo minimo quando un servizio non risponde sulla porta attesa o quando vuoi capire se un demone è davvero partito.

Per un test minimo di raggiungibilità verso un host remoto o verso il gateway, usa ping solo come segnale base e non come prova definitiva. Meglio affiancarlo a una richiesta HTTP o a una verifica TCP specifica, per esempio:

curl -I https://example.com

Con curl -I controlli risposta HTTP, redirect, header e tempi di connessione. Se il sito è lento o irraggiungibile, questo comando ti dice almeno se il problema è a livello DNS, TLS, edge o origin.

6. Processi, servizi systemd e stato operativo

Su una distribuzione moderna, systemd è la fonte più affidabile per sapere se un servizio è davvero sano. Un processo può esistere e il servizio essere comunque degradato; viceversa un demone può sembrare fermo ma in realtà essere in restart loop.

Per lo stato di un servizio:

systemctl status nome-servizio

Qui controlla: stato attivo, ultimi log, PID, codice di uscita e eventuali restart. Se il servizio è in failed o activating da troppo tempo, hai già un segnale forte.

Per la visione completa dei servizi avviati:

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

Per i log del servizio, il punto giusto è il journal:

journalctl -u nome-servizio -n 100 --no-pager

Se cerchi un errore temporale, aggiungi il filtro per data. Il vantaggio del journal è che puoi correlare restart, crash e messaggi applicativi senza dover scavare in file sparsi.

7. Hardware, dischi e sensori quando il problema non è software

In ambienti fisici o VM “pesanti”, il problema può essere hardware: errori disco, temperature, throttling, ECC, controller o storage degradato. Quando il sistema mostra sintomi strani e i log applicativi sono puliti, vale la pena controllare il livello fisico.

Per lo stato SMART dei dischi, se disponibile:

smartctl -a /dev/sda

Cerca errori, settori riallocati, pending sector e temperature. Se il disco mostra segnali di degrado, non aspettare il guasto completo: pianifica subito il cambio e il backup.

Per sensori e temperature su sistemi supportati:

sensors

Se la CPU o il controller storage vanno in throttling termico, i sintomi possono sembrare “software lenti” ma la causa è fisica. È un classico errore di diagnosi saltare questo livello.

8. Un flusso pratico per leggere il sistema in meno di due minuti

Se hai bisogno di una sequenza rapida, usa sempre lo stesso ordine. Prima identità della macchina, poi risorse, poi servizi, poi rete. Questo riduce il rumore e ti evita di aprire strumenti a caso.

1. Verifica release e kernel con cat /etc/os-release e uname -a.
2. Controlla CPU con lscpu e carico con top.
3. Leggi RAM e swap con free -h.
4. Controlla spazio e inode con df -hT e df -i.
5. Guarda servizi e log con systemctl status e journalctl -u.
6. Verifica rete e socket con ip addr, ip route e ss -tulpn.

Questo flusso è valido sia su server dedicati sia su VM, container host e ambienti cloud. La differenza la fa il contesto: su un nodo bare metal dai più peso a temperatura, storage e SMART; su una VM dai più peso a CPU steal, memoria e rete virtuale; su un container host devi guardare bene limiti e cgroup oltre ai processi.

9. Comandi utili da tenere pronti nei preferiti

Questa è la cassetta degli attrezzi minima che conviene avere a portata di mano quando devi fare triage o documentare un server. Non serve eseguirli tutti ogni volta, ma sapere dove andare è ciò che fa risparmiare tempo.

uname -a
cat /etc/os-release
hostnamectl
lscpu
free -h
top
df -hT
df -i
ss -tulpn
systemctl status nome-servizio
journalctl -u nome-servizio -n 100 --no-pager
ip addr
ip route
lsof +L1

Se devi andare oltre il controllo base, il passo successivo è sempre lo stesso: raccogli un dato, confrontalo con il comportamento atteso, poi restringi il campo. Linux ti dà quasi sempre la risposta, ma raramente te la consegna in un unico comando. Il lavoro vero è leggere i segnali nell’ordine giusto.

In pratica, i comandi Linux per vedere le informazioni di sistema da terminale non servono solo a “sapere qualcosa della macchina”: servono a costruire una diagnosi affidabile. Se impari a leggere kernel, risorse, storage, rete e servizi come livelli separati, riduci molto i tempi di troubleshooting e smetti di confondere i sintomi con la causa.