Waarom stopt mijn bot wanneer ik SSH sluit?

Omdat je het in je SSH-sessie startte, dus het is aan die sessie gebonden en sterft wanneer je de verbinding verbreekt. De fix is om het als een achtergrondservice te draaien die onafhankelijk is van je login — systemd is de schone manier, tmux is de snelle manier.

Hoe herstart ik een bot automatisch wanneer het crasht?

Draai het als een systemd-service met Restart=always en een kleine RestartSec-vertraging. systemd relaunched dan het proces binnen seconden van elke crash, onbeperkt, zonder babysitten. Die ene regel is het verschil tussen 'het stierf om 4 uur 's nachts' en 'het knipperde en herstelde.'

Hoe laat ik een bot automatisch starten na een herstart?

systemctl enable je service. 'enable' bedraadt het om bij boot te starten, 'start' draait het nu — doe beide (systemctl enable --now). Na elke herstart komt de bot op eigen kracht terug zonder dat je inlogt.

systemd of pm2 of tmux — welke moet ik gebruiken?

systemd voor alles echt en langlevend: het handelt restart, boot-start en logging native af, geen extra tooling. tmux is geweldig voor een snelle test of het bekijken van een interactieve run. pm2 is redelijk als je in Node leeft en zijn dashboard wilt, maar het is nog iets om draaiend te houden. Voor een enkele always-on bot wint systemd op eenvoud.

Hoe zie ik waarom mijn bot blijft crashen?

journalctl -u yourbot -n 100 toont de recente logs en de error waarop het stierf; voeg -f toe om live te volgen. Dit is meestal waar de echte oorzaak zich verstopt — een ontbrekende env-var, een onafgehandelde exception, een API-timeout. Fix dat, herstart niet gewoon blindelings.

Houd een bot 24/7 draaiend op een VPS (zodat hij nooit stilletjes sterft)

Er zijn twee manieren waarop een bot "niet werkt" op een server. De voor de hand liggende: het stopt op het moment dat je SSH sluit. De sluwe: het draait twee dagen prima, crasht om 4 uur 's nachts op een onafgehandelde error, en je komt er uren later achter wanneer iemand vraagt waarom het down is. Beide hebben dezelfde fix, en het is niet "onthoud om het te herstarten" — het is de klus overhandigen aan systemd, dat dingen op houdt zodat jij dat niet hoeft.

Waarom het sterft wanneer je uitlogt

Als je het lanceerde met python bot.py in je SSH-sessie, is het proces een kind van die sessie. Sluit de sessie, het proces gaat mee. nohup en & moffelen dit weg, maar ze geven je geen restart-bij-crash en geen start-bij-boot — dus je hebt het kleine probleem opgelost en het grote behouden.

De echte fix: een systemd-service

Dit is het hele ding. Maak /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

Twee regels doen het zware werk:

Restart=always — de bot crasht, systemd brengt het terug in 5 seconden. Die 4-uur-'s nachts-dood wordt een 5-seconden-blip die niemand merkt.
enable — het start weer na een herstart, op eigen kracht. Geen "oh, de server herstartte en ik vergat alles opnieuw te lanceren."

Wanneer het zich nog steeds misdraagt — lees de logs

Een bot die crash-loopt wordt niet gefixt door harder te herstarten; er is echt iets mis. systemd vangt stdout/stderr op, dus:

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

De oorzaak is bijna altijd precies daar: een ontbrekende omgevingsvariabele, een onafgehandelde exception, een API-timeout, een OOM kill. Fix dat — Restart=always is een vangnet, geen genezing voor een echte bug.

Tip: als de logs tonen dat de bot voor geheugen wordt gekild, ben je de box ontgroeid — check de dimensioneringsgids.

Wanneer tmux of pm2 in plaats daarvan zin hebben

systemd is niet het enige antwoord, gewoon de beste standaard:

tmux — perfect voor een snelle test of het bekijken van een interactief proces. Draai, ontkoppel, koppel later opnieuw. Maar het zal niet herstarten bij een crash of een herstart overleven, dus het is niet voor productie.
pm2 — redelijk als je al in de Node-wereld bent en zijn proces-dashboard wilt. Het addertje: pm2 is zelf een proces dat je nu in leven moet houden (meestal... via systemd). Voor één bot is dat een laag die je niet nodig hebt.

Voor een enkele always-on bot of agent is systemd het simpelste ding dat daadwerkelijk werkt — het staat al op de server, heeft geen extra tooling nodig, en doet restart, boot-start en logging out of the box.

De eerlijke conclusie

Uptime gaat niet over een grotere server of meer discipline — het gaat over je proces niet aan je laptop binden. Wikkel het in een systemd-unit met Restart=always en enable, en check journalctl wanneer er iets mis is. Doe dat één keer en je bot blijft op of je nu kijkt of slaapt. (Nieuwe box? Vergrendel het eerst — een 24/7-bot is ook een 24/7-doelwit.)

Ergens nodig om het te draaien? Een Nano-plan ($3/mnd) houdt een bot 24/7 in leven — systemd doet de rest.