Un sistema como capas, interfaces y estado

Antes de empezar#

Cuando una aplicación «no funciona», la frase todavía no identifica un problema. Puede que el programa no se haya iniciado, que el proceso exista pero no escuche donde esperábamos, que el kernel rechace el acceso a un archivo, que el nombre apunte a otro destino o que la aplicación reciba la petición y falle al procesarla. El mismo síntoma visible puede nacer en lugares distintos.

Para orientarnos necesitamos un mapa. No un inventario exhaustivo de piezas, sino un modelo que permita responder:

• ¿qué capa intenta hacer algo?;
• ¿qué interfaz utiliza para pedirlo?;
• ¿qué recurso necesita?;
• ¿qué estado debería existir y cuál existe realmente?;
• ¿en qué frontera puede haberse perdido, rechazado o transformado la operación?;
• ¿qué observación distinguiría una causa de otra?

Dependencias. Ninguna unidad anterior. Se presupone únicamente uso básico de un ordenador y capacidad para leer fragmentos cortos de terminal. Los comandos de las demostraciones son instrumentos de observación, no contenido que debas memorizar todavía.

Alcance. Esta unidad introduce capas, interfaces, recursos, mecanismos, políticas, estado deseado y estado observado, además de la diferencia entre proceso, servicio y aplicación.

Fuera de alcance. No estudia microarquitectura, ensamblador, implementación interna del kernel, programación de llamadas al sistema ni protocolos de red en detalle. Esos temas solo aparecen hasta el nivel necesario para construir el mapa.

1. El mapa del sistema#

Un sistema informático combina recursos físicos, software que los controla y programas que persiguen objetivos concretos. Podemos recorrerlo desde la intención visible hasta los mecanismos que la materializan:

persona u otro sistema
        ↓
aplicación y sus bibliotecas
        ↓
proceso en espacio de usuario
        ↓
interfaz del sistema operativo
        ↓
kernel
        ↓
CPU, memoria, almacenamiento y dispositivos de red

Cuando hay comunicación con otro host, el recorrido continúa a través de interfaces de red, enlaces e intermediarios hasta repetir, en sentido inverso, varias capas en el destino.

Cada nivel recibe una petición formulada en términos que entiende, consulta o modifica estado y entrega un resultado al nivel superior. Una aplicación pide «leer este archivo»; el kernel trabaja con rutas resueltas, permisos, descriptores y un sistema de archivos; el dispositivo termina moviendo bloques o devolviendo datos ya presentes en memoria. La intención inicial se traduce varias veces.

La guía curricular CS2023 de Systems Fundamentals utiliza precisamente capas, interfaces bien definidas, interacción aplicación-SO y propagación de errores para integrar fundamentos que a menudo se estudian por separado.

Una operación no pertenece a una sola capa#

Imagina que una aplicación muestra el contenido de un archivo de configuración. La funcionalidad pertenece a la aplicación, pero el resultado depende de:

1. código de la aplicación que construye la ruta y decide qué hacer con los datos;
2. un proceso con identidad, memoria y descriptores propios;
3. bibliotecas o un runtime que convierten una función cómoda en operaciones del sistema;
4. el kernel, que resuelve la ruta, aplica permisos y accede al sistema de archivos;
5. memoria, caché y almacenamiento, donde existen los datos;
6. configuración y estado previos: montaje correcto, archivo existente y acceso permitido.

Decir «la aplicación lee el disco» es una abreviatura aceptable en una conversación informal. Para diagnosticar resulta demasiado imprecisa: omite quién pide, quién media, qué estado se consulta y dónde puede fallar.

2. Capas y fronteras#

Kernel y espacio de usuario#

La separación entre kernel y espacio de usuario es una frontera de protección. Las aplicaciones ordinarias no ejecutan cualquier instrucción privilegiada ni escriben directamente en cualquier dirección de dispositivo. Solicitan operaciones al sistema operativo mediante interfaces controladas. El kernel valida contexto y permisos, realiza o rechaza la operación y devuelve un resultado.

