Hay dos formas en que un bot «no funciona» en un servidor. La obvia: se detiene en el segundo en que cierras SSH. La sigilosa: funciona bien dos días, se cae a las 4 de la madrugada por algún error no manejado, y te enteras horas después cuando alguien pregunta por qué está caído. Ambas tienen la misma solución, y no es «acuérdate de reiniciarlo» — es entregar el trabajo a systemd, que mantiene las cosas arriba para que tú no tengas que hacerlo.
Por qué muere cuando cierras sesión
Si lo lanzaste con python bot.py en tu sesión SSH, el proceso es un hijo de esa sesión. Cierra la sesión, el proceso se va con ella. nohup y & tapan esto, pero no te dan reinicio-en-fallo ni arranque-al-inicio — así que has resuelto el problema pequeño y conservado el grande.
La solución real: un servicio systemd
Esta es la cosa entera. Crea /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
Dos líneas hacen el trabajo pesado:
Restart=always— el bot se cae, systemd lo trae de vuelta en 5 segundos. Esa muerte a las 4 se convierte en un parpadeo de 5 segundos que nadie nota.enable— arranca de nuevo tras un reinicio, por su cuenta. Nada de «ah, el servidor se reinició y olvidé relanzarlo todo».
Cuando aún se porta mal — lee los logs
Un bot que sigue en bucle de fallos no se arregla reiniciando más fuerte; algo está realmente mal. systemd captura stdout/stderr, así que:
systemctl status mybot # arriba o abajo, último código de salida
journalctl -u mybot -n 100 # logs recientes + el error en el que murió
journalctl -u mybot -f # seguir en vivo
La causa casi siempre está justo ahí: una variable de entorno faltante, una excepción no manejada, un timeout de API, un kill por OOM. Arregla eso — Restart=always es una red de seguridad, no una cura para un bug real.
Consejo: si los logs muestran que el bot es matado por memoria, has superado la máquina — revisa la guía de dimensionamiento.
Cuándo tienen sentido tmux o pm2 en su lugar
systemd no es la única respuesta, solo el mejor valor por defecto:
- tmux — perfecto para una prueba rápida o ver un proceso interactivo. Ejecuta, desconecta, reconecta después. Pero no reinicia en los fallos ni sobrevive a un reinicio, así que no es para producción.
- pm2 — razonable si ya estás en el mundo Node y quieres su dashboard de procesos. El detalle: pm2 es él mismo un proceso que ahora tienes que mantener vivo (normalmente... vía systemd). Para un bot, esa es una capa que no necesitas.
Para un único bot siempre activo o agente, systemd es lo más simple que de verdad funciona — ya está en el servidor, no necesita tooling extra, y hace el reinicio, el arranque-al-inicio y el logging de fábrica.
El fondo honesto
La disponibilidad no va de un servidor más grande ni de más disciplina — va de no atar tu proceso a tu portátil. Envuélvelo en una unidad systemd con Restart=always y enable, y revisa journalctl cuando algo falle. Haz eso una vez y tu bot sigue arriba estés observando o durmiendo. (¿Máquina nueva? Ciérrala primero — un bot 24/7 es también un objetivo 24/7.)
¿Necesitas dónde ejecutarlo? Un plan Nano (3 $/mes) mantiene un bot vivo 24/7 — systemd hace el resto.
Comentarios
Aún no hay comentarios. Sé el primero.