Guida a Screen su Linux: sessioni persistenti da terminale

Perché screen resta utile su Linux

screen è uno di quei tool vecchi quanto affidabili che continuano a risolvere problemi pratici: apri una sessione remota, avvii un comando lungo, chiudi il client SSH e il processo resta lì, attaccato alla sessione virtuale. Quando ti riconnetti, riprendi esattamente dal punto in cui eri rimasto.

In ambienti sysadmin è ancora comodo per manutenzioni, migrazioni, compilazioni, importazioni dati, diagnostica interattiva e task che non vuoi legare alla durata della tua connessione. Non sostituisce sempre tmux, ma in molte macchine lo trovi già installato e, soprattutto, fa il suo lavoro senza richiedere troppa preparazione.

Il punto chiave è semplice: screen crea terminali persistenti. La shell e i processi figli continuano a vivere anche se la tua sessione SSH cade. Il terminale “reale” sparisce, ma il contesto resta agganciato a una sessione interna di screen.

Quando usarlo e quando evitarlo

Usalo quando ti serve una sessione affidabile, minimale e disponibile su molte distribuzioni senza installare altro. È perfetto su server di produzione dove vuoi evitare dipendenze aggiuntive o quando lavori su host vecchi, appliance o ambienti ridotti.

Evitalo se hai bisogno di una gestione finestre/pannelli più moderna, scripting più leggibile o integrazioni più comode: in quel caso tmux spesso è più pratico. Evitalo anche se il tuo problema non è la persistenza della shell ma la schedulazione del job: lì hanno più senso systemd, cron, at o un runner applicativo.

Regola pratica: screen è un terminale persistente, non un sistema di job management. Se lo usi come tale, finisci per costruirti workaround fragili.

Installazione e verifica rapida

Su molte distro è già presente, ma vale la pena verificare prima di dare per scontato qualcosa. Su Debian, Ubuntu e derivate:

sudo apt update
sudo apt install screen

Su RHEL, AlmaLinux, Rocky o Fedora:

sudo dnf install screen

Verifica la presenza e la versione con:

screen --version

Se il comando risponde con la versione, sei a posto. Se ottieni command not found, il pacchetto non è installato o il binario non è nel PATH dell’utente corrente.

Avvio di una sessione persistente

Il caso base è questo:

screen

Viene aperta una nuova sessione con una shell dentro screen. Da qui puoi eseguire comandi come faresti normalmente. Se vuoi dare subito un nome alla sessione, conviene farlo all’avvio:

screen -S manutenzione-db

Il nome è utile quando hai più sessioni aperte e vuoi riconoscerle al volo. In ambienti operativi, nominare bene le sessioni evita confusione molto più di quanto sembri.

Dentro screen, la combinazione più importante è Ctrl-a come prefisso dei comandi. Non è il comando finale, è il tasto che “apre” il menu di screen. Per staccarti dalla sessione senza chiuderla usa:

Ctrl-a d

La sessione rimane attiva in background. Se chiudi SSH, il processo non muore solo perché il terminale è sparito.

Ricollegarsi a una sessione esistente

Per vedere le sessioni aperte:

screen -ls

L’output tipico mostra un identificativo numerico e, se hai usato un nome, anche l’etichetta della sessione. Se hai una sola sessione, il rientro è semplice:

screen -r

Se ci sono più sessioni, specifica quella giusta:

screen -r manutenzione-db

Se la sessione risulta già “attached” perché sei entrato da un altro terminale o perché una connessione precedente non ha lasciato la sessione in stato pulito, puoi forzare il distacco e riattaccarti con:

screen -d -r manutenzione-db

Questo è uno dei motivi per cui screen resta comodo: recuperi sessioni lasciate appese senza dover ripartire da zero.

Comandi interni essenziali che devi ricordare

Screen vive di scorciatoie. Le più utili in pratica sono poche, ma vanno memorizzate perché fanno la differenza nel lavoro quotidiano.

La gestione delle finestre è uno dei punti forti di screen: puoi avere più shell nello stesso contesto persistente, con un minimo di ordine operativo. Rinominare le finestre è particolarmente utile quando stai seguendo log, comandi di deploy e verifiche DB nella stessa sessione.

Un esempio reale: manutenzione lunga via SSH

Scenario tipico: devi eseguire un import pesante su un database o un task applicativo che dura più di una normale finestra di manutenzione. Se lo lanci in una shell SSH normale e la connessione cade, rischi di interrompere tutto. Con screen, invece, fai così:

screen -S import-prod
mysql -u appuser -p database < dump.sql

Se la connessione si disconnette, torni più tardi e riprendi:

screen -ls
screen -r import-prod

Se vuoi monitorare un log mentre il job gira, apri una nuova finestra nella stessa sessione:

Ctrl-a c
tail -f /var/log/mysql/error.log

Questo approccio evita di aprire più SSH e ti mantiene tutto nello stesso contesto operativo.

Configurazione utile nel file .screenrc

La configurazione base di screen non è complicata. Se lo usi spesso, però, un file ~/.screenrc ben fatto migliora parecchio l’usabilità. Un esempio minimale e sensato:

