Curso de Linux / Reproducir fallos y recuperar un servicio con evidencias
La práctica de recuperación de fallos se realiza en un entorno separado, verificando primero el estado normal, luego cambiando solo una causa y restaurando según las evidencias observadas. Para determinar la finalización de la recuperación, se debe verificar tanto el estado de ejecución del servicio como la respuesta real del usuario.
Antes de la práctica, prepare instantáneas de VM y recuperación desde consola y compare las evidencias antes y después de los cambios siguiendo el procedimiento para acotar la causa con los logs.
Los ejemplos de servicios se orientan a máquinas virtuales con instalaciones habituales de Ubuntu 26.04 LTS y Rocky Linux 9. Contenedores, WSL y otras versiones pueden requerir cambios. Prepare el acceso de recuperación y compruebe la versión como se explica en crear un entorno de práctica con una máquina virtual.
Preparar el alcance de la práctica y los criterios de normalidad
Se utiliza una VM de práctica de Ubuntu o Rocky Linux con systemd administrador de usuario, Python 3 y curl. No se modifican Nginx, SSH, firewall ni discos en operación. Verifique si el puerto de loopback 18080 está libre con ss -lnt y, si ya está en uso, cambie todos los valores de puerto de esta práctica a otro número disponible.
Confirme la ruta de Python con command -v python3 y ajuste /usr/bin/python3 si es distinta. Si existen linux-course-recovery.service o ~/linux-recovery-lab, conserve su contenido y elija nombres nuevos para toda la práctica. Ejecute cada paso por separado y deténgase si falla la preparación. El servidor HTTP simple de Python se limita a esta prueba en la interfaz local; no lo utilice como servidor público de producción.
mkdir -p "$HOME/linux-recovery-lab/site" "$HOME/.config/systemd/user"
printf "recovery baseline\n" > "$HOME/linux-recovery-lab/site/index.html"
cat > "$HOME/.config/systemd/user/linux-course-recovery.service" <<'EOF'
[Unit]
Description=Isolated Linux recovery lab
[Service]
Type=simple
WorkingDirectory=%h/linux-recovery-lab/site
ExecStart=/usr/bin/python3 -m http.server 18080 --bind 127.0.0.1
EOF
systemctl --user daemon-reload
systemctl --user start linux-course-recovery.service
systemctl --user is-active linux-course-recovery.service
curl --fail --max-time 5 http://127.0.0.1:18080/
cp "$HOME/.config/systemd/user/linux-course-recovery.service" "$HOME/linux-recovery-lab/service.good"Introduzca el fallo únicamente cuando el servicio muestre active y la respuesta contenga recovery baseline. Un servicio Type=simple puede figurar como activo antes de que Python termine de abrir el puerto; si la primera petición falla, espere brevemente y revise estado, escucha y diario antes de repetirla. Guarde la copia service.good solo después de establecer la referencia normal. El ejemplo no habilita el arranque automático del servicio.
Experimento 1: Reproducir un fallo con ruta de ejecución incorrecta
sed -i 's@ExecStart=/usr/bin/python3 @ExecStart=/nonexistent/course-python @' "$HOME/.config/systemd/user/linux-course-recovery.service"
systemctl --user daemon-reload
systemctl --user restart linux-course-recovery.service
systemctl --user status linux-course-recovery.service --no-pager
journalctl --user -u linux-course-recovery.service --since "5 minutes ago" --no-pagerLa unidad apunta a un archivo ejecutable que no existe, por lo que no puede mantenerse activa. Dependiendo del momento, puede verificar fallos en el comando de inicio o en el status posterior. Consulte el journal para buscar fallos de ejecución y estados como 203/EXEC, y registre los mensajes reales. No interprete todos los fallos del servicio como problemas de red.
Restaurar la configuración normal y volver a verificar las respuestas
cp "$HOME/linux-recovery-lab/service.good" "$HOME/.config/systemd/user/linux-course-recovery.service"
systemctl --user daemon-reload
systemctl --user reset-failed linux-course-recovery.service
systemctl --user start linux-course-recovery.service
systemctl --user is-active linux-course-recovery.service
curl --fail --max-time 5 http://127.0.0.1:18080/Restaure el archivo de referencia y ejecute daemon-reload antes de iniciar de nuevo. reset-failed restablece el estado fallido y contadores de límite de inicio; no corrige la configuración ni borra el historial del diario. Considere recuperado el experimento cuando vuelvan tanto el estado del servicio como la respuesta esperada.
Experimento 2: Comparar cuando el puerto está cerrado y los errores HTTP
curl -i --max-time 5 http://127.0.0.1:18080/missing-resource
systemctl --user stop linux-course-recovery.service
curl -i --connect-timeout 2 --max-time 5 http://127.0.0.1:18080/
ss -lnt
systemctl --user start linux-course-recovery.service
curl --fail --max-time 5 http://127.0.0.1:18080/La primera solicitud recibe un HTTP 404 porque el servidor funciona pero no encuentra el recurso. Tras detenerlo, la conexión falla antes de obtener una respuesta HTTP. Sin --fail, curl puede devolver 0 al recibir un 404; con esa opción, un error HTTP produce un estado de fallo. Compare la respuesta y el estado de salida para distinguir errores de ejecución, conexión y aplicación.
Cambie y registre solo una condición a la vez
| Elementos a registrar | Lo que se debe dejar registrado en esta práctica |
|---|---|
| Criterio normal | Servicio activo, puerto en escucha y página esperada |
| Cambio | Ruta de ExecStart o detención del servicio |
| Evidencia | Estado, código de salida, diario, respuesta HTTP y socket |
| Recuperación | Restauración de archivo normal o inicio del servicio |
| Reverificación | Misma URL·puerto·cuerpo de respuesta |
| Prevención de recurrencia | Verificación de sintaxis·ruta y comprobación de estado antes de la distribución |
No se realizan experimentos en esta etapa que puedan perder la ruta de recuperación real, como llenar el disco, bloquear SSH o eliminar archivos aleatorios. Tales experimentos deben realizarse con un alcance definido en entornos con VM replicada separada, disco virtual limitado, consola verificada y respaldo disponible. El objetivo no es aumentar significativamente la falla, sino aprender el proceso de juicio desde la observación hasta la recuperación.
Detener el servicio de práctica y organizar solo los archivos creados
systemctl --user stop linux-course-recovery.service
systemctl --user reset-failed linux-course-recovery.service
rm -- "$HOME/.config/systemd/user/linux-course-recovery.service"
systemctl --user daemon-reload
ss -lntCompruebe que ya no haya escucha en 127.0.0.1:18080. Revise los archivos estáticos y la copia de referencia antes de retirarlos con el gestor de archivos. Las órdenes de esta sección se limitan a la unidad de práctica y conservan las demás; reset-failed no elimina su historial del diario.
