Ya sabes qué es un sistema operativo, de dónde viene y de qué tipos los hay. Toca ahora abrir la caja y ver qué hace exactamente. Esta lección es el mapa del resto del curso: cada gran función que veas aquí corresponde a uno o varios módulos posteriores, y la vas a ver aplicada a una situación concreta de Meteora. Pero el objetivo no es que te quedes con una lista de siete funciones sueltas, porque en la realidad nunca actúan por separado: atender una sola petición HTTP a meteo-api moviliza a todas ellas en cuestión de milisegundos. Por eso cerraremos siguiendo el ciclo de vida completo de una petición, de principio a fin, para ver cómo cooperan.

1. Gestión de procesos y del procesador
2. Gestión de memoria
3. Gestión del almacenamiento y de archivos
4. Gestión de dispositivos y de entrada/salida
5. Gestión de la red
6. Protección y seguridad
7. Interfaz de usuario: shell y entorno gráfico
8. Todas a la vez: ciclo de vida de una petición a meteo-api

Qué hace. Crear procesos, destruirlos, suspenderlos, reanudarlos, mantener información de cada uno y decidir cuál de ellos ocupa la CPU en cada instante. El sistema mantiene por cada proceso una estructura de control (en Linux, task_struct) con su identificador, su estado, sus registros guardados, su tabla de ficheros abiertos, su usuario propietario y sus estadísticas de consumo.

Por qué es difícil. Porque meteo-01 tiene 4 núcleos y, en un momento cualquiera, 300 procesos. Hay 300 candidatos para 4 puestos, y la decisión hay que tomarla miles de veces por segundo, en microsegundos, sin conocer el futuro y sin favorecer sistemáticamente a nadie.

En Meteora. Cuando agregador arranca su cálculo de las 02:30, consume un núcleo entero durante 20 segundos. Si el sistema no interviniera, meteo-api quedaría sin CPU durante ese tiempo y todos los clientes verían tiempos de espera. Lo que ocurre en realidad es que el planificador apropia a agregador cada pocos milisegundos y da paso a meteo-api en cuanto llega una petición.

Interpretación columna a columna:

• NI es el valor nice: la cortesía del proceso, de −20 (máxima prioridad) a +19 (mínima). agregador tiene 10, lo que significa que se ha arrancado deliberadamente con baja prioridad para que no moleste al servicio.
• PRI es la prioridad efectiva calculada por el núcleo.
• STAT es el estado: S significa sleeping (bloqueado esperando algo, típicamente E/S), R running o listo para ejecutarse, y la l de Sl indica que el proceso tiene varios hilos.
• ETIMES son los segundos transcurridos desde que arrancó. ingestor y meteo-api llevan 864.320 segundos (10 días); agregador acaba de empezar.

Fíjate en el patrón: los dos servicios permanentes están dormidos casi todo el tiempo, esperando red. agregador está ejecutándose. Este perfil (S para servicios, R para trabajos de cálculo) es lo primero que se mira al diagnosticar un servidor.

Dónde se desarrolla. Gestión de Procesos y Planificación de la CPU. La concurrencia entre procesos e hilos ocupa el módulo 3 completo.

Qué hace. Decidir qué hay en la RAM y dónde, asignar y liberar memoria a los procesos, dar a cada uno un espacio de direcciones privado, y hacer que quepa más de lo que físicamente hay.

Por qué es difícil. La RAM es un recurso escaso, indivisible en su forma física y compartido por todos. Tres exigencias entran en conflicto: que los procesos no se pisen, que se aproveche cada byte, y que todo esto no cueste tiempo.

En Meteora. meteo-api tiene un consumo curioso que conviene entender:

• VSZ (Virtual Size) son los KB de espacio de direcciones virtual: 1.284.560 KB, unos 1,2 GB.
• RSS (Resident Set Size) son los KB que realmente ocupan RAM física: 47.320 KB, unos 46 MB.

La diferencia es de 27 veces, y no es un error. meteo-api ha reservado espacio de direcciones para muchas cosas (bibliotecas compartidas, regiones mapeadas, pilas de sus hilos) que no está usando ahora mismo, y el sistema no le ha dado memoria física por ellas. El sistema entrega memoria física solo cuando el proceso toca de verdad esas direcciones. Este mecanismo, la asignación perezosa, es la razón de que en meteo-01 con 8 GB de RAM puedan convivir procesos cuya suma de VSZ supera los 20 GB.

