1 23/04/2026 9 min

40 comandi Linux essenziali, senza fumo

Su Linux non serve conoscere centinaia di utility per lavorare bene: ne bastano poche decine, ma usate con criterio. Qui sotto trovi 40 comandi che coprono il 90% delle attività quotidiane di amministrazione, supporto e troubleshooting. L’obiettivo non è fare teoria: è arrivare velocemente da un sintomo a un’evidenza verificabile.

La regola pratica è semplice: prima osserva, poi modifica. Quasi ogni comando in questa lista può essere usato in sola lettura, e quando c’è un’azione potenzialmente impattante vale la pena sapere cosa stai toccando, quale servizio ne dipende e come tornare indietro.

Navigazione e inventario del sistema

Questi sono i comandi che usi per capire dove sei, cosa c’è intorno e con quale utente stai operando. Sembra banale, ma molti errori operativi nascono proprio da qui: path sbagliato, permessi errati, shell diversa da quella attesa.

  1. pwd — mostra la directory corrente. Utile quando lavori in sessioni lunghe o con script che cambiano path.
  2. ls — elenca file e directory. Con ls -lah vedi anche dimensioni, owner e permessi.
  3. cd — cambia directory. Con cd - torni al path precedente.
  4. tree — visualizza la struttura ad albero; utile per capire l’organizzazione di un progetto o di una config. Se non è installato, spesso basta il pacchetto omonimo.
  5. find — ricerca file per nome, data, dimensione o permessi. È più lento di locate, ma molto più preciso.
  6. locate — ricerca rapida su database indicizzato. Se l’output è vecchio, aggiorna prima l’indice con updatedb.

Esempio rapido:

pwd
ls -lah
find /etc -name '*.conf' 2>/dev/null

File, testo e contenuti di configurazione

La maggior parte del lavoro sistemistico passa dai file: log, config, unit systemd, script, chiavi pubbliche, inventory. Qui contano velocità e precisione, non “aprire e guardare a caso”.

  1. cat — stampa il contenuto di un file. Va bene per file piccoli o per concatenare output.
  2. less — navigazione interattiva di file grandi, soprattutto log. È il lettore da usare di default.
  3. head — mostra le prime righe; utile per vedere intestazioni, versioni o formati.
  4. tail — mostra le ultime righe. Con tail -f segui un log in tempo reale.
  5. grep — filtra per pattern. Con -R cerchi in ricorsione, con -n vedi i numeri di riga.
  6. sed — modifica o filtra testo in stream. Perfetto per trasformazioni semplici e ripetibili.
  7. awk — estrazione e rielaborazione per colonne o campi. Molto forte su log e output tabellari.
  8. sort — ordina righe; combinato con uniq è utile per conteggi e normalizzazione.
  9. uniq — elimina duplicati adiacenti o li conta con -c; richiede spesso un sort prima.
  10. wc — conta righe, parole e byte; utile per dimensionare file o verificare output inattesi.

Tre esempi pratici che valgono più di mille spiegazioni:

tail -f /var/log/syslog
grep -Rni 'Listen' /etc/apache2 /etc/httpd 2>/dev/null
awk '{print $1, $9}' access.log | sort | uniq -c | sort -nr

Con grep, awk e sed si risolvono moltissimi casi senza aprire editor o scrivere script lunghi. Il punto è usare output minimi, leggibili e verificabili.

Permessi, utenti e ownership

Se un servizio non legge un file o un utente non riesce a scrivere in una directory, il problema spesso non è “il software”, ma i permessi. Qui conviene diagnosticare con calma: owner, gruppo, mode, ACL e contesto SELinux/AppArmor quando presenti.

  1. chmod — cambia i permessi. Usalo con attenzione: un chmod -R fatto male può rompere servizi e sicurezza.
  2. chown — cambia owner e gruppo. Tipico su directory web, spool mail, mount condivisi.
  3. id — mostra UID, GID e gruppi di un utente; utile per capire con quali privilegi gira una sessione.
  4. whoami — conferma l’utente effettivo della shell corrente.
  5. sudo — esegue comandi con privilegi elevati in modo controllato; meglio di operare da root in modo permanente.
  6. passwd — cambia la password di un account locale; su sistemi moderni spesso serve più per manutenzione che per uso quotidiano.

