Linux Operating System

Linux Operating System

Resumen

Esta guía de estudio independiente explica cómo se organiza un sistema Linux desde el kernel hasta los servicios de systemd.

No es material oficial ni está afiliada a la Linux Foundation.

El recorrido conecta tres ideas: el kernel controla los recursos, el espacio de usuario ejecuta programas y el sistema de archivos ofrece una jerarquía predecible. Sobre esa base se explican el arranque, las unidades de systemd y las interfaces virtuales del kernel.

Objetivos de aprendizaje

• Distinguir kernel, shell y programas de usuario.
• Identificar los directorios del FHS y el dato que alberga cada uno.
• Describir el arranque desde el firmware hasta systemd como PID 1.
• Reconocer unidades systemd y diferenciar start de enable.
• Explicar el papel de /proc, /sys y /dev.
• Explicar qué aporta el kernel de Linux, qué aporta el proyecto GNU y qué fija POSIX.
• Interpretar systemd-analyze y los filtros de journalctl para acotar fallos de arranque.
• Distinguir los runlevels heredados de SysVinit de los targets de systemd.

Prerrequisitos y conexiones

No se requiere experiencia previa, aunque ayuda haber usado una terminal. Este tema es la base de Command Line, donde se practican navegación, permisos y procesos. También se relaciona con System Administration.

Kernel, espacio de usuario y shell

El kernel es el núcleo del sistema operativo. Se ejecuta con privilegios elevados, planifica la CPU, administra la memoria, arbitra el acceso a dispositivos y expone llamadas al sistema. Los programas normales, incluidos el shell y los servidores, se ejecutan en espacio de usuario y solicitan servicios al kernel mediante esas llamadas. Esta separación impide que un proceso escriba en la memoria del kernel o controle el hardware sin una interfaz definida.

Linux es un kernel monolítico con módulos cargables. Un controlador puede compilarse dentro del kernel o cargarse con modprobe; lsmod muestra los módulos activos y modinfo describe uno concreto. El shell no forma parte del kernel: Bash lee una línea, expande variables y globos, y ejecuta el programa resultante. Por eso uname -r informa de la versión del kernel mientras que echo $SHELL indica la ruta del shell configurado.

uname -r                  # versión del kernel en ejecución
cat /etc/os-release       # identidad de la distribución
echo "$SHELL"             # shell configurado para el usuario
lsmod                     # módulos del kernel cargados

Una distribución empaqueta el kernel con bibliotecas, utilidades y un gestor de paquetes: Debian y Ubuntu usan apt/dpkg; Fedora y RHEL, dnf/rpm; Arch Linux, pacman. Por eso los comandos de instalación no son portables sin adaptación.

Llamadas al sistema, bibliotecas y trazas

Una petición al hardware no la realiza el programa: este invoca una función de la biblioteca C, como printf, que termina emitiendo la llamada al sistema correspondiente, por ejemplo write; el kernel comprueba credenciales, descriptor de archivo y permisos antes de conceder el acceso. Cuando un programa recibe «permiso denegado», la decisión no proviene de la aplicación sino de esa comprobación que ocurre dentro del kernel.

La traza de llamadas se observa con strace: la opción -c resume cuántas veces se invoca cada syscall y cuánto tiempo consume, mientras que -p PID se conecta a un proceso en marcha. En la mayoría de las distribuciones hace falta privilegio de root o la capacidad CAP_SYS_PTRACE para adjuntarse a procesos ajenos, y por eso el mismo comando devuelve un error de permiso cuando se ejecuta como usuario normal.

strace -c ls /tmp 2>&1 | tail -n 15
strace -e trace=openat cat /etc/hostname

La siguiente tabla resume en qué punto termina la responsabilidad de cada componente y cómo comprobarlo:

Componente	Responsabilidad	Comprobación
Kernel	Planificación de CPU, memoria, dispositivos y llamadas al sistema	uname -r, lsmod, cat /proc/meminfo
Shell	Expandir la línea, resolver rutas y lanzar el programa resultante	type cd, set -x
PID 1 (systemd)	Activar unidades en orden y mantener los servicios en ejecución	systemctl list-units --failed
Distribución	Empaquetar kernel, bibliotecas, políticas y valores por defecto	cat /etc/os-release

