Pourquoi mon bot s'arrête-t-il quand je ferme SSH ?

Parce que vous l'avez démarré dans votre session SSH, il est donc lié à cette session et meurt quand vous vous déconnectez. La solution est de le faire tourner comme un service en arrière-plan indépendant de votre connexion — systemd est la voie propre, tmux la voie rapide.

Comment redémarrer automatiquement un bot quand il plante ?

Faites-le tourner comme un service systemd avec Restart=always et un petit délai RestartSec. systemd relance alors le processus en quelques secondes après tout plantage, indéfiniment, sans surveillance. Cette seule ligne fait la différence entre « il est mort à 4 h » et « il a bégayé et récupéré ».

Comment faire démarrer un bot automatiquement après un redémarrage ?

systemctl enable votre service. « enable » le câble pour démarrer au boot, « start » le lance maintenant — faites les deux (systemctl enable --now). Après tout redémarrage, le bot revient tout seul sans que vous vous connectiez.

systemd, pm2 ou tmux — lequel utiliser ?

systemd pour tout ce qui est réel et de longue durée : il gère nativement le redémarrage, le démarrage au boot et la journalisation, sans outillage supplémentaire. tmux est parfait pour un test rapide ou pour observer une exécution interactive. pm2 est raisonnable si vous vivez dans Node et voulez son tableau de bord, mais c'est une chose de plus à garder en marche. Pour un seul bot toujours actif, systemd l'emporte sur la simplicité.

Comment voir pourquoi mon bot plante sans cesse ?

journalctl -u yourbot -n 100 montre les journaux récents et l'erreur sur laquelle il est mort ; ajoutez -f pour suivre en direct. C'est généralement là que se cache la vraie cause — une variable d'env manquante, une exception non gérée, un timeout d'API. Corrigez ça, ne redémarrez pas aveuglément.

Garder un bot en marche 24/7 sur un VPS (pour qu'il ne meure jamais en silence)

Il y a deux façons pour un bot de « ne pas fonctionner » sur un serveur. L'évidente : il s'arrête à la seconde où vous fermez SSH. La sournoise : il tourne bien pendant deux jours, plante à 4 h du matin sur une erreur non gérée, et vous l'apprenez des heures plus tard quand quelqu'un demande pourquoi il est en panne. Les deux ont la même solution, et ce n'est pas « pensez à le redémarrer » — c'est confier le travail à systemd, qui garde les choses debout pour que vous n'ayez pas à le faire.

Pourquoi il meurt quand vous vous déconnectez

Si vous l'avez lancé avec python bot.py dans votre session SSH, le processus est un enfant de cette session. Fermez la session, le processus part avec elle. nohup et & masquent cela, mais ils ne vous donnent aucun redémarrage au plantage ni démarrage au boot — vous avez donc résolu le petit problème et gardé le gros.

La vraie solution : un service systemd

C'est tout le sujet. Créez /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

Deux lignes font le gros du travail :

Restart=always — le bot plante, systemd le ramène en 5 secondes. Cette mort de 4 h du matin devient un bégaiement de 5 secondes que personne ne remarque.
enable — il redémarre après un redémarrage, tout seul. Pas de « oh, le serveur a redémarré et j'ai oublié de tout relancer ».

Quand il se comporte encore mal — lisez les journaux

Un bot qui plante en boucle ne se corrige pas en le redémarrant plus fort ; quelque chose ne va vraiment pas. systemd capture stdout/stderr, donc :

systemctl status mybot          # debout ou en panne, dernier code de sortie
journalctl -u mybot -n 100      # journaux récents + l'erreur sur laquelle il est mort
journalctl -u mybot -f          # suivre en direct

La cause est presque toujours juste là : une variable d'environnement manquante, une exception non gérée, un timeout d'API, un kill OOM. Corrigez ça — Restart=always est un filet de sécurité, pas un remède pour un vrai bug.

Astuce : si les journaux montrent le bot tué par manque de mémoire, vous avez dépassé la machine — consultez le guide de dimensionnement.

Quand tmux ou pm2 ont plutôt du sens

systemd n'est pas la seule réponse, juste le meilleur choix par défaut :

tmux — parfait pour un test rapide ou pour observer un processus interactif. Lancez, détachez, rattachez plus tard. Mais il ne redémarre pas au plantage et ne survit pas à un redémarrage, ce n'est donc pas pour la production.
pm2 — raisonnable si vous êtes déjà dans le monde Node et voulez son tableau de bord de processus. Le hic : pm2 est lui-même un processus que vous devez maintenant garder en vie (généralement… via systemd). Pour un bot, c'est une couche dont vous n'avez pas besoin.

Pour un seul bot ou agent toujours actif, systemd est la chose la plus simple qui fonctionne réellement — il est déjà sur le serveur, ne nécessite aucun outillage supplémentaire, et fait le redémarrage, le démarrage au boot et la journalisation d'emblée.

Le résumé honnête

La disponibilité ne dépend pas d'un serveur plus gros ou de plus de discipline — elle dépend de ne pas lier votre processus à votre portable. Enveloppez-le dans une unité systemd avec Restart=always et enable, et vérifiez journalctl quand quelque chose ne va pas. Faites-le une fois et votre bot reste debout que vous regardiez ou que vous dormiez. (Nouvelle machine ? Verrouillez-la d'abord — un bot 24/7 est aussi une cible 24/7.)

Besoin d'un endroit pour le faire tourner ? Une offre Nano (3 $/mois) garde un bot en vie 24/7 — systemd fait le reste.