ssh
Come mantenere la tua app in esecuzione 24/7 dopo il logout
Scopri perché le app si fermano quando una sessione SSH si chiude e quali opzioni più sicure le tengono in esecuzione sul tuo server.
Sei finalmente riuscito a mettere online la tua applicazione, ma non appena hai chiuso il portatile il sito è diventato irraggiungibile.
In breve: per fare in modo che un’applicazione resti attiva anche dopo aver chiuso la sessione SSH, è necessario affidarne la gestione a un servizio sul server che la mantenga in esecuzione e la riavvii in automatico al termine della connessione. Per test rapidi e temporanei si possono usare strumenti come tmux o screen; se invece si tratta di un sito web o di un'API in produzione, è indispensabile ricorrere a un gestore di processi come systemd o PM2, oppure a un'architettura basata su container configurata per l'avvio automatico.
Perché l’applicazione si interrompe alla chiusura della sessione SSH?
La connessione SSH (Secure Shell) rappresenta la porta d'accesso remota al tuo server. Quando avvii un comando all'interno del terminale, l'applicazione viene creata come processo "figlio" della sessione di login corrente.
Puoi immaginarlo come una lampada collegata a una prolunga che stai tenendo in mano: finché rimani connesso la lampada riceve corrente, ma non appena ti allontani portando via la prolunga, la luce si spegne.
Questo spiega perché un'applicazione Node.js, uno script Python o un server Web funzionino perfettamente finché il terminale è aperto, per poi sparire nel nulla subito dopo il logout. Il server non sta riscontrando un anomalia: si limita semplicemente a terminare tutti i processi associati alla sessione chiusa.
Nel gergo tecnico questo problema viene descritto con espressioni come "mantenere app attive dopo la disconnessione SSH" o "processo terminato al logout". Dietro le quinte, il sistema operativo invia al processo un segnale chiamato SIGHUP (Signal Hang Up), che notifica la chiusura del terminale di controllo.
Come mantenere un’applicazione sempre attiva sul server?
La soluzione consiste nell'assegnare all'applicazione un vero e proprio "supervisore".
Un supervisore è un programma residente sul server che opera in modo del tutto indipendente dal tuo terminale. Si occupa di avviare l'applicazione, monitorarne lo stato e ripristinarla automaticamente in caso di crash o di riavvio del sistema.
È importante distinguere tra due esigenze molto diverse:
- Esigenze temporanee: se vuoi soltanto mantenere attivo un processo mentre fai dei test, un multiplexer di terminale come tmux o screen equivale a lasciare una sessione aperta in una stanza chiusa a chiave. Puoi disconnetterti e riprendere il lavoro in un secondo momento.
- Ambienti di produzione: se vuoi che un servizio sia accessibile agli utenti h24, serve una soluzione permanente. In questo caso, utilizzare un gestore di servizi come systemd, un process manager come PM2 o una configurazione basata su Docker equivale a collegare l'applicazione direttamente all'impianto elettrico dell'edificio anziché a una prolunga volante.
Se vuoi approfondire l'argomento e chiarire il flusso di lavoro per la messa online, ti consigliamo di consultare la nostra guida su come pubblicare una web app senza complicarsi la vita con il DevOps.
Quale strumento scegliere: tmux, systemd, PM2 o Docker?
Non esiste uno strumento unico adatto a ogni scenario. La scelta migliore dipende dal tipo di attività: una semplice sperimentazione, la gestione di un'unica applicazione o il coordinamento di un'architettura complessa.
| Opzione | Ideale per | Vantaggi | Limiti |
|---|---|---|---|
| tmux o screen | Test rapidi e operazioni manuali prolungate | Mantiene attiva la sessione di terminale anche dopo la disconnessione | Non è una soluzione idonea o pulita per ambienti di produzione |
| nohup | Esecuzioni rapide in background una tantum | Impedisce l'interruzione del comando alla chiusura del terminale | Difficile da monitorare e gestire nel lungo periodo |
| systemd | La maggior parte delle applicazioni su server Linux | Si avvia in automatico al reboot, riavvia i processi in crash e centralizza i log | Richiede una configurazione iniziale accurata delle unit |
| PM2 | Applicazioni gestite in ambiente Node.js | Mantiene attivi i processi Node, gestisce i riavvii e offre il bilanciamento | Specifico per l'ecosistema JavaScript / Node.js |
| Docker | Applicazioni pacchettizzate in container | Rende l'applicazione e le sue dipendenze del tutto replicabili | Introduce un livello di astrazione ulteriore da imparare |
Per un sito web accessibile al pubblico, tmux non è sufficiente. È un ottimo strumento per eseguire migrazioni di dati o test temporanei, ma un servizio in produzione deve rimanere raggiungibile a prescindere dallo stato del tuo computer, da eventuali cadute di connessione o da un riavvio del server.
Docker rappresenta la scelta ideale quando l'architettura comprende più componenti (ad esempio un servizio web, un database e un worker in background). Per capire se fa al caso tuo o se rischia solo di complicare il lavoro iniziale, consulta la guida Docker su VPS per principianti: cos'è, quando serve e quando evitarlo.
Domande Frequenti (FAQ)
Posso semplicemente lasciare il computer acceso con il terminale aperto? È una soluzione improvvisata e rischiosa. Il funzionamento di un servizio online non dovrebbe mai dipendere dallo stato del tuo portatile, dalla stabilità della connessione di casa o da una sessione SSH aperta.
tmux è adatto per ambienti di produzione? No. È utilissimo per sessioni di lavoro temporanee, ma le applicazioni in produzione richiedono una gestione strutturata: permessi chiari, politiche di riavvio definite e tracciamento dei log.
Cosa succede se il server viene riavviato? Se hai configurato l'applicazione come servizio di sistema (ad esempio con systemd), il server la riavvierà automaticamente. Una sessione terminale o uno script avviato manualmente andranno invece persi.
**Perché il comando nohup non è sufficiente?** Sebbene nohup impedisca l'arresto del processo alla chiusura di SSH, non offre un sistema pratico per monitorare, riavviare o gestire l'applicazione nel tempo.
Dove posso verificare i motivi per cui l'applicazione si arresta? Il punto di partenza sono sempre i log dell'applicazione e del gestore di processi. Se hai difficoltà a orientarti tra i messaggi di errore, puoi consultare la nostra guida su come leggere i log del server quando qualcosa smette di funzionare.
La soluzione ideale
Server Manager semplifica la gestione rendendo visibile e controllabile il "supervisore" dell'applicazione, senza dover ricordare comandi complessi a memoria. In questo modo la tua app non sarà più legata alla sessione SSH e la chiusura del terminale non ne comprometterà il funzionamento.
Questo approccio evita anche il disordine tipico delle gestioni improvvisate: processi dimenticati avviati con nohup, sessioni tmux senza nome o servizi che non ripartono correttamente dopo un riavvio del server. La configurazione rimane chiara e documentata, permettendoti di intervenire in qualsiasi momento anche a distanza di mesi.
Questo diventa fondamentale quando gestisci più progetti, job in background o database affiancati al sito web: ogni componente lavora in modo isolato senza interferire con gli altri e l'uptime del sistema rimane garantito.
In conclusione
Assicurare la continuità operativo di un'applicazione non significa trovare un "trucco" da terminale, ma effettuare un passaggio concettuale: dall'avere un'app attiva perché il tuo terminale è aperto, all'avere un'app gestita direttamente dal server in modo autonomo.
Una volta impostata correttamente questa architettura, chiudere la sessione SSH non sarà più fonte di ansia: il portatile potrà andare in standby e la connessione potrà cadere, mentre la tua applicazione continuerà a funzionare regolarmente.