Come installare e usare Screen su AlmaLinux 9 o Rocky

Quando lavori su AlmaLinux 9 o Rocky Linux 9, screen serve soprattutto a una cosa: non perdere una sessione SSH quando la rete balla, il laptop va in standby o il terminale remoto si chiude per colpa di un timeout. È uno strumento vecchio, essenziale e ancora molto pratico per manutenzione, troubleshooting e lavori lunghi su server senza GUI.

La logica è semplice: avvii una shell dentro una sessione detached, poi puoi scollegarti e rientrare più tardi. Non sostituisce tmux in ogni scenario, ma su molte installazioni minimal o su host gestiti in modo tradizionale resta una scelta immediata e affidabile.

Installazione su AlmaLinux 9 e Rocky Linux 9

Su queste distribuzioni screen si installa dai repository standard. Prima verifica che il sistema veda i repository attivi, poi installa il pacchetto.

Step 1: controlla la presenza del pacchetto.

dnf info screen

Se il pacchetto è disponibile, vedrai nome, versione e repository di provenienza. Se invece il comando non restituisce nulla di utile, il problema non è screen ma la configurazione dei repository o la connettività verso il mirror.

Step 2: installa il pacchetto.

sudo dnf install -y screen

Il risultato atteso è l’installazione senza errori e la presenza del binario in /usr/bin/screen.

Step 3: verifica la versione installata.

screen --version

Un output tipico include la versione del programma e conferma che il comando è disponibile nel PATH dell’utente corrente.

Se vuoi capire da quale pacchetto arriva il file eseguibile, puoi usare anche:

rpm -qf /usr/bin/screen

Questo è utile quando devi documentare l’ambiente o verificare che non ci siano binari “orfani” installati a mano.

Avvio di una sessione e uso minimo

Il caso base è questo: accedi via SSH, avvii screen, lanci il comando lungo che vuoi proteggere dalla disconnessione, poi ti sganci con una combinazione di tasti.

Per creare una sessione nuova:

screen

Se vuoi assegnare un nome alla sessione, cosa che semplifica molto il rientro quando hai più sessioni aperte:

screen -S manutenzione-db

Una volta dentro, puoi lanciare qualunque comando. Per esempio, un aggiornamento di pacchetti, una copia lunga o un controllo di log.

tail -f /var/log/messages

Per scollegarti senza chiudere tutto, usa la sequenza Ctrl+A poi D. La sessione resta viva in background.

Per rientrare, prima elenca le sessioni disponibili:

screen -ls

Output atteso: una o più sessioni con PID e nome. Se vedi No Sockets found, non ci sono sessioni attive per quell’utente.

Per ricollegarti a una sessione specifica:

screen -r manutenzione-db

Se esiste una sola sessione, spesso basta:

screen -r

Se invece la sessione è già agganciata altrove, screen lo segnala e devi decidere se fare un reattach forzato. In ambiente operativo è meglio verificare prima chi la sta usando, soprattutto su account condivisi o jump host.

Combinazioni utili che conviene imparare subito

Screen vive di scorciatoie. La combinazione base è sempre Ctrl+A, poi un secondo tasto. Non è elegante, ma è stabile e funziona ovunque ci sia un terminale decente.

Le più utili in pratica sono queste:

• Ctrl+A poi D: detach dalla sessione.
• Ctrl+A poi C: crea una nuova finestra nella stessa sessione.
• Ctrl+A poi N: passa alla finestra successiva.
• Ctrl+A poi P: torna alla finestra precedente.
• Ctrl+A poi A: invia Ctrl+A all’applicazione dentro screen.
• Ctrl+A poi K: chiude la finestra corrente.

La scorciatoia Ctrl+A A è spesso sottovalutata: quando lavori dentro editor, shell interattive o altri strumenti che usano già Ctrl+A, ti permette di passare il carattere al programma in primo piano invece di comandare screen.

Per vedere l’elenco delle finestre aperte nella sessione corrente:

Ctrl+A poi "

È una funzione pratica quando hai più task aperti nello stesso contesto: log, editor, shell e monitoraggio possono convivere senza aprire più SSH.

Sessioni multiple, nomi e lavoro ordinato

Il vantaggio vero di screen emerge quando smetti di usarlo come “salvagente” e inizi a trattarlo come spazio di lavoro. Su un server di produzione, per esempio, puoi aprire una sessione dedicata a una manutenzione e tenerci dentro più finestre: una per i log, una per i controlli, una per il comando principale, una per eventuali rollback.

Conviene nominare le sessioni in modo descrittivo. Esempi sensati:

screen -S deploy-app1

screen -S debug-mail

screen -S backup-notturno

Quando fai screen -ls, questi nomi ti evitano di dover interpretare solo PID e timestamp. È un dettaglio piccolo, ma in ambienti con molte mani sullo stesso host riduce errori e tempi morti.

Se hai bisogno di entrare in una sessione specifica già esistente, il nome aiuta anche con il comando di reattach. In alternativa puoi usare l’ID numerico mostrato da screen -ls.

Logging e cattura dell’output della sessione

Screen può anche registrare quello che succede dentro la sessione. Non è un sostituto di un sistema di logging applicativo, ma per troubleshooting operativo è comodo: ti lascia una traccia testuale di ciò che hai eseguito e di ciò che ha risposto il terminale.