startup_message off
caption always "%{= kw}%-w%{= bw}%n %t%{-}%+w"
defscrollback 5000

Queste tre righe fanno cose concrete: disattivano il messaggio iniziale, mostrano una caption con numero e titolo delle finestre, aumentano lo scrollback. Non è estetica fine a sé stessa: più scrollback significa più contesto quando devi rivedere output lunghi o errori passati.

Se vuoi rinominare automaticamente le finestre o impostare binding personalizzati, puoi farlo, ma conviene partire da una configurazione sobria. Più il file cresce, più devi documentarlo per evitare sorprese a distanza di mesi.

Scrollback, copia e incolla: i punti che confondono di più

Chi usa screen per la prima volta spesso inciampa su due aspetti: lo scrollback e la selezione del testo. Il comportamento dipende anche dal terminal emulator che usi lato client, quindi non aspettarti un’esperienza identica ovunque.

Per entrare in modalità copia/scroll interna di screen si usa normalmente Ctrl-a [. Da lì puoi muoverti con i tasti del cursore o Page Up/Page Down. Per uscire dalla modalità basta premere Esc. Se il tuo terminale supporta bene lo scroll nativo, spesso è più semplice usare quello; se invece sei in una sessione remota con output molto lungo, la modalità di screen torna utile.

Il consiglio pratico è non affidarti al caso: verifica il comportamento su un host di test prima di usarlo in produzione. Il mix tra terminale locale, SSH, multiplexer e mouse può cambiare parecchio da un ambiente all’altro.

Detaching pulito e gestione delle sessioni “orfane”

Se perdi la connessione, la sessione di screen di solito resta viva e diventa “detached” in automatico. In alcuni casi, però, puoi ritrovarti con sessioni che risultano ancora attaccate a un terminale non più valido. È qui che i comandi di listing e reattach diventano fondamentali.

Controlla sempre lo stato con:

screen -ls

Se vedi sessioni non attive o duplicate, evita di ucciderle di impulso. Prima prova un reattach forzato:

screen -d -r

Se devi chiudere davvero una sessione, fallo dall’interno con exit nella shell o chiudendo tutte le finestre. In alternativa, da fuori, puoi terminare una sessione specifica con attenzione, dopo aver verificato che non stia facendo lavoro utile.

Questo è il punto in cui serve disciplina operativa: una sessione persistente non è automaticamente una sessione da tenere in vita per sempre.

Screen in ambienti server: vantaggi e limiti reali

In server room o su VM di supporto, screen ha un vantaggio molto concreto: è leggero e quasi sempre disponibile. Non richiede un demone complesso, non dipende da servizi esterni e non introduce molta superficie operativa.

Il limite, invece, è la sua interfaccia meno intuitiva rispetto a strumenti più moderni. Se lavori tutti i giorni con layout complessi, split multipli e workflow molto personalizzati, tmux tende a essere più ergonomico. Screen resta forte quando vuoi affidabilità semplice e compatibilità.

Un altro limite da tenere a mente: screen non sostituisce il logging. Se l’output del comando è critico, conviene comunque reindirizzarlo su file o usare un logger dedicato. La persistenza del terminale non è un backup dei dati di esecuzione.

Pattern operativi che funzionano davvero

Ci sono tre usi che, in pratica, giustificano quasi sempre screen su un server Linux:

Per esempio, durante una migrazione puoi tenere una finestra con il trasferimento, una con i log applicativi e una con il controllo dello stato del servizio. Questo riduce il rischio di perdere il filo quando lavori sotto pressione.

Un accorgimento utile è dare nomi coerenti alle sessioni: backup-2026-04, deploy-api, debug-mail. Quando torni sul server dopo ore o giorni, la memoria umana ringrazia.

Buone pratiche prima di affidarti a screen

Prima di lanciare qualcosa di importante dentro screen, fai due verifiche di buon senso. Primo: il comando deve essere idempotente o almeno ripetibile, perché un’interruzione può costringerti a rilanciarlo. Secondo: l’output deve andare anche da qualche altra parte, idealmente in un file di log o in un sistema di monitoraggio.

Se il task tocca dati o servizi, pianifica sempre il rollback. Screen ti protegge dalla disconnessione, non dagli errori di procedura. Un import sbagliato, un deploy errato o una modifica di configurazione fatta male restano sbagliati anche dentro una sessione persistente.

La regola finale è semplice: usa screen per non perdere il contesto, non per saltare il controllo operativo. È uno strumento di continuità, non di automazione.

Checklist rapida da tenere a mente

Se devi usarlo in modo professionale, questo è il minimo sindacale:

In sintesi, screen è ancora uno strumento solido per chi gestisce Linux da terminale: fa poche cose, ma le fa in modo affidabile. Se ti serve una sessione che sopravvive alle disconnessioni e non vuoi complicarti la vita, è una soluzione concreta. Se poi il tuo workflow richiede di più, il salto successivo è naturale, ma il problema della sessione persistente rimane risolto già qui.