Un error de principiante muy caro: alarmarse por el VSZ. La columna que importa para saber si te quedas sin memoria es RSS, y ni siquiera esa del todo, porque parte de la memoria residente son bibliotecas compartidas contabilizadas en varios procesos a la vez.

Dónde se desarrolla. Gestión de Memoria y Memoria Virtual y Paginación.

Qué hace. Convertir un dispositivo que solo entiende de bloques numerados en un árbol de directorios con ficheros que tienen nombre, tamaño, fechas, propietario y permisos. Además: asignar espacio, gestionar el espacio libre, mantener la coherencia ante un corte de luz y cachear en RAM lo leído recientemente.

Por qué es difícil. Porque el disco no sabe nada de ficheros. Un SSD ofrece una secuencia de bloques de 4 KB numerados del 0 al que sea. Todo lo demás —nombres, jerarquía, permisos, la propia noción de "fichero"— es una estructura de datos que el sistema operativo construye encima y debe mantener coherente aunque la máquina se apague en el peor momento posible.

En Meteora. Los ficheros diarios de lecturas viven en /var/lib/meteora/lecturas/:

Qué nos dice esto:

• ls -lh muestra el listado largo con tamaños legibles (-h). El fichero de hoy tiene 12 MB porque el día aún no ha terminado: crece a razón de unos 24 bytes por lectura recibida.
• Los permisos -rw-r----- significan: el propietario (meteora) lee y escribe, el grupo (meteora) solo lee, y el resto del mundo no tiene ningún acceso. Cualquier otro usuario del sistema no puede ni siquiera ver el contenido.
• df -h informa del sistema de archivos que contiene esa ruta: el dispositivo /dev/sda2, montado en /var, con un 63 % de ocupación.

Ese 63 % es un dato operativo importante: a 17 MB diarios, quedan 72 GB libres, es decir, unos 11 años de datos. Pero si mañana Meteora duplicase el número de estaciones y guardara además datos derivados, ese margen se reduciría rápidamente. Vigilar el crecimiento es parte del trabajo, y por eso lo veremos en Monitorización y Diagnóstico de Rendimiento.

Dónde se desarrolla. Módulo 4 completo, empezando por Sistemas de Archivos y Gestión de Almacenamiento.

Qué hace. Ofrecer una interfaz uniforme para hardware muy diverso, mediante controladores (drivers) específicos; planificar las operaciones de E/S; atender las interrupciones que generan los dispositivos; y amortiguar la diferencia de velocidad entre la CPU y todo lo demás con búferes y cachés.

Por qué es difícil. Por la desproporción de velocidades que ya viste: mientras el disco atiende una petición de 50 µs, la CPU podría ejecutar unas 150.000 instrucciones. Si la CPU esperase activamente, se desperdiciaría. La solución —bloquear el proceso, ejecutar otro, y despertar al primero mediante una interrupción cuando el dato llegue— es el corazón del diseño de un sistema operativo.

En Meteora. ingestor recibe unas 500 lecturas por minuto de la red y las escribe a disco. Si cada lectura provocase una escritura física, serían 500 operaciones de disco por minuto para escribir 12 KB en total: absurdo. El sistema agrupa esas escrituras en la caché de páginas y las vuelca al disco en bloques mayores.

Explicación de cada línea:

• MemTotal: 8 GB de RAM en la máquina.
• MemFree: solo 400 MB libres. Esto no es un problema, y confundirlo con uno es el error más frecuente de todos.
• Cached: 5,2 GB dedicados a caché de páginas, es decir, copias en RAM de datos de ficheros. Esta memoria es recuperable al instante: si un proceso la necesita, el núcleo la libera. Los ficheros de lecturas de los últimos días están aquí, y por eso agregador los relee tan rápido.
• Dirty: 8 MB escritos por procesos que aún no han llegado al disco. Son los datos que ingestor ha entregado y el núcleo todavía no ha volcado.
• Writeback: 0 KB en tránsito hacia el disco en este instante.