Verifica rapida:

id www-data
ls -ld /var/www /var/www/html
sudo chown -R www-data:www-data /var/www/html

Prima di toccare permessi ricorsivi, chiediti quale servizio li consuma e qual è il rollback. In molti casi basta correggere una sola directory o un solo file, non l’intero albero.

Processi, servizi e controllo dell’esecuzione

Quando qualcosa “non va”, il processo da guardare è quasi sempre il primo indiziato: è vivo? consuma CPU? è in crash loop? È bloccato in I/O? Questi comandi ti danno l’immagine operativa del sistema.

  1. ps — elenca processi. Con ps aux ottieni una vista ampia, con filtri mirati trovi il processo sospetto.
  2. top — monitoraggio in tempo reale di CPU, memoria e load; il classico primo check su host stressati.
  3. htop — alternativa più leggibile a top, se installata.
  4. kill — invia segnali a un processo. Di base meglio provare TERM prima di arrivare a KILL.
  5. pkill — termina processi per nome o pattern; comodo, ma richiede più attenzione di kill.
  6. systemctl — gestisce servizi systemd: start, stop, restart, status, enable, disable.
  7. journalctl — consulta i log del journal, spesso più utile dei file classici quando il servizio è gestito da systemd.

Una sequenza tipica di verifica è questa:

systemctl status nginx
journalctl -u nginx -n 50 --no-pager
ps aux | grep -E 'nginx|apache|php-fpm'

Se un servizio va riavviato, fallo solo dopo aver letto gli ultimi log: riavviare alla cieca può cancellare l’evidenza utile proprio quando serve di più.

Rete, DNS e raggiungibilità

Molti ticket “il sito non risponde” non sono problemi applicativi, ma di rete, DNS, routing o TLS. Qui i comandi devono dirti rapidamente se il problema è locale, di upstream o dell’origine.

  1. ip — sostituto moderno di ifconfig; con ip a e ip r vedi indirizzi e routing.
  2. ss — mostra socket e porte in ascolto; utile per capire se un demone è davvero bound sulla porta attesa.
  3. ping — test di base della raggiungibilità ICMP; non basta da solo, ma è un primo segnale.
  4. curl — verifica HTTP/HTTPS in modo preciso, con header, status code e tempi.
  5. wget — utile per download rapidi o test semplici; meno comodo di curl per debug HTTP.
  6. dig — interrogazione DNS dettagliata, molto più utile di lookup generici quando vuoi vedere record e TTL.
  7. nslookup — ancora usato in molte guide e ambienti legacy; meno ricco di dig, ma immediato.
  8. traceroute — utile per capire dove si interrompe il percorso di rete; a volte serve anche mtr come alternativa più continua.

Tre check rapidi che coprono quasi tutto:

ip a
ss -lntp
curl -I https://example.com

dig example.com +short
traceroute example.com

Se curl -I restituisce un 5xx, hai già un dato utile. Se invece non risolve il nome, il problema sta prima dell’applicazione: DNS, resolver, routing o edge.

Dischi, spazio e I/O

Spazio finito e I/O lento sono due classici che si presentano come sintomi generici: servizi che non scrivono, database che rallentano, log che smettono di avanzare. Qui servono comandi che distinguano capacità, inode e saturazione.

  1. df — mostra spazio usato e disponibile sui filesystem montati.
  2. du — misura l’occupazione di directory e file; perfetto per trovare chi sta crescendo troppo.
  3. mount — mostra i mount attivi e le opzioni; utile per verificare bind mount, NFS e filesystem remoti.
  4. lsblk — inventario di dischi, partizioni e mountpoint.
  5. blkid — identifica UUID e tipi filesystem, molto utile in configurazioni con mount persistenti.
  6. iostat — monitora latenza e throughput dei dischi; essenziale quando il collo di bottiglia è storage.