Esta mediación permite compartir recursos sin entregar a cada programa control absoluto sobre la máquina. También crea una frontera diagnóstica: una aplicación puede formular mal una petición, el kernel puede rechazarla por permisos o estado, y el dispositivo puede informar un fallo que el kernel traduce antes de que el programa lo vea.

Proceso, servicio y aplicación#

Un programa es código y datos almacenados. Un proceso aparece cuando se ejecuta ese programa bajo un contexto concreto. Puede haber muchos procesos del mismo programa.

Una aplicación es una unidad de comportamiento: reglas, código, configuración y dependencias que producen una función útil. Puede vivir en un proceso simple o repartirse entre varios.

Un servicio añade una perspectiva operativa. No solo pregunta qué hace el código, sino bajo qué identidad se inicia, qué dependencias necesita, qué estado se considera saludable, qué debe ocurrir si termina y dónde se registra su actividad. En systemd, el gestor recibe unidades y configuración y controla procesos asociados, dependencias y recursos; el servicio no se reduce conceptualmente a un PID.

3. Recursos e interfaces#

Un recurso es algo finito, identificable o protegido que una parte utiliza: tiempo de CPU, memoria, un archivo, un socket, ancho de banda, una identidad, un dispositivo o una entrada de configuración. Los recursos no son solo hardware. Una ruta, un puerto o una cuota pueden ser tan decisivos para una operación como el procesador.

Una interfaz determina cómo se solicita o se observa ese recurso. Algunas interfaces son llamadas o protocolos; otras parecen archivos, comandos o endpoints:

• una aplicación utiliza una API de biblioteca;
• la biblioteca puede solicitar una operación al kernel;
• /proc expone información sobre el sistema y los procesos mediante una interfaz con forma de archivos;
• un cliente utiliza un protocolo para hablar con un servicio;
• una persona utiliza una herramienta que, a su vez, consulta una interfaz inferior.

La documentación del kernel describe procfs como una interfaz a estructuras internas. Directorios como /proc/<pid>/ exponen estado de un proceso: argumentos, ejecutable, descriptores, memoria y estado. Esto no significa que «todo sea un archivo» de manera literal; significa que Linux reutiliza una interfaz familiar para presentar determinado estado.

Contratos en las fronteras#

Una interfaz útil establece un contrato: entradas válidas, resultados posibles y errores. La capa superior no necesita conocer toda la implementación inferior, pero sí debe respetar ese contrato e interpretar el resultado.

Si una operación de apertura devuelve «permiso denegado», el programa no necesita saber cómo el kernel recorrió cada estructura interna para reconocer que no obtuvo el recurso. Para diagnosticar la causa concreta sí necesitaremos observar identidad, ruta y permisos. La abstracción oculta detalle, pero no elimina el estado ni los límites.

4. Mecanismo y política#

Separar mecanismo y política evita atribuir decisiones a la capa equivocada.

El kernel proporciona mecanismos para crear procesos, asignar CPU, proteger memoria y aplicar permisos. La configuración, las herramientas administrativas y las aplicaciones expresan muchas de las políticas. La frontera no siempre es perfecta: el kernel también incorpora políticas por defecto y una aplicación puede implementar sus propios mecanismos. Aun así, la distinción ayuda a formular mejores preguntas.

5. Estado y transiciones#

Un sistema no se describe solo por sus componentes. También importa su estado en un momento determinado: procesos existentes, archivos abiertos, configuración cargada, sockets escuchando, rutas presentes, datos almacenados y recursos disponibles.

Una transición es un cambio entre estados. Iniciar un servicio puede crear procesos y sockets; cargar una configuración puede alterar el comportamiento sin cambiar el binario; terminar un proceso libera unos recursos y puede activar una política de reinicio.

configurado pero inactivo
        ↓ iniciar
activándose
        ↓ listo
activo y atendiendo
        ↓ fallo
fallido
        ↓ reinicio o intervención
activándose

