En 05-01 aprendiste a elegir con precisión los ficheros sobre los que actúa el toolkit. Pero un script de operaciones no solo lee y escribe: lanza procesos. informe-diario.sh invoca grep, bc, tar y consulta a la veloz-api; recorre cuatro ciudades una tras otra pudiendo hacerlo a la vez; y no tiene ninguna defensa si el informe de las 6:00 sigue corriendo cuando cron arranca el de las 6:05 —dos procesos escribiendo el mismo fichero, contadores mezclados y un informe sin sentido—. En 02-06 viste lo justo para no perder el control de la terminal: Ctrl-C, Ctrl-Z, jobs, fg, bg, &. Aquí completamos ese cuadro y lo llevamos al terreno del scripting: ver, buscar, lanzar en paralelo, esperar, señalizar, limitar y bloquear.

1. El modelo de procesos de Unix
2. Ver lo que corre: ps, pstree, top
3. Buscar procesos: pgrep
4. Primer y segundo plano
5. Sobrevivir al cierre de sesión: disown, nohup, setsid
6. $! y wait: paralelismo controlado
7. Señales
8. kill, pkill, killall y timeout
9. Prioridades con nice y renice
10. Una sola instancia a la vez: flock
11. Zombis y huérfanos

Un proceso es un programa en ejecución con su propia memoria, su entorno (las variables exportadas de 01-02) y un número que lo identifica: el PID. Todo proceso tiene además un PPID, el PID de quien lo creó. Eso convierte el sistema en un árbol cuya raíz es init/systemd (PID 1).

Cuando en 01-04 viste que un comando externo se ejecuta en un proceso hijo, eso es exactamente lo que ocurre: Bash se duplica (fork) y el duplicado se transforma en el comando (exec). De ahí salen dos consecuencias que ya conoces y que ahora encajan: el hijo hereda el entorno del padre, y nada de lo que el hijo cambie afecta al padre —el motivo por el que cd es un builtin y por el que el bucle de una tubería no ve sus variables (Módulo 4)—.

Los estados en los que puede estar un proceso aparecen en la columna STAT de ps: R ejecutándose o listo, S dormido esperando algo (lo normal), D en espera ininterrumpible de disco, T detenido, Z zombi.

ps tiene dos sintaxis históricas que conviven; ambas son correctas y verás las dos:

Las columnas de ps aux que de verdad se leen:

ps -ef muestra PPID en lugar de %CPU, lo que la hace mejor para investigar quién lanzó qué. Y -o selecciona solo los campos que te interesan, que es lo que se usa en scripts:

--sort=-rss ordena por memoria descendente; etime es el tiempo transcurrido desde el arranque, mucho más útil que TIME para saber si algo lleva colgado desde ayer.

pstree -p 2210 dibuja el árbol de un proceso y sus hijos, ideal para entender qué ha lanzado un script. top (y su versión cómoda htop) son interactivos: refrescan en vivo y sirven para mirar, no para programar. En un script nunca se usa top; se usa ps con -o.

El reflejo aprendido es ps aux | grep veloz-api, y tiene un defecto que causa bugs reales:

El grep aparece en su propia búsqueda, porque ps lo lista mientras corre. Un if ps aux | grep -q veloz-api da siempre cierto, aunque la API esté caída. La solución tradicional es el truco de la clase [v]eloz-api, pero la herramienta correcta existe:

-f es imprescindible para scripts: sin él, pgrep informe-diario.sh no encuentra nada, porque el nombre del proceso es bash, y el script es solo un argumento. Y pgrep devuelve código 0 si encontró algo y 1 si no, así que encaja directamente en una guarda de las de 03-04:

El shell agrupa los procesos que lanza en trabajos (jobs), y los numera. Recapitulando y ampliando 02-06:

Las referencias %1, %+ (el más reciente), %- (el anterior) y %?tar (por texto del comando) funcionan con fg, bg, kill y wait. Un detalle que importa: los trabajos son un concepto del shell interactivo; dentro de un script no hay control de trabajos, pero &, $! y wait sí funcionan, y son los que se usan.

Al cerrar la terminal, el shell envía SIGHUP (hang up, colgar, herencia de los módems) a sus trabajos, y estos mueren. Tres formas de evitarlo —nohup cmd > salida 2>&1 &, cmd & disown %1 y setsid cmd > /dev/null 2>&1 &—:

