EQVPS

Hold en bot kørende 24/7 på en VPS (så den aldrig dør i stilhed)

15. jun. 2026 · 3 min. læsning · EQVPS Team

Der er to måder, en bot "ikke virker" på en server. Den indlysende: den stopper i det sekund, du lukker SSH. Den luskede: den kører fint i to dage, crasher klokken 4 om natten på en uhåndteret fejl, og du finder ud af det timer senere, når nogen spørger, hvorfor den er nede. Begge har den samme løsning, og det er ikke "husk at genstarte den" — det er at overdrage jobbet til systemd, som holder tingene oppe, så du ikke behøver.

Hvorfor den dør, når du logger ud

Hvis du startede den med python bot.py i din SSH-session, er processen et barn af den session. Luk sessionen, og processen går med den. nohup og & dækker over dette, men de giver dig ingen genstart-ved-nedbrud og ingen start-ved-boot — så du har løst det lille problem og beholdt det store.

Den rigtige løsning: en systemd-tjeneste

Dette er hele sagen. Opret /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

To linjer laver det tunge løft:

Når den stadig opfører sig dårligt — læs loggene

En bot, der bliver ved med at crash-loope, fikses ikke ved at genstarte hårdere; noget er faktisk galt. systemd fanger stdout/stderr, så:

systemctl status mybot          # oppe eller nede, sidste exit-kode
journalctl -u mybot -n 100      # nylige logs + fejlen den døde på
journalctl -u mybot -f          # følg live

Årsagen er næsten altid lige der: en manglende miljøvariabel, en uhåndteret undtagelse, et API-timeout, et OOM-kill. Fiks detRestart=always er et sikkerhedsnet, ikke en kur for en rigtig fejl.

Tip: hvis loggene viser botten blive dræbt for hukommelse, er du vokset ud af boksen — tjek dimensioneringsguiden.

Når tmux eller pm2 giver mening i stedet

systemd er ikke det eneste svar, bare den bedste standard:

Til en enkelt altid-tændt bot eller agent er systemd det simpleste, der faktisk virker — den er allerede på serveren, kræver ingen ekstra værktøjer, og gør genstart, boot-start og logning ud af boksen.

Den ærlige bundlinje

Oppetid handler ikke om en større server eller mere disciplin — det handler om ikke at knytte din proces til din bærbare. Pak den ind i en systemd-unit med Restart=always og enable, og tjek journalctl, når noget er galt. Gør det én gang, og din bot forbliver oppe, uanset om du kigger eller sover. (Ny boks? Lås den ned først — en 24/7-bot er også et 24/7-mål.)


Har brug for et sted at køre den? Et Nano-abonnement ($3/md) holder en bot i live 24/7 — systemd gør resten.

FAQ

Hvorfor stopper min bot, når jeg lukker SSH?

Fordi du startede den inde i din SSH-session, så den er knyttet til den session og dør, når du afbryder. Løsningen er at køre den som en baggrundstjeneste, der er uafhængig af dit login — systemd er den rene måde, tmux er den hurtige måde.

Hvordan auto-genstarter jeg en bot, når den crasher?

Kør den som en systemd-tjeneste med Restart=always og en lille RestartSec-forsinkelse. systemd genstarter så processen inden for sekunder efter ethvert nedbrud, uendeligt, uden pasning. Den ene linje er forskellen mellem 'den døde klokken 4 om natten' og 'den blinkede og kom sig'.

Hvordan får jeg en bot til at starte automatisk efter en genstart?

systemctl enable din tjeneste. 'enable' kobler den til at starte ved boot, 'start' kører den nu — gør begge (systemctl enable --now). Efter enhver genstart kommer botten tilbage på egen hånd, uden at du logger ind.

systemd eller pm2 eller tmux — hvilken bør jeg bruge?

systemd til alt rigtigt og langtlevende: den håndterer genstart, boot-start og logning nativt, ingen ekstra værktøjer. tmux er fantastisk til en hurtig test eller til at se en interaktiv kørsel. pm2 er rimelig, hvis du bor i Node og vil have dens dashboard, men det er endnu en ting at holde kørende. Til en enkelt altid-tændt bot vinder systemd på enkelhed.

Hvordan ser jeg, hvorfor min bot bliver ved med at crashe?

journalctl -u yourbot -n 100 viser de nylige logs og fejlen, den døde på; tilføj -f for at følge live. Det er som regel her, den reelle årsag gemmer sig — en manglende env-variabel, en uhåndteret undtagelse, et API-timeout. Fiks det, genstart ikke bare blindt.

← Tilbage til blogSe planer & priser →

Kommentarer

Ingen kommentarer endnu. Vær den første.

Skriv en kommentar

Kommentarer modereres, før de vises.