El estado visible depende de la capa. Un gestor puede considerar una unidad «activa» mientras la aplicación aún no está preparada para responder. El kernel puede mostrar un socket en escucha aunque una dependencia interna esté caída. Un monitor HTTP puede confirmar una respuesta correcta sin demostrar que todos los workers están sanos.

Estado deseado y estado observado#

La configuración expresa intención, no prueba de realidad:

• estado deseado: el servicio debe iniciar, escuchar en el puerto 8000 y leer cierta configuración;
• estado observado: existe un proceso, el socket está o no está en escucha, se cargó una ruta concreta y las peticiones producen cierto resultado.

Entre ambos puede existir deriva. Quizá se editó el archivo pero el proceso conserva la configuración anterior; quizá el proceso correcto existe, pero otra instancia ocupa el puerto; quizá una automatización declara un usuario que alguien modificó manualmente.

Estado persistente y efímero#

Otra distinción útil es cuánto sobrevive el estado:

• un proceso y sus descriptores suelen desaparecer cuando termina;
• una dirección añadida de forma temporal puede desaparecer al reiniciar o al actuar el gestor de red;
• un archivo de configuración suele persistir, pero solo influye cuando algún componente lo lee;
• un log persistente puede conservar evidencia después de que el proceso haya desaparecido;
• una caché puede acelerar una operación y, al mismo tiempo, mostrar durante un periodo un valor anterior.

«Está configurado» y «está activo» no son sinónimos. Tampoco lo son «funciona ahora» y «sobrevivirá al siguiente arranque».

6. Seguir una lectura de archivo#

Sigamos una operación local sin entrar todavía en implementación interna. Una aplicación quiere leer /srv/catalogo/config.toml.

1. La aplicación construye la petición. Su código decide la ruta y solicita abrirla en modo lectura mediante la biblioteca o runtime correspondiente.

2. El proceso aporta contexto. La operación ocurre bajo una identidad efectiva, un directorio raíz y un conjunto de descriptores. La misma aplicación ejecutada con otro contexto puede obtener otro resultado.

3. La interfaz del sistema operativo recibe la solicitud. La biblioteca traduce la operación de alto nivel a las operaciones que ofrece el sistema. La petición cruza la frontera hacia el kernel.

4. El kernel resuelve y comprueba. Recorre la ruta dentro del árbol visible para ese proceso, identifica el objeto y el montaje correspondientes y aplica las comprobaciones de acceso.

5. El sistema de archivos obtiene los datos. Pueden estar ya en memoria o requerir acceso al dispositivo. La aplicación no necesita saber cuál de esos caminos ocurrió para recibir bytes, pero el rendimiento y algunos fallos sí dependen de ello.

6. El kernel devuelve un resultado. Si tiene éxito, entrega un descriptor que el proceso utiliza para leer. Si falla, devuelve una condición como «no existe» o «permiso denegado».

7. La aplicación interpreta. Puede cargar la configuración, usar un valor por defecto, registrar el error o terminar. Esa política pertenece a la aplicación, no al kernel.

Este recorrido permite elegir una observación con intención. Antes de aumentar permisos conviene saber si la ruta existe en el contexto del proceso. Antes de reiniciar conviene saber si la aplicación recarga automáticamente, si conserva estado y qué evidencia se perdería.

7. Seguir una petición local#

Ahora una herramienta ejecuta:

curl --verbose http://127.0.0.1:8000/salud

No es una práctica ni requiere que lo ejecutes. Es una demostración para relacionar capas. La opción --verbose permite observar detalles de la operación y cabeceras; su manual advierte que esa salida puede contener credenciales o datos sensibles y no debe compartirse sin revisar.

Supongamos esta salida reducida:

* Connected to 127.0.0.1 port 8000
> GET /salud HTTP/1.1
> Host: 127.0.0.1:8000
< HTTP/1.1 200 OK
< Content-Type: application/json
{"estado":"ok"}

1. curl es una aplicación y un proceso. Interpreta la URL, decide usar HTTP y pide al sistema operativo una conexión hacia 127.0.0.1:8000.