disown es el rescate cuando ya lanzaste algo largo y te das cuenta de que necesitas cerrar la sesión. Para tareas de verdad desatendidas, systemd (07-05) es la respuesta correcta; nohup es el apaño rápido.

$! contiene el PID del último proceso lanzado en segundo plano, y wait espera a que termine. Con esos dos, informe-diario.sh puede calcular las cuatro ciudades a la vez:

Tres cosas que hacen que este patrón funcione y no sea un simple "lanzar cosas":

• Cada hijo escribe en su propio fichero. Si todos escribieran en el mismo, sus salidas se entrelazarían a medias líneas. Un directorio de mktemp -d (05-01) es el sitio natural.
• wait PID devuelve el código de salida de ese hijo, así que el paralelismo no renuncia al control de errores.
• wait sin argumentos espera a todos los hijos, pero entonces pierdes los códigos individuales. wait -n devuelve en cuanto termina cualquiera de ellos, que es la base de una cola con un número máximo de tareas simultáneas.

Recuerda que cada hijo es un proceso separado: las variables que modifique no vuelven al padre. Por eso los resultados viajan por ficheros, exactamente igual que en el subshell de la tubería del Módulo 4.

Una señal es una notificación asíncrona que el núcleo entrega a un proceso. El proceso puede manejarla, ignorarla o dejar que actúe el comportamiento por defecto —salvo dos que nadie puede interceptar—.

El diagrama contiene la lección entera: la ruta por Limpiando es la que permite a un proceso cerrar ficheros, borrar temporales y dejar el sistema consistente. SIGKILL corta esa ruta. Capturar señales en tus propios scripts se hace con trap, y es el tema central de 05-03; aquí nos ocupamos de enviarlas.

Por qué kill -9 es el último recurso: SIGKILL no llega al proceso, lo ejecuta el núcleo. El programa no cierra sus ficheros (queda un CSV a medio escribir), no borra sus temporales, no libera su bloqueo, y sus hijos quedan huérfanos. La secuencia correcta es SIGTERM, esperar unos segundos comprobando con kill -0 "$pid" —que no envía ninguna señal, solo pregunta "¿existe y puedo señalizarlo?"— y solo si sigue vivo, SIGKILL. Lo montarás así en el ejercicio 3.

timeout resuelve el otro lado del problema: que algo no termine nunca.

Si expira, timeout devuelve 124. Ese código es la forma de distinguir "falló" de "tardó demasiado", y es imprescindible en cualquier llamada de red dentro de una tarea programada.

El valor va de -20 (máxima prioridad) a 19 (mínima). Solo root puede bajar el número; cualquiera puede subirlo, es decir, ser considerado. Para el archivado nocturno de Veloz Envíos, nice -n 10 junto con ionice -c 3 evita que la compresión compita con la veloz-api por CPU y disco.

El problema que abría la lección: dos informe-diario.sh simultáneos. El apaño casero es un fichero PID:

Es frágil por dos motivos. Entre la comprobación y la escritura hay una ventana en la que otro proceso hace lo mismo (condición de carrera, la misma familia que la del /tmp/fichero.$$ de 05-01). Y si el script muere de golpe, el fichero queda ahí y bloquea todas las ejecuciones futuras hasta que alguien lo borre a mano.

flock usa un bloqueo del núcleo asociado a un descriptor abierto, que el sistema libera solo cuando el proceso muere, pase lo que pase:

exec 9> abre el fichero en el descriptor 9 (los descriptores son el tema de 05-05; por ahora, léelo como "reserva el canal 9 para este fichero"). flock -n 9 intenta bloquearlo sin esperar. Si prefieres encolar en vez de abortar, flock -w 60 9 espera hasta 60 segundos. El bloqueo desaparece al terminar el script, aunque sea por SIGKILL. Cuando lleves esto a cron en 07-02 verás la variante de una sola línea, flock -n /ruta/lock comando, pensada justo para el crontab.

Cuando un proceso termina, su entrada permanece en la tabla del sistema hasta que su padre recoge el código de salida con wait. En ese intervalo es un zombi (STAT = Z): ya no consume CPU ni memoria, solo una entrada. Son normales y efímeros; solo son un síntoma si se acumulan cientos, lo que indica un padre que lanza hijos y nunca hace wait —exactamente el error que evita el patrón de la sección 6—.