Ese valor Dirty es también un riesgo: si meteo-01 perdiera la corriente ahora mismo, esos 8 MB de lecturas se perderían. Cuando la pérdida es inaceptable, el programa debe forzar el volcado con fsync(), a costa de rendimiento. Es un compromiso clásico que retomaremos en Asignación de Espacio, Journaling e Integridad.

Dónde se desarrolla. Gestión de Dispositivos y Controladores, Interrupciones y Operaciones de E/S.

Qué hace. Implementar las pilas de protocolos (TCP/IP), gestionar las interfaces, mantener las tablas de rutas, multiplexar las conexiones entre procesos y ofrecer la abstracción de socket, que permite tratar una conexión remota casi como un fichero.

Por qué es una función del sistema operativo y no de la aplicación. Porque la tarjeta de red es un recurso compartido: meteo-api, ingestor y sshd están todos escuchando a la vez, y alguien tiene que decidir a quién corresponde cada paquete que llega. Ese reparto se hace por puerto, y solo el núcleo puede arbitrarlo.

En Meteora.

Análisis línea a línea:

• ss -tlnp lista sockets TCP (-t) en escucha (-l), sin resolver nombres (-n, más rápido y sin sorpresas de DNS) y mostrando el proceso dueño (-p).
• meteo-api escucha en 0.0.0.0:8080: la dirección 0.0.0.0 significa todas las interfaces, es decir, acepta conexiones desde fuera de la máquina. Es lo correcto para un servicio público.
• ingestor escucha en 127.0.0.1:9310: solo en la interfaz de bucle local, así que únicamente procesos de la propia máquina pueden conectarse. Es una decisión de seguridad deliberada. Si tuviera que aceptar conexiones de las estaciones desde fuera, este sería un puerto expuesto y habría que protegerlo.
• Send-Q en estado LISTEN indica el tamaño máximo de la cola de conexiones pendientes: 512 para meteo-api, 128 para ingestor. Si llegan más conexiones simultáneas de las que caben en esa cola, se rechazan.
• fd=6 y fd=4 son los descriptores de fichero de esos sockets dentro de cada proceso: la prueba directa de que "todo es un fichero" alcanza también a la red.

Qué hace. Autenticar (¿quién eres?), autorizar (¿puedes hacer esto?), aislar (que un proceso no toque lo que es de otro) y auditar (dejar constancia de lo ocurrido).

Conviene separar dos conceptos que suelen mezclarse:

• Protección es el mecanismo interno que impide que los procesos interfieran entre sí, incluso sin mala intención. Que un fallo en agregador no corrompa la memoria de meteo-api es protección.
• Seguridad es la defensa frente a un adversario que actúa con intención. Que un atacante que compromete meteo-api no pueda leer /etc/shadow es seguridad.

En Meteora. El modelo de permisos aplica el mínimo privilegio en cada capa:

Lo interesante está en los detalles:

• El fichero de configuración pertenece a root pero su grupo es meteora. Los servicios pueden leerlo (permiso r de grupo) pero no modificarlo, porque el permiso de escritura es solo del propietario root. Si un atacante compromete meteo-api, no puede alterar la configuración para, por ejemplo, cambiar la ruta de los datos.
• El registro sí pertenece a meteora, porque el servicio necesita escribir en él.
• uid=990: los identificadores por debajo de 1000 se reservan por convención a cuentas de sistema, que no corresponden a personas y no pueden iniciar sesión interactiva.

Dónde se desarrolla. Módulo 5 completo, más Seguridad y Permisos de Archivos.

Qué hace. Ofrecer una vía para que las personas den órdenes al sistema. Puede ser una línea de comandos (bash), un entorno gráfico (GNOME) o una API de administración remota.

Matiz esencial, ya visto en la primera lección. La interfaz no forma parte del núcleo. bash es un programa de usuario que lee lo que escribes, lo interpreta y pide al núcleo que ejecute programas mediante llamadas al sistema. Su privilegio es exactamente el mismo que el de cualquier otro programa del usuario.

En meteo-01 no hay entorno gráfico. Toda la administración se hace por SSH y con bash, y esto es deliberado: menos software instalado significa menos memoria consumida, menos actualizaciones que aplicar y menos vulnerabilidades potenciales.

