El día que un script de cinco líneas tiró mi servidor: por qué uso systemd y cron (pero no como ustedes creen)

Era noviembre de 2022. Tenía un cliente de comercio electrónico que me pagaba un pago mensual decente por mantener un bot de captación de prospectos. El bot era un script sencillo en Python. Tenía que correr cada cinco minutos. En mi ingenuidad de aquel entonces, abrí la terminal de mi VPS de cinco dólares, escribí crontab -e y programé la tarea. Listo. Fácil. O eso pensaba.

A las tres de la mañana, la API del proveedor de datos cambió un endpoint sin avisar. Mi script se quedó esperando una respuesta que nunca llegó. No tenía un timeout bien configurado. Cinco minutos después, cron lanzó la segunda instancia del script. Cinco minutos más tarde, la tercera. Para cuando me desperté a las siete con los gritos del cliente en WhatsApp, la memoria RAM estaba completamente saturada por 48 procesos zombies. El servidor entero se había congelado. Perdimos exactamente 1,420 dólares en leads esa noche. Mi cliente se enojó. Yo no dormí.

Ahí aprendí la primera gran lección de infraestructura: cron es un martillo, pero no todos los problemas son clavos.

La gran mentira de "solo ponlo en cron"

Muchos desarrolladores cometen el error de usar cron para todo lo que requiere automatización. Cron es fantástico para tareas que tienen un inicio claro, un final rápido y que son completamente independientes del estado del sistema. Limpieza de logs el domingo a medianoche, respaldos de bases de datos, reportes diarios de ventas. Para eso nació.

Pero si ustedes están construyendo un sistema que debe reaccionar en tiempo real, monitorear un flujo de correos o realizar integraciones complejas, cron es una trampa mortal. No tiene un sistema de control de concurrencia nativo. Si un proceso se traba, cron levantará otro encima. Tampoco tiene un sistema de manejo de fallas inteligente. Si el script muere por un error de conexión a la base de datos, cron simplemente esperará hasta la próxima ejecución programada para volver a fallar.

Para mantener un flujo constante de trabajo pesado, necesitan un supervisor de procesos real. Necesitan systemd.

Systemd es el verdadero motor de la persistencia

Cuando configuramos un script de Python como un servicio de systemd, el sistema operativo toma el control total de su ciclo de vida. No dependemos de que el script sea perfecto; dependemos de que el sistema sea resiliente. Si el script falla por un error de red, systemd lo reinicia inmediatamente. Si el VPS se reinicia por mantenimiento del proveedor, el script vuelve a arrancar solo.

Para crear un servicio, solo necesitan un archivo plano de configuración. No hay magia negra aquí. Les comparto la estructura básica que yo uso para casi todos mis servicios en /etc/systemd/system/mi-agente.service:

[Unit]
Description=Agente de Monitoreo de Leads
After=network.target

[Service]
Type=simple
User=deploy
WorkingDirectory=/home/deploy/app
ExecStart=/home/deploy/app/venv/bin/python main.py
Restart=on-failure
RestartSec=10
Environment=PYTHONUNBUFFERED=1

[Install]
WantedBy=multi-user.target

La clave de esta configuración está en dos líneas. Primero, Restart=on-failure, que le dice al sistema que reviva el proceso si muere con un código de error distinto de cero. Segundo, PYTHONUNBUFFERED=1, que asegura que los logs de Python se escriban en tiempo real en journald, permitiéndoles revisar qué pasa con un simple comando journalctl -u mi-agente -f. Sin archivos de logs gigantes que llenan el disco duro de basura.

Cuándo usar cada herramienta: mi regla de oro

No se trata de elegir un bando. En mi día a día, uso ambas herramientas en conjunto para mantener la estabilidad del sistema. Mi regla de decisión es muy simple:

• Usen systemd si el script necesita estar activo las 24 horas, si maneja conexiones persistentes (como websockets), si realiza tareas de scraping continuo o si el tiempo de inactividad cuesta dinero real.
• Usen cron si la tarea dura menos de dos minutos, si se ejecuta en intervalos largos (diarios, semanales) y si no pasa nada grave si una ejecución se pierde ocasionalmente.

Si ustedes manejan un autonomous agents fleet freelance para diversos clientes, sabrán que la paz mental no tiene precio. Configurar la infraestructura de forma correcta desde el primer día es la única diferencia entre pasar el fin de semana con la familia o pasarlo reiniciando servidores colgados desde una laptop en un restaurante.

Mantener un entorno robusto con Python VPS systemd cron 24 7 requiere atención al detalle, monitoreo constante de recursos y una arquitectura que asuma que todo lo que puede fallar, eventualmente fallará.

Si ustedes prefieren delegar la administración técnica de sus bots y procesos automatizados para enfocarse únicamente en hacer crecer su negocio, podemos ayudarles. Nos encargamos de la configuración, el monitoreo y el mantenimiento preventivo de su infraestructura con nuestro servicio Флот автономных Python-агентов на VPS (systemd + cron), 24/7, garantizando que sus sistemas sigan corriendo sin interrupciones mientras ustedes duermen.