2. El socket es una interfaz. La aplicación no manipula directamente paquetes en la tarjeta. Utiliza la interfaz de sockets; el kernel mantiene estado de transporte y entrega datos entre extremos.

3. 127.0.0.1 selecciona loopback. El destino es local. La operación atraviesa la pila de red del kernel, pero no necesita salir por una interfaz física hacia otro host.

4. Debe existir un extremo en escucha. Algún proceso ha asociado un socket local compatible al puerto 8000. Si no existe, la conexión puede ser rechazada antes de que la aplicación servidora lea HTTP.

5. El proceso servidor recibe bytes. Su servidor HTTP interpreta método, path y cabeceras y entrega la operación al código de la aplicación.

6. La aplicación decide el resultado. Puede comprobar dependencias y producir el cuerpo {"estado":"ok"}. El servidor lo expresa como respuesta HTTP.

7. El estado deja evidencia en varios lugares. Durante la operación pueden observarse el proceso, el socket, la conexión, la respuesta y un evento de log. Ninguna vista aislada cuenta toda la historia.

Tres vistas de la misma operación#

La investigación gana fuerza cuando dos o más vistas independientes concuerdan. Si el cliente recibe rechazo y no existe socket en escucha, la hipótesis «el proceso no está atendiendo ese puerto» es mejor que «el JSON es incorrecto». Si existe socket y llega HTTP 500, la conectividad básica ya ocurrió; la siguiente observación debe acercarse a la aplicación o sus dependencias.

8. Local y remoto#

El recorrido local y el remoto comparten muchas piezas, pero no el mismo alcance.

En 127.0.0.1, cliente y servidor usan el mismo kernel. No intervienen el enlace físico, el switch o un router externo. Una prueba por loopback confirma que el proceso local y la pila necesaria para esa ruta funcionan; no confirma que otro host pueda llegar.

En una conexión remota aparecen más estados:

cliente → resolver de nombres → ruta local → interfaz/enlace
        → redes intermedias → interfaz del servidor → ruta/firewall
        → socket en escucha → proceso → aplicación

La representación sigue siendo simplificada. DNS puede ocurrir antes de la conexión, un proxy puede convertirse en el servidor visible y un balanceador puede seleccionar otro host. Lo importante es no colapsar todo bajo la palabra «red».

9. Dónde observar#

Las siguientes herramientas reaparecerán con profundidad en unidades posteriores. Aquí interesan por la pregunta que permiten formular, no por sus opciones.

Observar antes de mutar#

Una herramienta de observación reduce incertidumbre sin intentar arreglar todavía. Reiniciar, matar procesos, cambiar permisos, editar rutas o desactivar filtrado son mutaciones. Pueden resolver temporalmente un síntoma, destruir evidencia o introducir una segunda causa.

La secuencia segura inicial es:

definir el síntoma y el alcance
        ↓
capturar estado relevante
        ↓
formular hipótesis distintas
        ↓
elegir una observación que las separe

La Unidad 1.3 desarrollará este método. Por ahora basta con reconocer que una capa sugiere una familia de observaciones, no una receta universal.

10. Errores que atraviesan capas#

Una capa puede detectar un fallo y expresarlo hacia arriba mediante un código, una excepción, un status o un log. Durante la traducción puede perderse detalle:

dispositivo informa error
        ↓
kernel devuelve fallo de entrada/salida
        ↓
biblioteca devuelve una condición de error
        ↓
aplicación registra “no se pudo cargar configuración”
        ↓
cliente recibe “servicio no disponible”

El mensaje superior describe el impacto desde su propio contrato, no necesariamente la causa raíz. Por eso una respuesta 503 no demuestra por sí sola que la red esté caída; puede ser la manera en que la aplicación expresa que una dependencia no está preparada.

También puede ocurrir lo contrario: la capa inferior funciona y la superior interpreta mal. El kernel puede entregar correctamente un archivo cuyo contenido viola el formato esperado. La conectividad puede entregar una respuesta HTTP que la aplicación cliente no sabe procesar.

