Dlaczego mój bot zatrzymuje się, gdy zamykam SSH?

Bo uruchomiłeś go wewnątrz swojej sesji SSH, więc jest z nią związany i umiera, gdy się rozłączasz. Rozwiązaniem jest uruchomienie go jako usługi w tle, niezależnej od Twojego logowania — systemd to czysty sposób, tmux to szybki sposób.

Jak auto-restartować bota, gdy się wywala?

Uruchom go jako usługę systemd z Restart=always i małym opóźnieniem RestartSec. systemd wtedy ponownie uruchamia proces w ciągu sekund od każdej awarii, w nieskończoność, bez pilnowania. Ta pojedyncza linia to różnica między „umarł o 4 nad ranem” a „mrugnął i się odzyskał”.

Jak sprawić, by bot uruchamiał się automatycznie po restarcie?

systemctl enable Twoja usługa. „enable” podłącza ją do startu przy rozruchu, „start” uruchamia ją teraz — zrób oba (systemctl enable --now). Po każdym restarcie bot wraca sam, bez Twojego logowania.

systemd, pm2 czy tmux — którego użyć?

systemd dla czegokolwiek prawdziwego i długotrwałego: obsługuje restart, start przy rozruchu i logowanie natywnie, bez dodatkowych narzędzi. tmux jest świetny do szybkiego testu lub obserwowania interaktywnego przebiegu. pm2 jest rozsądny, jeśli żyjesz w Node i chcesz jego panelu, ale to kolejna rzecz do utrzymywania. Dla pojedynczego zawsze włączonego bota systemd wygrywa prostotą.

Jak zobaczyć, dlaczego mój bot ciągle się wywala?

journalctl -u yourbot -n 100 pokazuje ostatnie logi i błąd, na którym umarł; dodaj -f, by śledzić na żywo. Tu zwykle ukrywa się prawdziwa przyczyna — brakująca zmienna środowiskowa, nieobsłużony wyjątek, timeout API. Napraw to, nie tylko restartuj na ślepo.

Utrzymaj bota działającego 24/7 na VPS (by nigdy po cichu nie umarł)

Są dwa sposoby, na które bot „nie działa” na serwerze. Oczywisty: zatrzymuje się w sekundzie, gdy zamkniesz SSH. Podstępny: działa dobrze przez dwa dni, wywala się o 4 nad ranem na jakimś nieobsłużonym błędzie, a Ty dowiadujesz się godziny później, gdy ktoś pyta, czemu jest wyłączony. Oba mają to samo rozwiązanie, i nie jest nim „pamiętaj, by go zrestartować” — to wręczenie zadania systemd, który utrzymuje rzeczy włączone, byś Ty nie musiał.

Dlaczego umiera, gdy się wylogowujesz

Jeśli uruchomiłeś go przez python bot.py w swojej sesji SSH, proces jest dzieckiem tej sesji. Zamknij sesję, proces idzie z nią. nohup i & to zamalowują, ale nie dają Ci restartu przy awarii ani startu przy rozruchu — więc rozwiązałeś mały problem, a zachowałeś duży.

Prawdziwe rozwiązanie: usługa systemd

To cała rzecz. Utwórz /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

Dwie linie wykonują ciężką pracę:

Restart=always — bot się wywala, systemd przywraca go w 5 sekund. Ta śmierć o 4 nad ranem staje się 5-sekundowym mrugnięciem, którego nikt nie zauważa.
enable — uruchamia się ponownie po restarcie, sam. Bez „ojej, serwer się zrestartował, a ja zapomniałem wszystko ponownie uruchomić”.

Gdy wciąż się źle zachowuje — czytaj logi

Bota, który wciąż wpada w pętlę awarii, nie naprawia się restartowaniem mocniej; coś jest faktycznie nie tak. systemd przechwytuje stdout/stderr, więc:

systemctl status mybot          # włączony czy wyłączony, ostatni kod wyjścia
journalctl -u mybot -n 100      # ostatnie logi + błąd, na którym umarł
journalctl -u mybot -f          # śledź na żywo

Przyczyna prawie zawsze jest wprost tam: brakująca zmienna środowiskowa, nieobsłużony wyjątek, timeout API, zabicie OOM. Napraw to — Restart=always to siatka bezpieczeństwa, nie lekarstwo na prawdziwy błąd.

Wskazówka: jeśli logi pokazują bota zabijanego za pamięć, przerosłeś maszynę — sprawdź przewodnik doboru.

Kiedy tmux lub pm2 mają sens zamiast tego

systemd nie jest jedyną odpowiedzią, tylko najlepszym domyślnym wyborem:

tmux — idealny do szybkiego testu lub obserwowania interaktywnego procesu. Uruchom, odłącz, podłącz ponownie później. Ale nie zrestartuje się przy awarii ani nie przetrwa restartu, więc nie do produkcji.
pm2 — rozsądny, jeśli już jesteś w świecie Node i chcesz jego panelu procesów. Haczyk: pm2 to sam proces, który teraz musisz utrzymywać przy życiu (zwykle... przez systemd). Dla jednego bota to warstwa, której nie potrzebujesz.

Dla pojedynczego zawsze włączonego bota lub agenta systemd to najprostsza rzecz, która faktycznie działa — jest już na serwerze, nie potrzebuje dodatkowych narzędzi i robi restart, start przy rozruchu i logowanie od razu.

Uczciwa konkluzja

Dostępność nie jest o większym serwerze czy większej dyscyplinie — jest o niewiązaniu procesu z laptopem. Owiń go w jednostkę systemd z Restart=always i enable oraz sprawdzaj journalctl, gdy coś nie gra. Zrób to raz, a Twój bot pozostaje włączony, niezależnie od tego, czy patrzysz, czy śpisz. (Nowa maszyna? Najpierw ją zablokuj — bot 24/7 to też cel 24/7.)

Potrzebujesz gdzieś to uruchomić? Plan Nano (3 $/mies.) utrzymuje bota przy życiu 24/7 — systemd robi resztę.