Introducción
Un sistema Linux en ejecución es mucho más que sus archivos. El kernel administra el hardware y los procesos; cada comando se ejecuta como un proceso con un identificador, y el shell realiza el seguimiento de los trabajos en primer y segundo plano. Los administradores primero observan este estado y después actúan sobre el proceso relevante más pequeño.
En este laboratorio identificarás el sistema operativo y el kernel, interpretarás el tiempo de actividad y los promedios de carga, inspeccionarás las relaciones entre procesos, localizarás procesos por nombre, enviarás señales de terminación, practicarás el control interactivo de trabajos, interpretarás el estado de salida, ejecutarás un comando desvinculado con nohup y consultarás los mensajes recientes del kernel.
Identificar el sistema e interpretar la carga
En este paso identificarás el kernel y la distribución, comprobarás cuánto tiempo lleva el sistema en ejecución y aprenderás qué representan los promedios de carga.
Crea y accede a un espacio de trabajo:
mkdir -p /home/labex/project/process-lab
cd /home/labex/project/process-lab
El comando uname muestra información del kernel. Las opciones -s, -r y -m seleccionan, respectivamente, el nombre del kernel, su versión y la arquitectura de la máquina:
uname -srm
uname -a muestra todos los campos disponibles en una sola línea:
uname -a
El kernel no es lo mismo que la distribución de Linux. Consulta los metadatos de la distribución:
cat /etc/os-release
Busca campos como NAME, VERSION e ID. A continuación, comprueba el tiempo de actividad y la carga:
uptime
La salida incluye la hora actual, cuánto tiempo lleva funcionando el sistema, el número de usuarios conectados y tres promedios de carga. Estos promedios describen el trabajo ejecutable o en espera no interrumpible durante aproximadamente 1, 5 y 15 minutos. No son porcentajes; su significado depende en parte del número de núcleos de la CPU.
Consulta el registro compacto de carga del kernel:
cat /proc/loadavg
Los tres primeros valores corresponden al concepto de promedio de carga. Los campos posteriores muestran las tareas ejecutables y el identificador de proceso asignado más recientemente.
Guarda un pequeño resumen del sistema para consultarlo más adelante:
uname -srm > system-summary.txt
uptime >> system-summary.txt
cat system-summary.txt
El archivo debe contener una línea con la información del kernel y otra con el tiempo de actividad.
Inspeccionar procesos y actividad de recursos
En este paso inspeccionarás los identificadores de proceso, las relaciones entre procesos padre e hijo, los estados y una instantánea de la actividad de los recursos del sistema.
Un proceso es un programa en ejecución. Cada proceso tiene un identificador de proceso, o PID. La mayoría de los procesos también tienen un identificador de proceso padre, o PPID, que identifica el proceso que los inició.
El comando ps muestra una instantánea de los procesos. Selecciona campos útiles y ordénalos por PID:
cd /home/labex/project/process-lab
ps -eo pid,ppid,user,stat,comm --sort=pid | head -n 15
La opción -e selecciona todos los procesos y -o define las columnas:
PIDes el identificador del proceso.PPIDes el identificador del proceso padre.USERes el propietario del proceso.STATes el estado del proceso junto con posibles indicadores adicionales.COMMANDes el nombre del ejecutable.
Entre las letras de estado más habituales se encuentran R para en ejecución, S para suspensión interrumpible, D para suspensión no interrumpible, T para detenido y Z para zombi. Un proceso en suspensión normalmente solo está esperando trabajo.
La variante de estilo BSD ps aux proporciona columnas de CPU y memoria, además de las líneas de comando completas:
ps aux | head -n 10
top se actualiza continuamente cuando se utiliza de forma interactiva. El modo por lotes permite obtener una instantánea estable: -b selecciona la salida por lotes y -n 1 solicita una sola actualización.
top -b -n 1 | head -n 12
La cabecera resume el tiempo de actividad, la carga, los estados de las tareas, el uso de la CPU y la memoria. La tabla de procesos que aparece debajo ayuda a localizar los procesos que consumen más recursos.
Ahora abre la vista interactiva:
top
Observa cómo se actualizan los valores, localiza las columnas %CPU y %MEM, y pulsa q para volver al shell. El modo interactivo de top resulta útil para observar cambios a lo largo del tiempo; el modo por lotes es mejor cuando necesitas guardar o procesar la salida.
Guarda una instantánea centrada en los procesos como resultado observable:
ps -eo pid,ppid,user,stat,comm --sort=pid > process-snapshot.txt
head -n 5 process-snapshot.txt
Iniciar y localizar un proceso de práctica
En este paso iniciarás un proceso inofensivo en segundo plano, guardarás su PID y lo localizarás tanto con ps como con pgrep.
El & final indica al shell que ejecute un comando en segundo plano y devuelva inmediatamente el indicador de comandos. Inicia un proceso sleep de cinco minutos con el nombre visible labex-worker:
cd /home/labex/project/process-lab
bash -c 'exec -a labex-worker sleep 300' &
El valor especial del shell $! contiene el PID del proceso en segundo plano iniciado más recientemente. Guárdalo antes de iniciar otro comando en segundo plano:
worker_pid=$!
echo "$worker_pid" > worker.pid
Inspecciona exactamente ese proceso. La opción -p selecciona un PID y -o elige los campos:
ps -o pid,ppid,user,stat,etime,args -p "$worker_pid"
ETIME muestra el tiempo transcurrido, mientras que ARGS incluye el nombre visible del proceso. Usa pgrep -f para buscar en la línea de comando completa; -a también la muestra:
pgrep -af labex-worker
El PID mostrado por pgrep debe coincidir con el contenido de worker.pid. Buscar mediante un patrón preciso es más seguro que actuar sobre todos los procesos que compartan un nombre genérico.
Detener procesos mediante señales
En este paso solicitarás una terminación ordenada con SIGTERM y utilizarás SIGKILL únicamente con un proceso diseñado para ignorar esa solicitud.
El comando kill envía una señal a un PID. Si no se especifica ninguna señal, envía SIGTERM, la señal 15. SIGTERM solicita un cierre ordenado y permite que el proceso tenga la oportunidad de realizar tareas de limpieza.
Lee el PID del proceso de trabajo y envía SIGTERM:
cd /home/labex/project/process-lab
worker_pid=$(cat worker.pid)
kill "$worker_pid"
sleep 1
El siguiente error esperado de ps confirma que el proceso terminó:
ps -p "$worker_pid" || echo "labex-worker stopped after SIGTERM"
Ahora inicia un proceso controlado que ignora intencionadamente SIGTERM:
bash -c 'trap "" TERM; exec -a labex-stubborn sleep 300' &
stubborn_pid=$!
echo "$stubborn_pid" > stubborn.pid
Espera un momento para que el nuevo shell instale su manejador de señales:
sleep 1
Envía SIGTERM, espera brevemente e inspecciona el proceso:
kill -TERM "$stubborn_pid"
sleep 1
ps -o pid,stat,args -p "$stubborn_pid"
El proceso debería seguir presente porque este proceso de práctica ignora SIGTERM. SIGKILL, la señal 9, no se puede capturar ni ignorar. Utilízala únicamente cuando una señal de terminación ordenada no sea eficaz:
kill -KILL "$stubborn_pid"
Recoge el trabajo en segundo plano terminado. El estado distinto de cero es esperado, por lo que || true permite que la secuencia de práctica continúe:
wait "$stubborn_pid" 2>/dev/null || true
ps -p "$stubborn_pid" || echo "labex-stubborn required SIGKILL"
SIGKILL no da al proceso ninguna oportunidad de guardar su estado ni de liberar correctamente los recursos de la aplicación, por lo que debe considerarse el último recurso.
kill actúa sobre un PID conocido. Cuando necesites seleccionar un proceso por su nombre o por la línea de comandos completa, pkill combina la búsqueda y el envío de señales. Inicia otro proceso controlado con una línea de comandos distintiva:
bash -c 'exec -a labex-helper sleep 300' &
helper_pid=$!
echo "$helper_pid" > helper.pid
Confirma la coincidencia exacta de la línea de comandos completa antes de actuar:
pgrep -af '^labex-helper 300$'
Envía SIGTERM a esa coincidencia exacta con pkill -f. Los anclajes ^ y $ evitan que el patrón de práctica coincida con líneas de comandos no relacionadas:
pkill -TERM -f '^labex-helper 300$'
wait "$helper_pid" 2>/dev/null || true
ps -p "$helper_pid" || echo "labex-helper stopped by pkill"
Utiliza patrones precisos con pkill y comprueba primero las coincidencias con pgrep; un patrón demasiado amplio puede detener más procesos de los previstos.
Controlar trabajos en primer y segundo plano
En este paso suspenderás un comando en primer plano, lo reanudarás en segundo plano, lo devolverás al primer plano y lo interrumpirás.
El control de trabajos pertenece al shell interactivo actual. Inicia un proceso sleep en primer plano con un nombre reconocible:
cd /home/labex/project/process-lab
bash -c 'exec -a labex-job sleep 300'
El terminal está ahora ocupado por el proceso en primer plano. Pulsa Ctrl+Z. El shell enviará una señal de detención y devolverá el indicador de comandos.
Muestra los trabajos conocidos por este shell. La opción -l incluye el identificador del proceso:
jobs -l
Deberías ver un trabajo con el estado Stopped. Reanuda el trabajo número 1 en segundo plano:
bg %1
jobs -l
El estado debería ser ahora Running y el indicador de comandos seguirá disponible. Devuelve el trabajo al primer plano:
fg %1
Pulsa Ctrl+C para enviar una señal de interrupción al trabajo en primer plano. El indicador de comandos debería reaparecer. Confirma que no queda ningún trabajo de práctica:
pgrep -af labex-job || echo "No labex-job process remains"
Crea un marcador de finalización cuando hayas terminado la secuencia interactiva:
touch job-control.done
Utiliza el control de trabajos para los comandos vinculados al terminal actual. Más adelante utilizarás nohup para ejecutar tareas que no dependan de la sesión del terminal.
Leer el estado de salida y ejecutar tareas desvinculadas
En este paso interpretarás el estado de salida de los comandos y ejecutarás una tarea breve en segundo plano cuya salida se conservará independientemente de lo que se muestre en el terminal.
Cada comando devuelve un estado entero. Cero significa que la operación tuvo éxito; un valor distinto de cero indica algún tipo de error. La variable del shell $? contiene el estado del comando que acaba de finalizar.
Ejecuta un comando exitoso y muestra inmediatamente su estado:
cd /home/labex/project/process-lab
true
echo "true status: $?"
El resultado es 0. Ahora ejecuta un comando cuyo directorio no existe:
ls missing-path
Guarda su estado antes de que otro comando reemplace $?:
missing_status=$?
echo "missing-path status: $missing_status"
El valor es distinto de cero. Guarda ambas interpretaciones esperadas:
printf 'success=0\nfailure=%s\n' "$missing_status" > exit-status.txt
El comando nohup hace que un programa ignore la señal de cierre de la terminal. El & final lo inicia en segundo plano. La redirección < /dev/null desconecta la entrada del terminal, mientras que > nohup.log 2>&1 envía ambos flujos de salida a un registro:
nohup bash -c 'for item in one two three; do echo "background: $item"; sleep 1; done' < /dev/null > nohup.log 2>&1 &
Guarda el PID del proceso en segundo plano y espera a que la tarea breve termine:
echo $! > nohup.pid
sleep 4
cat nohup.log
Deberías ver tres líneas, desde background: one hasta background: three. Para tareas de larga duración, el PID guardado y el registro proporcionan formas de comprobar el progreso.
Inspeccionar los mensajes recientes del kernel
En este paso inspeccionarás el búfer de mensajes del kernel y guardarás la versión del kernel en ejecución como referencia estable.
El kernel registra en un búfer circular los mensajes relacionados con el arranque, el hardware, los controladores y los eventos de ejecución. dmesg lee ese búfer. Normalmente se requieren privilegios administrativos:
cd /home/labex/project/process-lab
sudo dmesg | tail -n 10
Los mensajes exactos varían según la máquina y el momento. Presta atención al campo con aspecto de marca temporal y al componente o subsistema que produjo cada mensaje.
La opción --level filtra por gravedad. Muestra las advertencias y los errores recientes:
sudo dmesg --level=err,warn | tail -n 10
Que no aparezca ninguna salida no significa que el comando haya fallado; puede indicar que el búfer actual no contiene mensajes con esos niveles. Busca en los mensajes recientes términos habituales relacionados con el almacenamiento y la red:
sudo dmesg | grep -Ei 'disk|filesystem|network|eth' | tail -n 10
De nuevo, los resultados dependen del sistema actual. Guarda la versión del kernel que informa uname -r:
uname -r > kernel-version.txt
cat kernel-version.txt
Los mensajes del kernel son indicios, no diagnósticos automáticos. Antes de decidir qué acción tomar, combínalos con el estado de los procesos, los registros de los servicios y los síntomas observados.
Resumen
Identificaste un sistema Linux, interpretaste el tiempo de actividad y los promedios de carga, e inspeccionaste los PID, los procesos padre, los propietarios, los estados y las instantáneas de recursos. Iniciaste y localizaste un proceso con nombre, utilizaste SIGTERM antes que SIGKILL y practicaste el control de trabajos en primer y segundo plano.
También interpretaste el estado de salida, ejecutaste tareas desvinculadas con nohup y registros explícitos, e inspeccionaste los mensajes del kernel mediante dmesg. Estos hábitos, basados primero en la observación, constituyen la base de una resolución segura de problemas de procesos y te preparan para los diagnósticos de servicios, registros y redes que abordarás más adelante en el curso.