Fallo, causa y síntoma#

• Fallo o condición: un componente no cumple una expectativa concreta.
• Síntoma: la evidencia visible para una persona o capa superior.
• Causa: el mecanismo y estado que explican ese fallo.
• Impacto: qué capacidad dejó de estar disponible y para quién.

Estas palabras no siempre tienen una frontera absoluta. Una base de datos inaccesible es causa del error de una API y, a la vez, síntoma de un problema de red o de identidad. El análisis debe declarar el nivel al que se refiere.

11. Errores conceptuales frecuentes#

La nube cambia el límite de responsabilidad#

En un servicio gestionado quizá no administras el kernel ni ves el dispositivo físico. Eso no hace desaparecer esas capas: el proveedor las opera y expone una interfaz más alta. Tu responsabilidad puede desplazarse hacia configuración, identidad, datos, red lógica, consumo y verificación.

El modelo sigue siendo útil porque obliga a preguntar qué controlas, qué observas y qué garantiza realmente el proveedor. «Gestionado» describe una división de trabajo; no significa ausencia de estado, límites o fallos.

12. Síntesis y criterio de dominio#

Un sistema puede entenderse como capas que cooperan mediante interfaces. La aplicación expresa una intención; un proceso aporta contexto; bibliotecas y runtimes usan la interfaz del sistema operativo; el kernel protege y asigna recursos; hardware y red materializan parte de la operación. Cada frontera transforma información, conserva estado y puede rechazar o propagar un error.

Las distinciones más importantes son:

• programa no es proceso;
• proceso no es servicio;
• configuración no es estado observado;
• mecanismo no es política;
• funciona localmente no implica es accesible remotamente;
• una señal confirma una parte del recorrido, no todas las capas;
• el error visible en una capa no identifica automáticamente la causa inferior.

Criterio de dominio. Deberías poder dibujar dos recorridos:

1. aplicación → proceso → interfaz del SO → kernel → filesystem/dispositivo para una lectura;
2. cliente → socket → kernel → socket en escucha → proceso servidor → aplicación para una petición local.

En cada recorrido debes señalar al menos tres estados observables, explicar qué confirma cada uno y nombrar una conclusión que todavía no permite obtener. También deberías corregir con precisión las frases «Linux es la terminal», «un servicio es un proceso» y «si funciona en localhost, funciona desde fuera».

13. Prácticas relacionadas#

Las dos actividades relacionadas ya están publicadas en una ruta separada:

• SYS-R-101;
• SYS-L-101.

La página práctica contiene sus enunciados, materiales, evidencia y criterios. El laboratorio se ejecuta en un contenedor desechable fuera del checkout del portfolio y no incluye una solución oficial.

14. Fuentes#

Las fuentes siguientes respaldan el modelo y las demostraciones. Se citan por el alcance exacto utilizado, no como una lista general de lecturas.

• ACM/IEEE-CS/AAAI CS2023 — Systems Fundamentals, versión Gamma

  SF-A y SF-B, páginas 2–3: construcción por capas con interfaces, interacción aplicación-SO, propagación de errores y descripción de sistemas mediante estado y transiciones.

• ACM/IEEE-CS/AAAI CS2023 — informe curricular, versión Gamma

  Secciones OS-Purpose y OS-Principles: mediación entre hardware y aplicaciones, abstracciones, procesos, recursos, llamadas al sistema y separación usuario/kernel.

• Linux kernel documentation — The /proc Filesystem

  Capítulo 1 y sección 1.1: procfs como interfaz a estructuras internas y directorios por PID con estado, ejecutable, descriptores y memoria del proceso.

• systemd — Repository Architecture

  Service Manager: entrada mediante unidades y configuración, creación y seguimiento de procesos y aplicación de límites antes de ejecutar el programa configurado.

• curl — manual oficial

  Opción -v/--verbose: información de la operación, prefijos de cabeceras enviadas y recibidas y advertencia sobre credenciales o datos sensibles en la traza.