Varför stoppar min bot när jag stänger SSH?

För att du startade den inuti din SSH-session, så den är knuten till den sessionen och dör när du kopplar från. Fixen är att köra den som en bakgrundstjänst som är oberoende av din inloggning — systemd är det rena sättet, tmux är det snabba sättet.

Hur startar jag om en bot automatiskt när den kraschar?

Kör den som en systemd-tjänst med Restart=always och en liten RestartSec-fördröjning. systemd startar sedan om processen inom sekunder av vilken krasch som helst, obegränsat, utan barnvakt. Den enda raden är skillnaden mellan 'den dog klockan 4 på natten' och 'den blippade och återhämtade sig.'

Hur får jag en bot att starta automatiskt efter en omstart?

systemctl enable din tjänst. 'enable' kopplar den att starta vid boot, 'start' kör den nu — gör båda (systemctl enable --now). Efter vilken omstart som helst kommer boten tillbaka på egen hand utan att du loggar in.

systemd eller pm2 eller tmux — vilken ska jag använda?

systemd för allt verkligt och långlivat: den hanterar omstart, boot-start och loggning nativt, ingen extra verktygsuppsättning. tmux är utmärkt för ett snabbtest eller att titta på en interaktiv körning. pm2 är rimligt om du lever i Node och vill ha dess dashboard, men det är ännu en sak att hålla igång. För en enda always-on bot vinner systemd på enkelhet.

Hur ser jag varför min bot fortsätter krascha?

journalctl -u yourbot -n 100 visar de senaste loggarna och felet den dog på; lägg till -f för att följa live. Detta är oftast där den verkliga orsaken gömmer sig — en saknad env-var, ett ohanterat undantag, en API-timeout. Fixa det, starta inte bara om blint.

Håll en bot igång 24/7 på en VPS (så den aldrig tyst dör)

Det finns två sätt en bot "inte fungerar" på en server. Det uppenbara: den stoppar i det ögonblick du stänger SSH. Det smygande: den körs bra i två dagar, kraschar klockan 4 på natten på något ohanterat fel, och du får reda på det timmar senare när någon frågar varför den är nere. Båda har samma fix, och det är inte "kom ihåg att starta om den" — det är att lämna jobbet till systemd, som håller saker uppe så att du inte behöver.

Varför den dör när du loggar ut

Om du startade den med python bot.py i din SSH-session är processen ett barn till den sessionen. Stäng sessionen, processen följer med. nohup och & sopar över detta, men de ger dig ingen omstart-vid-krasch och ingen start-vid-boot — så du har löst det lilla problemet och behållit det stora.

Den verkliga fixen: en systemd-tjänst

Detta är hela grejen. Skapa /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

Två rader gör det tunga lyftet:

Restart=always — boten kraschar, systemd tar tillbaka den på 5 sekunder. Den 4-på-natten-döden blir en 5-sekunders-blip ingen märker.
enable — den startar igen efter en omstart, på egen hand. Inget "åh, servern startade om och jag glömde att starta om allt."

När den fortfarande missköter sig — läs loggarna

En bot som fortsätter krasch-loopa fixas inte genom att starta om hårdare; något är faktiskt fel. systemd fångar stdout/stderr, så:

systemctl status mybot          # up or down, last exit code
journalctl -u mybot -n 100      # recent logs + the error it died on
journalctl -u mybot -f          # follow live

Orsaken är nästan alltid precis där: en saknad miljövariabel, ett ohanterat undantag, en API-timeout, en OOM kill. Fixa det — Restart=always är ett skyddsnät, ingen bot för en verklig bugg.

Tips: om loggarna visar att boten dödas för minne har du vuxit ur boxen — kolla dimensioneringsguiden.

När tmux eller pm2 är vettiga istället

systemd är inte det enda svaret, bara det bästa standardvalet:

tmux — perfekt för ett snabbtest eller att titta på en interaktiv process. Kör, koppla från, återanslut senare. Men den startar inte om vid krasch eller överlever en omstart, så den är inte för produktion.
pm2 — rimligt om du redan är i Node-världen och vill ha dess process-dashboard. Haken: pm2 är själv en process du nu måste hålla vid liv (vanligtvis... via systemd). För en bot är det ett lager du inte behöver.

För en enda always-on bot eller agent är systemd det enklaste som faktiskt fungerar — den finns redan på servern, behöver ingen extra verktygsuppsättning, och gör omstart, boot-start och loggning direkt.

Den ärliga slutsatsen

Drifttid handlar inte om en större server eller mer disciplin — det handlar om att inte knyta din process till din laptop. Slå in den i en systemd-unit med Restart=always och enable, och kolla journalctl när något är fel. Gör det en gång och din bot stannar uppe oavsett om du tittar eller sover. (Ny box? Lås ner den först — en 24/7-bot är också ett 24/7-mål.)

Behöver någonstans att köra den? Ett Nano-plan ($3/mån) håller en bot vid liv 24/7 — systemd gör resten.