Dónde se desarrolla. La Línea de Comandos como Interfaz del Sistema.

Aquí es donde las siete funciones dejan de ser una lista y se convierten en un sistema. Sigamos una petición real:

Recorramos el diagrama poniendo nombre a la función responsable de cada paso:

1. Llegada por red (gestión de la red + gestión de dispositivos). La tarjeta recibe los paquetes y lanza una interrupción. El núcleo reensambla el flujo TCP, mira el puerto de destino (8080) y localiza el socket de meteo-api.
2. Despertar y planificar (gestión de procesos). meteo-api estaba bloqueado en read(), en estado S. El núcleo lo pasa a "listo" y el planificador decide cuándo le da CPU. Como es un proceso orientado a E/S, tiene ventaja frente a agregador. El cambio de contexto cuesta del orden de 1 a 5 microsegundos.
3. Lectura de la petición (llamadas al sistema, tema de la próxima lección). meteo-api ejecuta read(), cruza la frontera a modo núcleo, recoge sus bytes y vuelve.
4. Apertura del fichero (gestión de archivos + seguridad). El núcleo traduce /var/lib/meteora/lecturas/2026-08-31.dat recorriendo el árbol de directorios, y en cada paso comprueba que el usuario meteora tiene permiso. Si no lo tuviera, devolvería EACCES sin llegar a tocar el disco.
5. Obtención de los datos (gestión de memoria + gestión de dispositivos). Aquí hay dos caminos, y la diferencia entre ambos es de tres órdenes de magnitud:
   • Si los bloques están en la caché de páginas, la copia se hace desde RAM: unos 80 ns por bloque.
   • Si no lo están, el núcleo pide al disco los bloques, bloquea a meteo-api y aprovecha para ejecutar otro proceso. Cuando el disco termina, lanza una interrupción, el núcleo copia los datos a la caché de páginas y despierta al proceso: unos 50 µs por bloque en un SSD.
6. Cálculo (gestión de procesos). meteo-api filtra las lecturas de la estación 118, agrupa por hora y calcula medias. Es la única parte del recorrido que hace trabajo específico de Meteora; todo lo demás lo aporta el sistema.
7. Respuesta (gestión de la red). write() al socket. El núcleo copia los datos a su búfer de transmisión, los fragmenta según el tamaño máximo de segmento y ordena a la tarjeta que los envíe. Fíjate en un detalle importante: write() devuelve el control antes de que los datos hayan llegado al cliente. La aplicación no espera a la red.
8. Registro (gestión de archivos). Otra escritura, esta vez a /var/log/meteora/meteo-api.log, que también pasa por la caché y se volcará al disco más tarde.

La conclusión que importa: de todo este recorrido, el código de Meteora solo aporta el paso 6. Los siete restantes son sistema operativo. Y ninguna de sus funciones podría cumplir su parte sin las demás: la planificación depende de saber quién está bloqueado en E/S, la E/S depende de la gestión de memoria para la caché, la caché depende de que la seguridad ya haya autorizado el acceso. Son un sistema, no un catálogo.

• Memorizar las funciones como una lista. Lo que se pregunta en la práctica no es "enumera las funciones del SO", sino "por qué esta petición tarda 400 ms". Practica el recorrido del ciclo de vida completo: es el ejercicio que de verdad enseña.
• Alarmarse porque MemFree es bajo. La RAM libre no utilizada es RAM desperdiciada. Un sistema sano usa casi toda la memoria, la mayor parte en caché de páginas, que se libera al instante cuando hace falta. La métrica útil es MemAvailable, no MemFree.
• Confundir VSZ con consumo real. El espacio de direcciones virtual puede ser 30 veces mayor que la memoria física ocupada. Mira RSS, y para un análisis fino, /proc/<pid>/smaps_rollup.
• Creer que la aplicación "escribe en disco". La aplicación entrega bytes al núcleo. Cuándo llegan al disco lo decide el sistema, salvo que se fuerce con fsync(). Esta diferencia explica muchísimas pérdidas de datos tras un corte de luz.
• Pensar que write() a un socket significa que el cliente recibió los datos. Solo significa que el núcleo los aceptó en su búfer de salida.
• Consejo: acostúmbrate a mirar las cuatro cosas básicas al diagnosticar cualquier problema, en este orden: estado de los procesos (ps, top), memoria (free -h), disco (df -h, iostat) y red (ss). Casi todos los incidentes se localizan ahí en menos de un minuto.

