Generador de servicios systemd y cron jobs
Armá un archivo .service de systemd listo para producción (auto-reinicio, logs con journald, arranque al boot) o una línea de crontab con traducción a lenguaje simple, más los comandos exactos para instalar cualquiera de los dos.
Se guardará como miapp.service
Usá siempre la ruta absoluta del binario (which node, which python3, etc.)
Usá network-online.target si tu app necesita internet ya disponible al arrancar (ej. conectarse a una DB remota)
[Unit]
Description=My App
After=network.target
[Service]
ExecStart=/usr/bin/node /home/user/app/server.js
WorkingDirectory=/home/user/app
User=www-data
Environment="NODE_ENV=production"
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
sudo nano /etc/systemd/system/miapp.service
# (pegá el contenido de arriba, guardá con Ctrl+O, salí con Ctrl+X)
sudo systemctl daemon-reload
sudo systemctl enable --now miapp.servicesudo systemctl status miapp
sudo journalctl -u miapp -f¿Por qué systemd en vez de screen, tmux o nohup?
Correr tu app dentro de una sesión de screen o tmux "funciona" para probar algo rápido, pero no es apto para producción: si el proceso crashea, nadie lo reinicia; si el servidor reinicia, la sesión desaparece y tenés que entrar a mano a levantarla de nuevo; y los logs quedan atrapados en el scrollback de esa terminal, sin rotación ni forma fácil de buscarlos. systemd resuelve los tres problemas a la vez: con Restart=always el proceso se reinicia solo si crashea, con WantedBy=multi-user.target arranca automáticamente cuando el servidor bootea (sin que nadie tenga que loguearse), y con journald todos los logs quedan centralizados, con timestamps y buscables con journalctl -u tu-servicio. Es el mismo mecanismo que usan Nginx, PostgreSQL, Docker y prácticamente todo demonio de Linux moderno.
El gotcha más común: crear el servicio no lo activa
systemctl start arranca el servicio ahora mismo, pero no hace nada al próximo reinicio. systemctl enable es lo que crea el symlink que lo deja "enganchado" al target multi-user.target para que arranque solo en el boot. Por eso el comando recomendado siempre es systemctl enable --now tu-servicio — hace las dos cosas en un solo paso: lo arranca ya y lo deja activado para la próxima vez.
La sintaxis de cron, campo por campo
Una línea de crontab tiene 5 campos de tiempo seguidos del comando a ejecutar. Cada campo acepta un valor exacto, un asterisco (*) que significa "cualquier valor", una lista separada por comas (1,15), un rango (1-5), o un paso (*/5, "cada 5 unidades").
| Campo | Rango | Notas |
|---|---|---|
| Minuto | 0-59 | |
| Hora | 0-23 | Formato 24hs |
| Día del mes | 1-31 | |
| Mes | 1-12 | |
| Día de la semana | 0-7 | 0 y 7 son ambos domingo |
Preguntas frecuentes
¿Por qué mi servicio no arranca al reiniciar el VPS?+
El motivo más común es que lo arrancaste con systemctl start pero nunca corriste systemctl enable — start solo lo prende en el momento, enable es lo que lo deja "enganchado" para arrancar en cada boot. Solución: systemctl enable --now tu-servicio (o revisá con systemctl is-enabled tu-servicio si ya está activado).
¿Cron usa la zona horaria del sistema?+
Sí, por defecto cron interpreta los horarios en la zona horaria del sistema operativo. Si tus jobs corren a una hora que no esperabas, revisá la zona horaria del VPS con timedatectl — muchos proveedores configuran los servidores en UTC por defecto, no en tu zona horaria local.
¿Por qué mi cron job funciona a mano pero no cuando lo ejecuta cron?+
Casi siempre es el PATH: cron ejecuta los comandos con un entorno mínimo, sin las variables ni el PATH ampliado de tu shell interactiva (bash, zsh). Usá siempre la ruta absoluta del binario (which node o which python3 para encontrarla) en vez de confiar en que el comando esté en el PATH.
¿Qué diferencia hay entre Restart=on-failure y Restart=always?+
on-failure reinicia el servicio solo si termina con un código de salida distinto de cero (un crash o error) — si vos lo detenés a mano con systemctl stop, no se reinicia. always lo reinicia sin importar cómo haya terminado, incluso si salió con código 0. Para la mayoría de las apps de producción, always es lo más predecible.
¿Necesitás un VPS donde correr esto de verdad?
VPS con NVMe real e IP dedicada, acceso root completo para instalar servicios systemd y cron jobs sin restricciones.
Ver planes