Cómo dejar un proceso corriendo en el VPS después de cerrar SSH

Por qué el proceso muere cuando se corta la conexión

Al entrar por SSH, el sistema te asigna una terminal y un intérprete de comandos, y todo lo que lanzás cuelga de ahí. Cuando la conexión se cae, esa terminal desaparece y el sistema les manda a sus procesos la señal SIGHUP, que por defecto los termina. Agregar & al final del comando solo lo manda al fondo: sigue siendo hijo de la misma sesión.

nohup hace que el proceso ignore esa señal, y por eso sobrevive al corte. Pero es una solución a medias: la salida va a parar a un archivo nohup.out, no podés volver a interactuar con el proceso, nadie lo levanta si falla y un reinicio del servidor lo borra del mapa.

Qué herramienta usar en cada caso

Hay cuatro situaciones y cada una tiene su herramienta. La última, las tareas periódicas, tiene guía propia en programar tareas con cron y systemd.

tmux: una sesión que te espera

tmux mantiene una terminal viva en el servidor, independiente de tu conexión. Te desenganchás, cerrás la notebook y al día siguiente encontrás todo como lo dejaste, con la salida en pantalla. Está en los repositorios de todas las distribuciones: sudo apt install tmux en Debian y Ubuntu, sudo dnf install tmux en AlmaLinux.

tmux new -s importacion            # abre una sesión con nombre
# ... lanzás el comando largo ...
# Ctrl-b y después d: te desenganchás sin cortar nada
tmux ls                             # lista las sesiones abiertas
tmux attach -t importacion          # volvés a entrar
tmux kill-session -t importacion    # la cerrás cuando terminó

• Para ver lo que ya pasó por pantalla, Ctrl-b y después [ activa el modo de desplazamiento; con q salís.
• Ctrl-b % divide la ventana en dos, útil para tener htop al lado del proceso.
• Si en el servidor ya está screen, sirve igual con otros atajos: screen -S importacion para abrir, Ctrl-a d para desengancharte y screen -r importacion para volver. Si la conexión se cortó antes de desengancharte y screen dice que la sesión está ocupada, screen -d -r importacion la libera y te la devuelve.

systemd-run: un servicio de un solo uso

Menos conocido y muy práctico: systemd-run lanza un comando como servicio temporal, fuera de tu sesión. Sobrevive al corte de SSH, su salida queda en el journal con fecha y hora, y cuando termina, desaparece solo. Es ideal para una copia grande o una conversión que no necesitás mirar en vivo. Con --uid= elegís con qué usuario corre.

sudo systemd-run --unit=copia-fotos rsync -a /srv/fotos/ /mnt/respaldo/fotos/
systemctl status copia-fotos      # mientras corre
journalctl -u copia-fotos -f      # la salida, en vivo o cuando ya terminó

Una unidad de systemd para lo que tiene que estar siempre

Supongamos un worker en Python que procesa una cola, instalado en /opt/cola con su entorno virtual, que corre con un usuario sin privilegios llamado deploy (si todavía hacés todo como root, antes mirá cómo crear un usuario con sudo). La unidad va en /etc/systemd/system/cola.service, y el nombre del archivo es el nombre del servicio:

[Unit]
Description=Worker de la cola de pedidos
Wants=network-online.target
After=network-online.target mariadb.service
[Service]
User=deploy
WorkingDirectory=/opt/cola
EnvironmentFile=/etc/cola.env
ExecStart=/opt/cola/venv/bin/python worker.py
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target

• After= con el nombre de la base hace que arranque después de ella, pero no espera a que acepte conexiones. Si el worker falla por eso, Restart=on-failure lo reintenta cada cinco segundos hasta que la base responde.
• EnvironmentFile= carga variables como contraseñas o direcciones de APIs desde un archivo aparte. Dale permisos 600 y dejalo con dueño root: systemd lo lee antes de pasar al usuario del servicio.
• ExecStart= usa la ruta completa del intérprete del entorno virtual. systemd no lee tu .bashrc ni activa entornos, y solo encuentra por nombre los programas de las carpetas estándar como /usr/bin; Node instalado con nvm o cualquier cosa de tu carpeta personal va con la ruta entera.
• Sin User=, el servicio corre como root. Con User=deploy, la carpeta /opt/cola y todo lo que escriba el programa tienen que pertenecer a ese usuario.

Activarla y probar que vuelve sola

1. Avisale a systemd que hay un archivo nuevo o modificado: sudo systemctl daemon-reload.
2. Habilitala para el arranque e iniciala en el mismo paso: sudo systemctl enable --now cola.
3. Revisá el estado con systemctl status cola. Tiene que decir active (running) y mostrar las últimas líneas de la salida.
4. Probá el reinicio automático matando el proceso a propósito con sudo systemctl kill -s KILL cola. A los cinco segundos, el estado tiene que volver a active.
5. Reiniciá el servidor con sudo reboot y, al volver, confirmá con systemctl is-active cola. Es la única prueba de que arranca sola.

Leer la salida en journalctl

Todo lo que el programa escribe en pantalla, errores incluidos, queda en el journal con fecha, hora y nombre del servicio. No hace falta redirigir a un archivo ni armar una rotación.

journalctl -u cola -f                      # en vivo, mientras probás
journalctl -u cola --since "30 min ago"    # la última media hora
journalctl -u cola -n 50 --no-pager        # las últimas 50 líneas
journalctl -u cola -b -1                   # lo que pasó en el arranque anterior

• La última opción necesita que el journal se guarde en disco. Si no existe la carpeta /var/log/journal, el registro vive en memoria y se pierde al reiniciar; se activa con sudo mkdir -p /var/log/journal y sudo systemctl restart systemd-journald.
• journalctl --disk-usage muestra cuánto ocupa, y sudo journalctl --vacuum-time=30d borra lo que tenga más de un mes.

Cuando no arranca: qué dice el estado

Si systemctl status muestra failed, la línea del proceso principal trae un código que casi siempre alcanza para saber qué pasó:

systemd deja de reintentar si una unidad arranca más de 5 veces en 10 segundos. Con RestartSec=5 no se llega a ese límite; sin esa línea, los reintentos son casi inmediatos y se llega enseguida.

Dos trampas que no dejan un código claro

La primera: tuberías, redirecciones y variables del intérprete (|, >, $HOME) no funcionan en ExecStart, porque systemd ejecuta el programa directamente, sin un intérprete de comandos en el medio. Si los necesitás, el comando entero va dentro de /bin/sh -c "...".

La segunda: un programa que se manda solo al fondo. systemd ve terminar el proceso que lanzó y da el servicio por muerto, o lo reinicia en un ciclo. Casi todos los programas tienen una opción para quedarse en primer plano, y es la que hay que usar.