Para cada síntoma observado en meteo-01, indica qué función del sistema operativo está implicada principalmente, qué comando usarías para confirmarlo y en qué módulo del curso se estudia:

1. Las respuestas de meteo-api tardan 3 segundos en lugar de 50 ms, y top muestra un núcleo al 100 %.
2. ingestor falla con "No space left on device".
3. Un cliente no puede conectarse al puerto 8080 desde fuera, pero desde la propia máquina sí.
4. meteo-api no puede leer /etc/meteora/meteora.conf tras un cambio de configuración.

meteo-api recibe 200 peticiones por segundo. Cada petición requiere leer 40 bloques de 4 KB del fichero del día. Calcula el tiempo total de E/S por segundo en dos escenarios: (a) todo desde disco SSD, a 50 µs por bloque; (b) todo desde caché de páginas, a 80 ns por bloque. ¿Puede meteo-01 sostener esa carga en el escenario (a)? Razona qué función del SO hace que en la práctica el escenario real se parezca al (b).

Recorre el ciclo de vida de una petición e indica, para cada uno de los ocho pasos, qué ocurriría si esa función del sistema operativo no existiera. El objetivo es que justifiques la necesidad de cada una, no que describas su funcionamiento.

Solución 1

1. Respuestas lentas con un núcleo al 100 %

• Función: gestión de procesos y del procesador. Hay contención de CPU: algún proceso (muy probablemente agregador) está monopolizando un núcleo y meteo-api no recibe CPU suficiente.
• Comando: top ordenado por CPU, o ps -eo pid,ni,pri,stat,%cpu,comm --sort=-%cpu. Interesa mirar el valor NI: si agregador no está arrancado con nice, esa es la causa y la solución inmediata es renice.
• Módulo: Planificación de la CPU.

2. "No space left on device"

• Función: gestión del almacenamiento y de archivos.
• Comando: df -h /var/lib/meteora para ver el espacio, y también df -i. Este segundo es importante: el error idéntico aparece cuando se agotan los inodos aunque quede espacio libre, algo típico cuando hay millones de ficheros pequeños. Es un diagnóstico que se pasa por alto constantemente.
• Módulo: Sistemas de Archivos y Asignación de Espacio, Journaling e Integridad.

3. Conecta desde dentro pero no desde fuera

• Función: gestión de la red (y posiblemente seguridad, si hay cortafuegos).
• Comando: ss -tlnp | grep 8080. Si la dirección local es 127.0.0.1:8080 en lugar de 0.0.0.0:8080, el servicio solo escucha en el bucle local y ese es el problema; se corrige en la configuración de la aplicación. Si ya escucha en 0.0.0.0, entonces hay que revisar el cortafuegos con iptables -L -n o nft list ruleset.
• Módulo: Amenazas Comunes y Endurecimiento del Sistema para la parte de cortafuegos.

4. No puede leer la configuración

• Función: protección y seguridad.
• Comando: ls -l /etc/meteora/meteora.conf y ls -ld /etc/meteora. Hay que mirar los dos: aunque el fichero tenga permisos correctos, si el directorio perdió el permiso de ejecución (x) para el grupo, no se puede atravesar y el acceso falla igualmente. Es el error más frecuente al ajustar permisos a mano.
• Módulo: Seguridad y Permisos de Archivos.

Solución 2

Bloques a leer por segundo:

(a) Desde SSD, a 50 µs por bloque:

(b) Desde caché de páginas, a 80 ns por bloque:

¿Puede sostener la carga en (a)? Estrictamente sí, porque 0,4 s de E/S por cada segundo de reloj deja margen. Pero el margen es engañoso por dos razones:

• Es un 65 % de utilización efectiva del subsistema de E/S si consideramos la latencia serializada. En teoría de colas, la latencia crece de forma no lineal al acercarse a la saturación: a partir del 70-80 % de utilización, los tiempos de respuesta se disparan. Un pico del doble de tráfico haría inviable el servicio.
• Los 0,4 s son latencia de espera, no CPU. Durante ese tiempo los procesos están bloqueados, lo que exige que haya suficientes hilos o procesos concurrentes para que el servidor no quede parado esperando.

