EQVPS

Cómo crear un servicio systemd para mantener una app en marcha

Convierte cualquier script o app en un servicio gestionado que arranca al inicio, se reinicia si se cae y registra en journalctl. Escribe un archivo unit, actívalo y revisa su estado — la forma estándar de tener algo funcionando 24/7 en Linux.

Ejecutar una app con & o nohup va bien hasta que el servidor se reinicia, el proceso se cae o quieres encontrar sus registros — entonces se desmorona. systemd es la respuesta estándar: arranca tu app al inicio, la reinicia si muere y captura sus registros. Convertir un script o binario en un servicio gestionado es un archivo pequeño.

1. Escribe un archivo unit

Crea /etc/systemd/system/myapp.service:

[Unit]
Description=My application
After=network.target

[Service]
User=myapp
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/python3 /opt/myapp/run.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Ajusta ExecStart, WorkingDirectory y User a tu app. Restart=always es lo que la mantiene viva.

2. Crea un usuario dedicado (recomendado)

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp
sudo chown -R myapp:myapp /opt/myapp

Ejecutar como usuario sin privilegios de root limita el daño si algún día comprometen la app.

3. Actívalo e inícialo

sudo systemctl daemon-reload
sudo systemctl enable --now myapp

enable hace que arranque al inicio; --now lo inicia de inmediato.

4. Revisa estado y registros

sudo systemctl status myapp
journalctl -u myapp -f       # seguir los registros en vivo

Comandos del día a día

sudo systemctl restart myapp   # reiniciar tras un cambio
sudo systemctl stop myapp      # detenerlo
sudo systemctl disable myapp   # dejar de arrancar al inicio

Advertencias honestas

Siguientes pasos

Un servicio systemd es como mantienes cualquier cosa funcionando 24/7 — por ejemplo un agente de IA que corre las 24 horas o el relay tras un servidor RustDesk autoalojado. Si tu app está contenerizada en su lugar, el --restart unless-stopped de Docker cumple el mismo papel — mira cómo instalar Docker.

Preguntas frecuentes

¿Por qué usar systemd en vez de solo ejecutar la app en segundo plano?

Un proceso en segundo plano (con & o nohup) muere al reiniciar, no vuelve si se cae y dispersa sus registros. Un servicio systemd arranca automáticamente al inicio, se reinicia ante un fallo y envía su salida a journalctl. Es la forma estándar y fiable de ejecutar algo de larga duración en Linux.

¿Dónde van los archivos unit?

Tus propios servicios van en /etc/systemd/system/, un archivo por servicio, con nombre tipo algo.service. Tras crear o editar uno, ejecuta 'systemctl daemon-reload' para que systemd tome el cambio, y luego actívalo e inícialo.

¿Qué hace 'Restart=always' y tiene desventajas?

Le dice a systemd que reinicie el servicio cada vez que termina, por cualquier motivo — la clave para mantener algo en marcha. La única trampa es el bucle de caídas: si la app falla al instante al arrancar, systemd la reinicia sin parar. Añade 'RestartSec=5' para espaciar los intentos, y revisa los registros para corregir el error de fondo.

¿Cómo veo los registros del servicio?

Usa 'journalctl -u yourservice -f' para seguir la salida en vivo, o sin -f para leer el historial. systemd captura stdout y stderr automáticamente, así que no necesitas cablear archivos de registro por tu cuenta.

¿El servicio debe ejecutarse como root?

Preferiblemente no. Crea un usuario dedicado sin privilegios de root y define 'User=' en el unit, para que un compromiso de la app no entregue toda la máquina. Ejecuta como root solo cuando el servicio realmente lo necesite.

Comentarios

Aún no hay comentarios. Sé el primero.

Deja un comentario

Los comentarios se moderan antes de aparecer.