Ejecutar procesos en segundo plano de manera controlada: systemd-run vs nohup vs tmux/screen

Comentarios

Si estamos conectados por ssh y sufrimos una desconexión mientras ejecutamos un comandos, puede representar un problema, desde la interrupción del proceso o la pérdida del acceso a la salida estándar/error del mismo. Existen comandod como nohup que de alguna manera nos ayudan a mitigar esas situaciones, tales como nohup, o multiplexores de terminal como screen y tmux.

Al usar systemd, contamos con una herramienta tan sencilla como poderosa: el comando systemd-run que permite ejecutar un comando muy sencillo como el siguiente en un servicio. O para ser más exactos en una service unit:

systemd-run --user ping 8.8.8.8


Comparación con nohup, tmux/screen

Característica systemd-run nohup tmux / screen
Supervisión del estado Sí, vía systemctl status y journalctl No, se debe usar ps o pgrep Parcial, requiere inspección manual de la sesión
Control del ciclo de vida Completo: iniciar, detener, reiniciar con políticas de reinicio Nulo: solo iniciar, sin reinicio automático Manual: requiere interacción del usuario
Manejo de logs Centralizado en journal, con metadata y timestamps Básico: redirige a nohup.out sin rotación Opcional: solo si se configura logging explícitamente
Integración con el sistema Alta: como unidad de systemd, con cgroup, slices, y logs centralizados Nula: proceso genérico del usuario Baja: proceso de usuario sin integración con systemd
Persistencia tras logout Alta: configurable vía lingering o como unidad del sistema Limitada: depende de configuración de logind Alta (tradicional), pero afectada por KillUserProcesses
Persistencia tras reinicio Posible mediante conversión a unidad persistente o uso de systemd-timer No, se requiere cron, scripts externos No, sesión se pierde tras reboot
Políticas de recursos/aislamiento Completa: límites CPU, memoria, I/O, namespaces, privilegios, etc. Nula: se requiere uso externo de ulimit o nice Nula: requiere herramientas externas
Facilidad de uso interactivo Baja: orientado a ejecución no interactiva Nula: no interactivo Alta: diseñado para interacción, múltiples ventanas/sesiones
Ideal para Tareas ad-hoc, servicios temporales, pruebas controladas Procesos simples que deben continuar tras logout Tareas interactivas largas o sesiones remotas persistentes

Más Ejemplos

Ansible

Advertencia: Los siguiente comandos no son para copiar y pegar sin analizarlos, deben ser ajustados al entorno en los cuales se los desea utiizar. El propósito principal es mostrar la potencia práctia de la herramienta systemd-run.

Objetivo: Ejecutar playbooks críticos en entornos controlados, como servicios temporales autoreiniciables.

systemd-run -p Restart=on-failure -p PrivateTmp=yes -p Description="Provisionar servidores" \
  -p SuccessExitStatus=0 \ 
  -p RestartSec=5 \ 
  -p TimeoutStopSec=30   \ 
  --unit=ansible-run ansible-playbook site.yml -i inventory/prod

Ventajas:

  • Crea un entorno temporal (/tmp aislado).
  • Si falla, se reinicia automáticamente.
  • El log de toda la ejecución queda en journal.

mysqldump

Objetivo: Realizar dumps de bases de datos con límites de memoria y sin cargar el sistema.

systemd-run \
  -p MemoryMax=750M \
  -p MemorySwapMax=150M \
  -p Nice=10 \
  -p Description="Backup de MySQL sin afectar el sistema" \
  --unit=mysql-dump \
  bash -c 'mysqldump --all-databases > /tmp/backup.sql'

Ventajas:

  • Protege al sistema de un uso excesivo de memoria
  • Alta prioridad de batch (Nice=10).
  • Log y control vía systemd.

Azure CLI

Objetivo: Apagar/desasignar todas las VMs del grupo "GrupoDesarrollo" en segundo plano

systemd-run --unit=apagar_vms \
    --service-type=oneshot \
    -p WorkingDirectory=/tmp \
    bash -c 'az login --identity && az vm list -g GrupoDesarrollo --query "[].id" -o tsv | xargs -r az vm deallocate --ids'

Ventajas:

  • Ejecución desacoplada de la terminal.
  • Se puede usar journalctl para auditar el comando.
  • Control sobre el entorno de ejecución

Conclusión

El comando systemd-run es una alternativa más robusta que otros comandos legacy o multiplexores de terminal, ya que permite, no solamente desacoplar el proceso de la terminal sino también poder gestionarlo perfectamente dentro de systend.

Fuentes y más recursos

Comentarios

Comments powered by Disqus