Per trovare rapidamente cosa occupa spazio:

df -hT
sudo du -xh /var | sort -h | tail -n 20
lsblk -f
iostat -xz 1

Attenzione agli inode: un filesystem può avere gigabyte liberi ma zero inode disponibili. In quel caso df -h non basta; serve anche df -i.

Archivi, trasferimenti e manutenzione

Backup, migrazioni e restore passano spesso da archivi compressi e copie remote. Anche qui l’errore tipico è agire senza verificare integrità e destinazione.

  1. tar — crea o estrae archivi; con compressione integrata è ancora uno standard pratico.
  2. gzip — compressione semplice e diffusa, spesso usata insieme a tar.
  3. zip — utile per compatibilità con ambienti misti, soprattutto quando il destinatario non è Linux puro.
  4. rsync — sincronizzazione efficiente con delta transfer; ottimo per backup incrementali e copie remote.
  5. scp — copia semplice via SSH; comodo, ma meno flessibile di rsync.
  6. ssh — accesso remoto sicuro e base di quasi ogni operazione amministrativa distribuita.

Esempio pragmatico per una copia verificabile:

rsync -avh --progress /var/www/ backup@server:/srv/backup/www/
tar -czf site-backup.tar.gz /var/www/html

Se lavori su dati importanti, non fermarti alla copia: controlla dimensioni, checksum o almeno presenza dei file critici nel target. Una copia riuscita non è automaticamente un backup valido.

Gestione pacchetti e software installato

Un sistema sano è anche un sistema aggiornato e coerente. Il gestore pacchetti varia tra distribuzioni, ma il concetto è lo stesso: sapere cosa è installato, da dove arriva e quale versione è effettivamente in uso.

  1. apt — gestione pacchetti su Debian/Ubuntu e derivate.
  2. dnf — gestione pacchetti su Fedora, RHEL e compatibili recenti.
  3. yum — ancora presente in ambienti legacy; spesso sostituito da dnf.
  4. rpm — interrogazione diretta dei pacchetti su sistemi RPM-based.
  5. dpkg — strato base su Debian-based, utile per query locali e troubleshooting.

Comandi pratici:

apt list --installed | grep nginx
dnf info php-fpm
rpm -qa | grep openssl
dpkg -l | grep mariadb

Quando aggiorni, conserva sempre la possibilità di rollback: snapshot, repository coerenti o almeno elenco delle versioni precedenti. In produzione, un upgrade senza piano di ritorno è solo una scommessa.

Tre comandi che si sottovalutano spesso

man è il primo posto dove cercare il comportamento reale di un comando, non una sintesi trovata in rete. which e type aiutano a capire quale binario o shell builtin stai realmente usando, evitando equivoci quando esistono alias o versioni multiple. env è fondamentale quando un servizio funziona in shell ma fallisce come unit systemd: spesso il problema è l’ambiente, non il binario.

man rsync
which php
type cd
env | sort

Come usarli senza farsi male

Il modo corretto di lavorare con questi strumenti non è “sapere il comando”, ma combinarlo con un metodo. Prima raccogli evidenze: stato servizio, log recenti, socket, spazio disco, DNS, risposta HTTP. Poi fai una modifica piccola e reversibile. Se non cambia nulla, hai falsificato un’ipotesi e puoi passare alla successiva senza aver ampliato il danno.

Una buona sequenza operativa, quando il problema è generico, è questa: status del servizio, journal o log file, curl verso l’endpoint, ss sulla porta, df e iostat se sospetti storage, dig se c’è di mezzo il nome host. È una catena semplice, ma spesso basta per evitare ore di tentativi casuali.

Se il comando ti dà un output ambiguo, non forzare conclusioni: restringi il contesto con un filtro, un path preciso o una porta specifica. In Linux il dettaglio giusto vale più di cento ipotesi generiche.

In pratica, questi 40 comandi non servono a “sapere Linux”, ma a portare ordine nel lavoro quotidiano. Se li usi bene, riduci i tempi di diagnosi, limiti gli errori e mantieni il controllo anche quando il sistema è sotto pressione.