GNU, POSIX y la identidad real del sistema

El nombre Linux designa, en rigor, solo el kernel; la mayor parte de lo que se ejecuta a diario procede del proyecto GNU y de bibliotecas del sistema, por eso ls --version anuncia GNU Coreutils y no una versión de Linux. La distribución decide qué versiones combina, con qué frecuencia las actualiza y qué valores por defecto instala, de modo que la misma utilidad puede comportarse distinto en dos equipos actualizados en momentos diferentes.

POSIX fija un contrato de interoperabilidad: mismas llamadas al sistema, mismas utilidades y un lenguaje de script comunes entre sistemas certificados. En la práctica la convergencia es alta, pero las extensiones de Bash quedan fuera del estándar: [[ ... ]], los arrays y el rango {1..10} existen en Bash y en shells compatibles, no en un intérprete estrictamente POSIX. Un script con #!/bin/bash que recibe argumentos o hace sustituciones de ese tipo fallará si alguien lo ejecuta con sh, que en Debian y Ubuntu apunta a dash.

Antes de poner en marcha un script desconocido conviene revisar su intérprete y validar su sintaxis sin ejecutarlo: bash -n respaldo.sh solo analiza el archivo y devuelve un error de línea si detecta algo inválido, mientras que head -n 1 respaldo.sh muestra la directiva #! que decidirá qué intérprete se carga.

Jerarquía del sistema de archivos (FHS)

El Filesystem Hierarchy Standard define una estructura común para que scripts y administradores encuentren los archivos en lugares previsibles. La raíz / contiene el árbol completo. /etc alberga configuración estática, como /etc/hosts o /etc/ssh/sshd_config. /var contiene datos variables: registros en /var/log, colas y cachés de servicios. /home reúne los directorios personales y /root es el del usuario root.

/usr contiene la mayor parte del software y datos de solo lectura, con subdirectorios como /usr/bin, /usr/lib y /usr/share. En sistemas con usrmerge, /bin, /sbin y /lib son enlaces simbólicos hacia sus equivalentes en /usr, de modo que las rutas antiguas siguen funcionando. /tmp se usa para archivos temporales y /run para estado volátil; /srv alberga datos servidos por el sistema.

ls -ld /etc /var /home /usr /tmp
findmnt /                      # dispositivo y opciones del sistema raíz
df -hT                         # uso y tipo de los sistemas de archivos

/proc, /sys y /dev no son directorios ordinarios en disco. El primero expone información de procesos y parámetros del kernel; el segundo representa dispositivos y subsistemas; /dev contiene nodos como /dev/null o /dev/sda. El kernel los mantiene en memoria; su contenido cambia con el estado del sistema.

Volátiles frente a persistentes

La frontera útil no es «sistema» frente a «usuario», sino qué sobrevive a un reinicio. /run se vacía en cada arranque, por eso ahí viven los archivos PID, los sockets de los servicios y los bloqueos de paquetes; /var conserva su contenido entre reinicios, de ahí que los registros y las bases de datos residan allí. /var/tmp está pensado para temporales que deben persistir, mientras que /tmp puede limpiarse automáticamente según la distribución.

El usrmerge se comprueba con una sola orden: ls -ld /bin muestra un primer carácter l y un destino dentro de /usr cuando el sistema usa enlaces, no copias duplicadas de los binarios. Conviene verificarlo antes de seguir instrucciones antiguas que asumen que /bin y /usr/bin son árboles independientes, porque en esos sistemas son la misma colección de archivos vista por dos rutas.

Tipos de sistemas de archivos y opciones de montaje

El kernel separa la capa lógica de archivos (VFS) del controlador de cada sistema de archivos, de modo que un programa escribe sin saber si los datos viven en ext4, XFS o tmpfs. cat /proc/filesystems enumera los tipos que el kernel sabe manejar en ese momento y findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS muestra qué está montado, desde qué origen y con qué opciones.

