Perché il mio bot si ferma quando chiudo SSH?

Perché lo hai avviato dentro la tua sessione SSH, quindi è legato a quella sessione e muore quando ti disconnetti. La soluzione è eseguirlo come servizio in background indipendente dal tuo login — systemd è il modo pulito, tmux è il modo rapido.

Come faccio a riavviare automaticamente un bot quando va in crash?

Eseguilo come servizio systemd con Restart=always e un piccolo ritardo RestartSec. systemd rilancia poi il processo entro pochi secondi da qualsiasi crash, indefinitamente, senza doverlo sorvegliare. Quell'unica riga è la differenza tra 'è morto alle 4 del mattino' e 'ha avuto un intoppo e si è ripreso.'

Come faccio ad avviare un bot automaticamente dopo un riavvio?

systemctl enable del tuo servizio. 'enable' lo collega all'avvio al boot, 'start' lo esegue ora — fai entrambi (systemctl enable --now). Dopo qualsiasi riavvio, il bot torna da solo senza che tu debba fare login.

systemd o pm2 o tmux — quale dovrei usare?

systemd per qualsiasi cosa reale e a lunga durata: gestisce riavvio, avvio al boot e logging in modo nativo, senza strumenti extra. tmux è ottimo per un test rapido o per guardare un'esecuzione interattiva. pm2 è ragionevole se vivi in Node e vuoi la sua dashboard, ma è un'altra cosa da tenere in funzione. Per un singolo bot sempre attivo, systemd vince per semplicità.

Come faccio a vedere perché il mio bot continua ad andare in crash?

journalctl -u yourbot -n 100 mostra i log recenti e l'errore su cui è morto; aggiungi -f per seguire in tempo reale. Di solito è qui che si nasconde la vera causa — una variabile d'ambiente mancante, un'eccezione non gestita, un timeout dell'API. Sistema quello, non riavviare alla cieca.

Tieni un bot in funzione 24/7 su un VPS (così non muore mai in silenzio)

Ci sono due modi in cui un bot "non funziona" su un server. Quello ovvio: si ferma nel momento in cui chiudi SSH. Quello subdolo: gira bene per due giorni, va in crash alle 4 del mattino su un errore non gestito, e lo scopri ore dopo quando qualcuno chiede perché è giù. Entrambi hanno la stessa soluzione, e non è "ricordati di riavviarlo" — è affidare il lavoro a systemd, che tiene le cose attive così non devi farlo tu.

Perché muore quando esci

Se l'hai lanciato con python bot.py nella tua sessione SSH, il processo è figlio di quella sessione. Chiudi la sessione, il processo se ne va con essa. nohup e & tamponano il problema, ma non ti danno riavvio-dopo-crash né avvio-al-boot — quindi hai risolto il problema piccolo e tenuto quello grande.

La vera soluzione: un servizio systemd

Questo è tutto. Crea /etc/systemd/system/mybot.service:

[Unit]
Description=My bot
After=network-online.target

[Service]
WorkingDirectory=/home/youruser/mybot
ExecStart=/home/youruser/mybot/venv/bin/python bot.py
Restart=always
RestartSec=5
User=youruser
Environment=API_KEY=...

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now mybot

Due righe fanno il lavoro pesante:

Restart=always — il bot va in crash, systemd lo riporta in 5 secondi. Quella morte delle 4 del mattino diventa un intoppo di 5 secondi che nessuno nota.
enable — riparte dopo un riavvio, da solo. Niente "ah, il server si è riavviato e ho dimenticato di rilanciare tutto."

Quando continua a comportarsi male — leggi i log

Un bot che continua a fare crash-loop non si sistema riavviando più forte; qualcosa non va davvero. systemd cattura stdout/stderr, quindi:

systemctl status mybot          # attivo o giù, ultimo exit code
journalctl -u mybot -n 100      # log recenti + l'errore su cui è morto
journalctl -u mybot -f          # segui in tempo reale

La causa è quasi sempre proprio lì: una variabile d'ambiente mancante, un'eccezione non gestita, un timeout dell'API, un kill per OOM. Sistema quello — Restart=always è una rete di sicurezza, non una cura per un bug reale.

Consiglio: se i log mostrano il bot ucciso per la memoria, hai superato la macchina — controlla la guida al dimensionamento.

Quando invece tmux o pm2 hanno senso

systemd non è l'unica risposta, solo il miglior default:

tmux — perfetto per un test rapido o per guardare un processo interattivo. Esegui, stacca, riattacca più tardi. Ma non si riavvia dopo un crash né sopravvive a un riavvio, quindi non è per la produzione.
pm2 — ragionevole se sei già nel mondo Node e vuoi la sua dashboard dei processi. La fregatura: pm2 è esso stesso un processo che ora devi tenere vivo (di solito... tramite systemd). Per un bot, è uno strato di cui non hai bisogno.

Per un singolo bot o agente sempre attivo, systemd è la cosa più semplice che funziona davvero — è già sul server, non serve alcuno strumento extra, e fa riavvio, avvio al boot e logging di serie.

La conclusione onesta

L'uptime non riguarda un server più grande o più disciplina — riguarda il non legare il tuo processo al tuo laptop. Avvolgilo in una unit systemd con Restart=always ed enable, e controlla journalctl quando qualcosa non va. Fallo una volta e il tuo bot resta attivo che tu stia guardando o dormendo. (Macchina nuova? Blindala prima — un bot 24/7 è anche un bersaglio 24/7.)

Ti serve un posto dove eseguirlo? Un piano Nano ($3/mese) tiene vivo un bot 24/7 — systemd fa il resto.