Per avviare screen con logging automatico:

screen -L -S debug-servizio

Il file di log viene creato secondo la configurazione e il contesto utente. Se non lo trovi, controlla la directory corrente e la configurazione di screen dell’utente in ~/.screenrc.

Se vuoi forzare un nome file più prevedibile, puoi definire la log directory nella configurazione personale. Un esempio minimale:

logfile /var/log/screen/%Y-%m-%d-%c:%t.log

Questa riga va in ~/.screenrc, ma attenzione ai permessi: la directory deve essere scrivibile dall’utente che avvia screen. Se lavori su server multiutente, non mettere log in percorsi globali senza ragionare su ownership e retention.

Per verificare rapidamente che il log stia crescendo, puoi confrontare dimensione e timestamp del file:

ls -lh /var/log/screen/

Se il file resta fermo, la causa di solito è una configurazione errata del path o un problema di permessi, non screen in sé.

Personalizzazione con `.screenrc`

La configurazione personale di screen è in ~/.screenrc. Anche senza trasformarla in un manifesto, puoi mettere poche righe per rendere il comportamento più leggibile e meno macchinoso.

Un esempio pratico e sobrio:

termcapinfo xterm* ti@:te@
startup_message off
defscrollback 5000

startup_message off evita il banner iniziale, defscrollback aumenta la cronologia visibile e le righe termcapinfo aiutano con alcuni terminali xterm-like. Non sono impostazioni obbligatorie, ma migliorano l’usabilità quando passi molte ore in shell.

Se vuoi verificare che la configurazione venga letta correttamente, avvia screen e controlla il comportamento della nuova sessione. In caso di problemi, rinomina temporaneamente il file:

mv ~/.screenrc ~/.screenrc.bak

Questo è un rollback semplice e reversibile: se screen torna a comportarsi normalmente, il problema era nella configurazione utente, non nel pacchetto installato.

Uso pratico in manutenzione server

In un contesto sysadmin, screen è utile per operazioni che non vuoi interrompere: compilazioni lunghe, export di database, rsync, analisi forense leggera, test di rete e monitoraggio di processi che richiedono interazione continua.

Un caso concreto: devi aggiornare un servizio e tenere sotto controllo i log in tempo reale. Puoi aprire una sessione nominata, creare due finestre e separare le attività.

screen -S upgrade-web

# dentro screen: Ctrl+A poi C per nuova finestra
journalctl -u httpd -f

# altra finestra
sudo dnf update -y httpd

In questo modo non devi tenere due SSH aperte, e soprattutto non perdi il contesto se la connessione cade durante il comando più lungo.

Un’altra situazione comune è la diagnostica su host remoti con latenza alta. Screen non migliora la rete, ma ti evita di ripetere da capo un lavoro già avviato. Se devi riprendere una sessione dopo dieci minuti o dopo due ore, il vantaggio è identico.

Problemi frequenti e come riconoscerli

Il primo errore tipico è confondere la perdita di SSH con la perdita della sessione. Se screen è stato avviato correttamente, la sessione continua anche se il client si disconnette. Se invece hai lanciato il comando fuori da screen, quando la shell muore il processo muore con lei.

Il secondo problema è il reattach su sessioni già agganciate. In quel caso screen -r può rispondere che la sessione è in uso. Prima di forzare un rientro, verifica lo stato con:

screen -ls

Se sei sicuro di essere l’unico operatore, puoi usare il reattach forzato. Va fatto con criterio, perché se qualcuno sta lavorando davvero dentro quella sessione gli interrompi il contesto.

screen -d -r manutenzione-db

Il terzo problema è più banale: terminale locale o remoto con combinazioni di tasti intercettate dal client, dal browser o dal multiplexer intermedio. Se Ctrl+A non funziona, controlla prima il terminal emulator, poi eventuali layer di SSH jump o console web. Screen non può vincere contro un tasto già catturato prima di arrivare alla shell.

Alternativa pratica: quando scegliere screen e quando no

Screen è una scelta razionale quando vuoi una dipendenza minima, una curva di apprendimento bassa e un comportamento prevedibile su host standard. È perfetto per interventi rapidi, bastioni, server di emergenza e ambienti dove non vuoi aggiungere troppa complessità.

Se però ti servono layout più flessibili, split multipli più comodi, scripting avanzato o una gestione più moderna delle finestre, tmux è spesso superiore. Detto questo, conoscere screen resta utile perché lo trovi già installato in molti ambienti o lo installi in un attimo senza portarti dietro dipendenze extra.

Verifica rapida dopo l’installazione

Se vuoi un controllo operativo minimale dopo l’installazione, fai questi tre passi:

1. Verifica il binario con screen --version.
2. Apri una sessione nominata con screen -S test-screen.
3. Dettagliati con Ctrl+A poi D e rientra con screen -ls e screen -r test-screen.

Se tutti e tre i passaggi funzionano, il setup è corretto. Se qualcosa si rompe, il punto di partenza è quasi sempre il PATH, i permessi utente o una configurazione in ~/.screenrc troppo aggressiva. Assunzione: AlmaLinux 9 e Rocky Linux 9 con repository standard attivi e accesso sudo per l’installazione.