Tipo	Rasgo principal	Dónde se ve
ext4	Registro de transacciones y disponibilidad amplia	Sistemas raíz de muchas distribuciones
XFS	Diseñado para ficheros grandes y E/S paralela	Volúmenes de datos de gran tamaño
Btrfs	Instantáneas, compresión y verificación de integridad	Copias locales y volúmenes administrados
tmpfs	Vive en memoria y desaparece al reiniciar	/run y, en algunas configuraciones, /tmp
procfs y sysfs	No almacenan datos: reflejan el estado del kernel	/proc y /sys

Las opciones de montaje limitan lo que puede hacerse dentro del recurso: noexec impide ejecutar binarios, nosuid ignora el bit de propietario y nodev evita que se interpreten nodos de dispositivo. En /etc/fstab conviven seis campos —dispositivo, punto de montaje, tipo, opciones, volcado y orden de comprobación de fsck— y mount -a procesa todas las entradas pendientes dejando intactos los sistemas que ya están montados.

cat /proc/filesystems | head
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /
grep -v '^#' /etc/fstab | grep -v '^$'

Arranque y systemd

En un equipo con UEFI, el firmware inicializa el hardware y localiza un cargador de arranque, habitualmente GRUB. El cargador carga el kernel y un initramfs con los controladores mínimos para montar el sistema raíz. Después, el kernel inicia PID 1, que en la mayoría de distribuciones actuales es systemd. systemd activa unidades según dependencias y alcanza un target, como multi-user.target o graphical.target.

Las unidades describen recursos. Una unidad .service representa un servicio; .socket activa un servicio al recibir conexiones; .timer programa ejecuciones; .mount representa un punto de montaje; .target agrupa otras unidades. Un temporizador suele acompañarse de un servicio con el mismo nombre base y puede usar OnCalendar= para la periodicidad. Los temporizadores integran la programación con el estado y los registros de systemd, aunque no sustituyen automáticamente a cron.

systemctl status sshd              # estado y último resultado
systemctl list-units --type=service --state=running
systemctl cat sshd                 # unidad y drop-ins
systemctl list-dependencies sshd   # dependencias

systemctl start inicia una unidad ahora; systemctl enable crea los enlaces para que se active en el arranque. enable --now combina ambas acciones. daemon-reload relee archivos de unidad modificados, pero no reinicia servicios. Requires=, Wants= y After= expresan dependencia fuerte, dependencia débil y orden de arranque; no son equivalentes.

Runlevels frente a targets

Antes de systemd, SysVinit describía el estado del sistema con runlevels del 0 al 6 y cada distribución fijaba uno en su archivo de configuración de arranque. systemd sustituye ese número por targets, que son unidades que agrupan otras, y conserva la correspondencia clásica para que los hábitos antiguos sigan traduciéndose sin sorpresas.

Runlevel	Target equivalente	Estado del sistema
0	poweroff.target	Apagado
1	rescue.target	Consola mínima de reparación
2, 3, 4	multi-user.target	Consola con red y sin sesión gráfica
5	graphical.target	Sesión gráfica activa
6	reboot.target	Reinicio

Debian y Ubuntu heredaron el nivel 2 como predeterminado y RHEL y Fedora el nivel 3; el target de systemd equivalente es multi-user.target en ambos casos. El predeterminado actual es un enlace simbólico sobre /etc/systemd/system/default.target: systemctl get-default lo lee y systemctl set-default graphical.target lo reorienta, sin editar archivos a mano.

Medir el arranque

El tiempo de arranque se mide sin instalar nada más: systemd-analyze informa del total hasta alcanzar el target, systemd-analyze blame ordena las unidades por su tiempo de activación y systemd-analyze critical-chain describe la secuencia que retrasa el objetivo final. Ninguna de esas órdenes modifica el sistema, así que es seguro ejecutarlas en un servidor en producción.

