Warum stoppt mein Bot, wenn ich SSH schließe?

Weil du ihn innerhalb deiner SSH-Sitzung gestartet hast, sodass er an diese Sitzung gebunden ist und stirbt, wenn du dich trennst. Die Lösung ist, ihn als Hintergrunddienst zu betreiben, der von deinem Login unabhängig ist — systemd ist der saubere Weg, tmux ist der schnelle Weg.

Wie starte ich einen Bot bei einem Absturz automatisch neu?

Betreibe ihn als systemd-Dienst mit Restart=always und einer kleinen RestartSec-Verzögerung. systemd startet den Prozess dann innerhalb von Sekunden nach jedem Absturz neu, unbegrenzt, ohne Babysitting. Diese eine Zeile ist der Unterschied zwischen „er starb um 4 Uhr“ und „er blinkte kurz und erholte sich“.

Wie sorge ich dafür, dass ein Bot nach einem Neustart automatisch startet?

systemctl enable deinen Dienst. „enable“ verdrahtet ihn, beim Booten zu starten, „start“ führt ihn jetzt aus — mach beides (systemctl enable --now). Nach jedem Neustart kommt der Bot von selbst zurück, ohne dass du dich anmeldest.

systemd oder pm2 oder tmux — was sollte ich nutzen?

systemd für alles Echte und Langlebige: es handhabt Neustart, Boot-Start und Logging nativ, ohne zusätzliches Tooling. tmux ist super für einen schnellen Test oder um einen interaktiven Lauf zu beobachten. pm2 ist vertretbar, wenn du in Node lebst und sein Dashboard willst, aber es ist noch eine Sache, die am Laufen zu halten ist. Für einen einzelnen immer-aktiven Bot gewinnt systemd bei der Einfachheit.

Wie sehe ich, warum mein Bot ständig abstürzt?

journalctl -u yourbot -n 100 zeigt die jüngsten Logs und den Fehler, an dem er starb; füge -f hinzu, um live zu folgen. Hier versteckt sich meist die echte Ursache — eine fehlende Env-Variable, eine unbehandelte Ausnahme, ein API-Timeout. Behebe das, statt einfach blind neu zu starten.

Einen Bot 24/7 auf einem VPS am Laufen halten (damit er nie stillschweigend stirbt)

Es gibt zwei Arten, wie ein Bot auf einem Server „nicht funktioniert“. Die offensichtliche: er stoppt in der Sekunde, in der du SSH schließt. Die heimtückische: er läuft zwei Tage lang gut, stürzt um 4 Uhr morgens an einem unbehandelten Fehler ab, und du erfährst es Stunden später, wenn jemand fragt, warum er unten ist. Beide haben dieselbe Lösung, und sie lautet nicht „daran denken, ihn neu zu starten“ — sie besteht darin, den Job an systemd zu übergeben, das die Dinge oben hält, damit du es nicht musst.

Warum er stirbt, wenn du dich abmeldest

Wenn du ihn mit python bot.py in deiner SSH-Sitzung gestartet hast, ist der Prozess ein Kind dieser Sitzung. Schließe die Sitzung, und der Prozess geht mit. nohup und & überkleben das, aber sie geben dir keinen Neustart-bei-Absturz und keinen Start-beim-Booten — du hast also das kleine Problem gelöst und das große behalten.

Die echte Lösung: ein systemd-Dienst

Das ist die ganze Sache. Erstelle /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

Zwei Zeilen leisten die Schwerarbeit:

Restart=always — der Bot stürzt ab, systemd bringt ihn in 5 Sekunden zurück. Dieser 4-Uhr-Tod wird zu einem 5-Sekunden-Blinken, das niemand bemerkt.
enable — er startet nach einem Neustart wieder, von selbst. Kein „oh, der Server hat neu gestartet und ich habe vergessen, alles wieder zu starten“.

Wenn er sich immer noch danebenbenimmt — lies die Logs

Ein Bot, der ständig in einer Absturzschleife hängt, wird nicht durch härteres Neustarten behoben; etwas ist tatsächlich falsch. systemd erfasst stdout/stderr, also:

systemctl status mybot          # oben oder unten, letzter Exit-Code
journalctl -u mybot -n 100      # jüngste Logs + der Fehler, an dem er starb
journalctl -u mybot -f          # live folgen

Die Ursache ist fast immer genau dort: eine fehlende Umgebungsvariable, eine unbehandelte Ausnahme, ein API-Timeout, ein OOM-Kill. Behebe das — Restart=always ist ein Sicherheitsnetz, keine Heilung für einen echten Bug.

Tipp: wenn die Logs zeigen, dass der Bot wegen Speicher gekillt wird, bist du aus der Maschine herausgewachsen — sieh dir den Dimensionierungs-Leitfaden an.

Wann tmux oder pm2 stattdessen Sinn ergeben

systemd ist nicht die einzige Antwort, nur der beste Standard:

tmux — perfekt für einen schnellen Test oder um einen interaktiven Prozess zu beobachten. Ausführen, ablösen, später wieder anhängen. Aber es startet bei einem Absturz nicht neu und übersteht keinen Neustart, also ist es nichts für die Produktion.
pm2 — vertretbar, wenn du bereits in der Node-Welt bist und sein Prozess-Dashboard willst. Der Haken: pm2 ist selbst ein Prozess, den du jetzt am Leben halten musst (meist... über systemd). Für einen Bot ist das eine Schicht, die du nicht brauchst.

Für einen einzelnen immer-aktiven Bot oder Agenten ist systemd das Einfachste, das tatsächlich funktioniert — es ist bereits auf dem Server, braucht kein zusätzliches Tooling und erledigt Neustart, Boot-Start und Logging von Haus aus.

Das ehrliche Fazit

Verfügbarkeit dreht sich nicht um einen größeren Server oder mehr Disziplin — sie dreht sich darum, deinen Prozess nicht an deinen Laptop zu binden. Verpack ihn in eine systemd-Unit mit Restart=always und enable, und prüfe journalctl, wenn etwas nicht stimmt. Mach das einmal und dein Bot bleibt oben, ob du zusiehst oder schläfst. (Neue Maschine? Riegle sie zuerst ab — ein 24/7-Bot ist auch ein 24/7-Ziel.)

Brauchst du einen Ort, um ihn laufen zu lassen? Ein Nano-Plan (3 $/Mon.) hält einen Bot 24/7 am Leben — systemd erledigt den Rest.