Un huérfano es lo contrario: su padre murió antes que él. El sistema lo adopta asignándole init/systemd como padre, así que sigue funcionando con normalidad y alguien recogerá su código al terminar. Un proceso lanzado con nohup ... & acaba siendo un huérfano adoptado, y por eso sobrevive.

• ps aux | grep proceso en una condición. Se encuentra a sí mismo y siempre da cierto. Usa pgrep.
• pgrep informe-diario.sh sin -f. El proceso se llama bash; sin -f no encuentras tu script.
• Empezar por kill -9. Deja ficheros a medias, temporales sin borrar y bloqueos huérfanos. SIGTERM primero.
• Lanzar N tareas con & y no hacer wait. El script termina antes que sus hijos y los resultados no están.
• Esperar que un hijo modifique variables del padre. Es otro proceso: comunica por ficheros o por stdout.
• Ficheros PID caseros como bloqueo. Carrera al crearlos y bloqueo permanente si el script muere. Usa flock.
• Consejo: toda llamada a un servicio externo dentro de una tarea desatendida va envuelta en timeout. Un curl sin límite puede dejar colgada la tarea de las 6:00 hasta la del día siguiente.

Ejercicio 1. Escribe api_viva(), que devuelva 0 si el proceso veloz-api está corriendo y 1 si no, sin caer en el problema del grep que se encuentra a sí mismo, y que además informe por stderr del PID y de los minutos que lleva en marcha.

Ejercicio 2. Modifica el bucle de ciudades de informe-diario.sh para que las cuatro se calculen en paralelo, cada una en su fichero, esperando a todas y contando cuántas fallaron.

Ejercicio 3. Escribe una función parar_servicio() que envíe SIGTERM a todos los procesos veloz-api, espere hasta 15 segundos comprobando cada segundo y solo entonces recurra a SIGKILL, informando de qué camino tomó.

Solución 1.

pgrep -x exige nombre exacto y ya devuelve 1 si no hay coincidencias, así que el || return 1 basta como guarda (03-04). ps -o etime= con el = final imprime el valor sin cabecera, y tr -d ' ' quita el relleno de alineación.

Solución 2.

Los errores de cada hijo van a su propio .err para que no se entrelacen. Con cuatro ciudades el ahorro es de tres cuartas partes del tiempo si el cuello de botella es la lectura del CSV. Fíjate en que rm -rf "$tmpdir" solo se ejecuta si llegamos vivos hasta ahí; en 05-03 lo convertirás en un trap.

Solución 3.

$pids va sin comillas a propósito —el único caso de todo el curso en que eso es correcto—: queremos que la lista de PIDs se parta en varios argumentos para kill. Y el return 1 final permite a quien llama saber que hubo que forzar la muerte, lo que probablemente merezca una entrada en el registro.

Cada comando externo es un proceso con su PID, su PPID y su lugar en un árbol que nace en systemd. ps aux y ps -ef lo enseñan todo —con RSS y etime como columnas más útiles—, ps -eo selecciona campos para scripts, pstree dibuja la jerarquía y top/htop sirven para mirar en vivo, nunca para programar. pgrep, con -f y -x, sustituye al ps aux | grep que se encuentra a sí mismo. &, jobs, fg, bg y %1 gobiernan los trabajos del shell; nohup, disown y setsid los sacan del alcance de SIGHUP. La pareja $! + wait convierte cuatro cálculos secuenciales en cuatro paralelos sin renunciar a sus códigos de salida. Las señales son el lenguaje entre procesos: SIGTERM pide terminar y permite limpiar, SIGKILL no se puede interceptar y por eso es el último recurso, timeout pone un límite y devuelve 124. Y flock sobre un descriptor da la exclusión mutua que un fichero PID casero nunca dará.

informe-diario.sh ya sabe comprobar si la API está viva, repartir el trabajo entre cuatro procesos y negarse a ejecutarse dos veces a la vez. Pero sigue teniendo un agujero: si algo falla dentro —una variable sin definir, un grep sin resultados, un disco lleno a media escritura—, el script continúa como si nada y produce un informe silenciosamente falso, dejando además el temporal de mktemp sin borrar. En 05-03 cerramos ese agujero: set -euo pipefail con su crítica honesta, PIPESTATUS, trap con EXIT y ERR para la limpieza garantizada que llevamos dos lecciones prometiendo, una función morir() que informa de la línea exacta del fallo, un convenio de códigos de salida y las herramientas de depuración bash -x, PS4 y BASH_XTRACEFD.