Qué hace que el caso real se parezca a (b): la caché de páginas, que es gestión de memoria y de E/S trabajando juntas. Como el fichero del día ocupa 17 MB y meteo-01 tiene gigabytes dedicados a caché, tras las primeras lecturas el fichero completo reside en RAM y todas las peticiones posteriores se sirven desde ahí. El disco solo interviene la primera vez y al principio de cada día nuevo.

Esta es también la razón de que las pruebas de rendimiento mal hechas den resultados engañosamente buenos: si mides después de haber ejecutado la misma consulta veinte veces, estás midiendo la RAM, no el sistema completo.

Solución 3

1. Sin gestión de red: cada aplicación tendría que hablar directamente con la tarjeta e implementar TCP por su cuenta. Peor aún, no habría forma de repartir los paquetes entrantes entre meteo-api, ingestor y sshd: solo un programa podría usar la red a la vez.
2. Sin planificación de procesos: meteo-api no podría ser despertado. O bien tendría que consultar activamente el socket en un bucle (quemando CPU sin hacer nada útil) o bien el sistema ejecutaría un solo programa hasta que terminase, y las peticiones se atenderían de una en una.
3. Sin llamadas al sistema: no habría frontera entre la aplicación y el núcleo. Cualquier programa podría manipular el hardware directamente, y un fallo en meteo-api podría corromper cualquier estructura del sistema.
4. Sin gestión de archivos: meteo-api tendría que saber en qué sectores físicos están los datos del 31 de agosto y mantener esa contabilidad por su cuenta. Cambiar de disco obligaría a reescribir la aplicación. Y sin comprobación de permisos, cualquier proceso podría leer cualquier dato de la máquina.
5. Sin gestión de memoria y caché: cada lectura iría al disco, con un coste 600 veces mayor. Además, sin espacios de direcciones separados, un puntero erróneo en agregador podría sobrescribir la memoria de meteo-api, con corrupción silenciosa de datos servidos a clientes.
6. Sin apropiación en la planificación: meteo-api conservaría la CPU durante todo su cálculo y, si entrara en un bucle infinito por una petición malformada, la máquina entera quedaría inservible hasta un reinicio físico.
7. Sin búferes de red en el núcleo: la aplicación tendría que esperar a que cada byte se transmitiera físicamente antes de continuar, lo que multiplicaría por varios órdenes de magnitud el tiempo de respuesta y reduciría el rendimiento a una fracción del actual.
8. Sin sistema de archivos ni control de acceso para el registro: no habría forma fiable de dejar constancia de lo ocurrido, ni de garantizar que un atacante no pueda borrar sus huellas. Sin registros, la respuesta a incidentes es imposible; volveremos a ello en Auditoría, Registros y Respuesta a Incidentes.

Las funciones principales de un sistema operativo —procesos y CPU, memoria, almacenamiento y archivos, dispositivos y E/S, red, protección y seguridad, e interfaz de usuario— son el mapa del resto de este curso. Cada una resuelve un problema concreto: repartir el procesador, dar a cada proceso un espacio propio, convertir bloques en ficheros, amortiguar la lentitud del hardware, multiplexar la red, aislar a unos de otros y permitir que un humano dé órdenes.

Lo que has visto al seguir una petición HTTP de principio a fin es que estas funciones no operan por separado. En los pocos milisegundos que tarda meteo-api en responder, intervienen todas, se apoyan unas en otras y de las ocho etapas del recorrido, siete son sistema operativo y solo una es código de Meteora. Esa proporción explica por qué merece la pena entender lo que hay debajo.

Hasta aquí hemos mirado el sistema desde fuera: qué hace y para quién. En la siguiente lección, Arquitectura del Núcleo: Monolítico, Microkernel e Híbrido, abriremos el núcleo para ver cómo se organiza por dentro todo ese código, y descubrirás que existen formas radicalmente distintas de estructurarlo, con consecuencias directas sobre el rendimiento y la robustez de meteo-01.