Por que meu bot para quando fecho o SSH?

Porque você o iniciou dentro da sua sessão SSH, então ele está atrelado a essa sessão e morre quando você desconecta. A solução é rodá-lo como um serviço em segundo plano independente do seu login — o systemd é a forma limpa, o tmux é a forma rápida.

Como faço um bot reiniciar sozinho quando ele cai?

Rode-o como um serviço systemd com Restart=always e um pequeno atraso RestartSec. O systemd então relança o processo em segundos após qualquer queda, indefinidamente, sem babá. Essa única linha é a diferença entre 'morreu às 4 da manhã' e 'deu um piscar e se recuperou'.

Como faço um bot iniciar automaticamente após um reboot?

systemctl enable no seu serviço. 'enable' o conecta para iniciar no boot, 'start' o roda agora — faça os dois (systemctl enable --now). Após qualquer reboot, o bot volta sozinho sem você fazer login.

systemd, pm2 ou tmux — qual devo usar?

systemd para qualquer coisa real e de longa duração: ele cuida de restart, boot-start e logging nativamente, sem ferramentas extras. O tmux é ótimo para um teste rápido ou acompanhar uma execução interativa. O pm2 é razoável se você vive no Node e quer o dashboard dele, mas é mais uma coisa para manter rodando. Para um único bot sempre ligado, o systemd vence na simplicidade.

Como vejo por que meu bot vive caindo?

journalctl -u seubot -n 100 mostra os logs recentes e o erro no qual ele morreu; adicione -f para acompanhar ao vivo. É geralmente aqui que a causa real se esconde — uma env var faltando, uma exceção não tratada, um timeout de API. Conserte isso, não só reinicie às cegas.

Mantenha um bot rodando 24/7 num VPS (para que ele nunca morra silenciosamente)

Há duas formas de um bot "não funcionar" num servidor. A óbvia: ele para no segundo em que você fecha o SSH. A traiçoeira: ele roda bem por dois dias, cai às 4 da manhã em algum erro não tratado, e você descobre horas depois quando alguém pergunta por que está fora. Ambas têm a mesma solução, e não é "lembrar de reiniciá-lo" — é entregar o trabalho ao systemd, que mantém as coisas de pé para você não precisar.

Por que ele morre quando você faz logout

Se você o lançou com python bot.py na sua sessão SSH, o processo é um filho dessa sessão. Feche a sessão, o processo vai junto. nohup e & disfarçam isso, mas não te dão restart-em-queda nem iniciar-no-boot — então você resolveu o problema pequeno e manteve o grande.

A solução de verdade: um serviço systemd

Isto é a coisa inteira. Crie /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

Duas linhas fazem o trabalho pesado:

Restart=always — o bot cai, o systemd o traz de volta em 5 segundos. Aquela morte das 4 da manhã vira um piscar de 5 segundos que ninguém nota.
enable — ele inicia de novo após um reboot, sozinho. Sem "ah, o servidor reiniciou e eu esqueci de relançar tudo".

Quando ele ainda está se comportando mal — leia os logs

Um bot que fica em loop de queda não é consertado reiniciando com mais força; algo está de fato errado. O systemd captura stdout/stderr, então:

systemctl status mybot          # de pé ou fora, último código de saída
journalctl -u mybot -n 100      # logs recentes + o erro no qual ele morreu
journalctl -u mybot -f          # acompanhe ao vivo

A causa quase sempre está ali mesmo: uma variável de ambiente faltando, uma exceção não tratada, um timeout de API, um kill por OOM. Conserte isso — Restart=always é uma rede de segurança, não uma cura para um bug de verdade.

Dica: se os logs mostram o bot sendo morto por memória, você ultrapassou a máquina — confira o guia de dimensionamento.

Quando tmux ou pm2 fazem sentido

O systemd não é a única resposta, só o melhor padrão:

tmux — perfeito para um teste rápido ou acompanhar um processo interativo. Rode, desanexe, reanexe depois. Mas ele não vai reiniciar em queda nem sobreviver a um reboot, então não é para produção.
pm2 — razoável se você já está no mundo Node e quer o dashboard de processos dele. O detalhe: o pm2 é ele mesmo um processo que você agora tem que manter vivo (geralmente... via systemd). Para um bot, essa é uma camada de que você não precisa.

Para um único bot sempre ligado ou agente, o systemd é a coisa mais simples que de fato funciona — ele já está no servidor, não precisa de ferramentas extras e faz restart, boot-start e logging de fábrica.

A conclusão honesta

Uptime não é sobre um servidor maior ou mais disciplina — é sobre não atrelar seu processo ao seu notebook. Envolva-o numa unit systemd com Restart=always e enable, e cheque o journalctl quando algo estiver errado. Faça isso uma vez e seu bot fica de pé esteja você observando ou dormindo. (Máquina nova? Tranque-a primeiro — um bot 24/7 também é um alvo 24/7.)

Precisa de um lugar para rodá-lo? Um plano Nano (US$3/mês) mantém um bot vivo 24/7 — o systemd faz o resto.