Un valor alto no implica un fallo: a menudo refleja una espera de dirección IP, de un disco de red o de un servicio externo que nunca responde. La lectura correcta es seguir la cadena crítica hasta encontrar la unidad que bloquea a las demás y revisar su archivo con systemctl cat, en lugar de perseguir el primer número grande de la lista.

systemd-analyze
systemd-analyze blame | head -n 10
systemd-analyze critical-chain multi-user.target

Diagnóstico de estado y fallos de arranque

Cuando un servicio falla, el punto de partida es systemctl status, que muestra el código de salida y las últimas líneas del registro. journalctl -u nombre.service filtra el diario por unidad y journalctl -b se limita al arranque actual. systemctl get-default indica el target predeterminado; systemctl isolate rescue.target cambia a un modo mínimo sin reiniciar, útil para reparar configuraciones. Si el sistema no llega a la interfaz gráfica, revisa el target, las unidades requeridas y el montaje de /etc/fstab.

systemctl get-default
journalctl -b -p err            # errores del arranque actual
systemctl --failed              # unidades que fallaron
cat /proc/cmdline               # parámetros de arranque del kernel

El diario admite más filtros que los habituales: journalctl -f sigue la salida en tiempo real como hace tail -f, journalctl --since "2 hours ago" acota por fecha y journalctl -k muestra solo los mensajes del kernel, que es lo que dmesg recoge del búfer anular. Tras corregir la causa de un fallo, systemctl reset-failed nombre.service limpia el marcador para que systemctl --failed deje de anunciar la unidad.

journalctl -f -u sshd
journalctl -k -p warning --no-pager | tail -n 20
journalctl --since "2 hours ago" | tail -n 30
systemctl reset-failed sshd.service

Un error frecuente es habilitar un servicio sin comprobar sus dependencias o asumir que start lo hará persistente tras reiniciar. Otro es interpretar un failed como un problema del binario cuando la causa puede ser un puerto ocupado, un permiso denegado o una unidad requerida que no se inició.

Ejemplos prácticos

Supón que un servidor arranca, pero el servicio de copias no se ejecuta tras un reinicio. El técnico comprueba si la unidad está habilitada y si su temporizador está activo; después revisa el resultado de la última ejecución y el diario.

systemctl is-enabled backup.timer
systemctl list-timers backup.timer
systemctl status backup.service --no-pager
journalctl -u backup.service -n 30 --no-pager

Si is-enabled devuelve disabled, la unidad no se activa en el arranque. Si el temporizador está activo pero el servicio falla, el problema está en el comando, el usuario de ejecución o una ruta inexistente. Si funciona manualmente pero no tras reiniciar, revisa WantedBy= y el target predeterminado.

Un segundo escenario: tras una actualización, el equipo ya no presenta un recurso de datos y hay que determinar si el fallo pertenece al arranque, al dispositivo o a la configuración. La secuencia va de lo observable a lo declarativo, para no editar /etc/fstab a ciegas.

findmnt /var/datos
systemctl --failed
systemctl status var-datos.mount --no-pager
blkid /dev/sdb1

Si findmnt /var/datos no devuelve nada, el recurso no está montado en el arranque actual; la unidad var-datos.mount —creada por systemd a partir de /etc/fstab— indica si se intentó el montaje y con qué error, y blkid confirma si el identificador declarado sigue coincidiendo con el dispositivo. Cuando el equipo debe seguir funcionando aunque el recurso esté ausente, la opción nofail en la línea de /etc/fstab evita que el arranque se detenga esperándolo.

Errores frecuentes

• Confundir el shell con el kernel: el shell no planifica procesos ni accede al hardware.
• Guardar configuración cambiante en /etc o registros en /usr.
• Creer que systemctl start habilita el servicio para el próximo arranque.
• Añadir After= pensando que crea una dependencia de activación; solo ordena.
• Editar una unidad sin ejecutar systemctl daemon-reload.
• Tratar /proc o /sys como archivos persistentes.
• Esperar que daemon-reload reinicie las unidades modificadas: solo vuelve a leer sus archivos.
• Leer systemctl is-enabled como confirmación de que el servicio está en ejecución.
• Reiniciar el equipo sin revisar antes journalctl -b -p err, que acota los errores al arranque actual.
• Suponer que un runlevel de SysVinit sigue gobernando el estado del sistema.
• Colocar datos que deben sobrevivir a un reinicio en /tmp o en /run.

Puntos clave para el examen

Relaciona cada componente con su función: kernel con recursos y llamadas al sistema; shell con interpretación de comandos; systemd con unidades y servicios; FHS con ubicación predecible. Distingue /etc de /var y /usr de /home. Recuerda la secuencia firmware, cargador, kernel, initramfs y PID 1. Diferencia start de enable y Requires de After. /proc, /sys y /dev son interfaces virtuales.

Añade a esa base el vocabulario de la ampliación: Linux es el kernel y GNU aporta las utilidades; POSIX fija las interfaces comunes mientras que [[ ]] y los arrays son extensiones de Bash. /run se vacía en cada arranque y /var persiste, noexec, nosuid y nodev restringen lo que puede hacerse dentro de un recurso montado, y los targets sustituyen a los runlevels del 0 al 6. En diagnóstico, systemd-analyze mide el arranque, journalctl -k acota los mensajes del kernel y systemctl reset-failed limpia el marcador de fallo cuando la causa ya está corregida.

Recursos externos

• Linux Kernel Documentation: https://docs.kernel.org/admin-guide/README.html
• Interfaces de /proc: https://docs.kernel.org/filesystems/proc.html
• Filesystem Hierarchy Standard 3.0: https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html
• Bash Reference Manual: https://www.gnu.org/software/bash/manual/bash.html
• systemd: https://www.freedesktop.org/software/systemd/man/latest/systemd.html
• systemd.unit(5): https://man7.org/linux/man-pages/man5/systemd.unit.5.html
• fstab(5): https://man7.org/linux/man-pages/man5/fstab.5.html
• mount(8): https://man7.org/linux/man-pages/man8/mount.8.html
• systemd.special: https://www.freedesktop.org/software/systemd/man/latest/systemd.special.html

Autoevaluación

1. ¿Qué componente planifica la CPU y gestiona la memoria?
   El kernel; el shell solo interpreta comandos.

2. ¿Dónde se ubican los archivos de configuración estáticos?
   En /etc. /var se reserva para datos variables y /usr para software de solo lectura.

3. ¿Qué hace systemctl enable backup.timer?
   Crea los enlaces para que se active en el arranque; no la inicia. Para eso se usa start o enable --now.

4. ¿Cuál es la diferencia entre Wants= y Requires=?
   Wants= es débil: si la unidad deseada no arranca, la principal puede seguir. Requires= es fuerte y puede detener la dependiente.

5. ¿Por qué /proc/cmdline no ocupa espacio como un archivo normal?
   Porque /proc es un sistema de archivos virtual generado por el kernel; refleja el estado actual, no un archivo persistente.

6. ¿Qué diferencia hay entre systemctl is-enabled y systemctl is-active?
   El primero informa de la configuración de arranque de la unidad y el segundo responde si está en ejecución ahora mismo; ambos valores son independientes.

7. ¿Qué papel juega el initramfs antes de que aparezca el prompt?
   Es la imagen mínima que el kernel carga primero y que contiene los controladores y guiones necesarios para localizar y montar la partición real del sistema.

8. ¿Qué informa systemd-analyze blame?
   El tiempo que ha tardado cada unidad en activarse, ordenado de mayor a menor, para localizar los puntos lentos del arranque.

9. ¿Por qué mount -a no vuelve a montar los sistemas ya activos?
   Porque comprueba el punto de montaje antes de actuar y solo procesa las entradas pendientes de /etc/fstab.

10. ¿Qué aporta POSIX al sistema y qué no?
    Fija las interfaces comunes de llamadas, utilidades y script; no cubre extensiones como [[ ]], los arrays o el rango {1..10}, que dependen de Bash.