Consultar el estado del sistema

1. Las preguntas y sus comandos

En el tema 8 conocimos /proc, el directorio donde el kernel publica su estado en forma de archivos de texto que se generan al leerlos, y dijimos que muchos comandos son lectores de /proc con mejor presentación. Los de este tema son exactamente eso. Ninguno modifica nada, ninguno necesita sudo —con dos excepciones que señalaremos—, y todos responden al instante.

Varios de estos datos ya pasaron por la pantalla: la primera línea de top, en el tema 32, mostraba el tiempo encendido y la carga, y las dos siguientes, la memoria. Allí quedó la promesa de volver sobre ellos. La diferencia es de propósito: top es para mirar, y estos comandos escriben una respuesta breve y terminan, de modo que se pueden filtrar, guardar en un archivo o usar en un script.

2. uname: el kernel

uname, de Unix name, informa sobre el kernel que está en ejecución. Sin opciones responde una sola palabra; con -a, todo lo que sabe.

$ uname
Linux
$ uname -r
6.8.0-87-generic
$ uname -a
Linux equipo 6.8.0-87-generic #87-Ubuntu SMP PREEMPT_DYNAMIC Tue Sep 22 18:03:36 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

En el tema 1, este mismo equipo respondía 6.8.0-45-generic. El número cambió porque las actualizaciones del tema 35 trajeron un kernel nuevo y el equipo se reinició después: uname informa el kernel que está en memoria, no el más nuevo que haya en el disco. La versión se lee así:

6.8.0-87-generic
│ │ │  │    │
│ │ │  │    └─ la variante: «generic» es la de uso general
│ │ │  └─ la revisión de Ubuntu: sube con cada actualización de seguridad
│ │ └─ el nivel de corrección: en Ubuntu queda siempre en 0
│ └─ la versión menor: una nueva cada dos o tres meses
└─ la versión mayor

Las dos primeras cifras, 6.8, son la versión del kernel de Linux tal como la publican sus desarrolladores; lo que sigue al guion es de la distribución, y cada una lo escribe a su manera. Fedora muestra algo como 6.14.4-300.fc42.x86_64, y Arch, 6.14.5-arch1-1.

La arquitectura indica para qué familia de procesadores está compilado el sistema. Es el dato que hay que conocer al descargar un programa que se ofrece en varias versiones:

Es el amd64 que formaba parte del nombre de los paquetes en el tema 35. Un programa compilado para una arquitectura no se ejecuta en otra: al intentarlo, la shell responde Exec format error.

Quien sigue el curso en WSL, una de las opciones del tema 2, verá en uname -r algo como 5.15.167.4-microsoft-standard-WSL2: no es el kernel de Ubuntu, sino uno que provee Windows para todas sus distribuciones.

3. hostnamectl: la identidad de la máquina

El nombre de la máquina es el que aparece en el indicador, después de la arroba. Se consulta con hostname, y con hostnamectl se obtiene una ficha más completa, que reúne en un solo lugar datos que de otro modo habría que pedir a tres comandos:

$ hostname
equipo
$ hostnamectl
 Static hostname: equipo
       Icon name: computer-laptop
         Chassis: laptop
      Machine ID: 3f9c41d27a8e4b6b9d0e5a17c2f48b61
         Boot ID: 7a1e0c5594d34f0e8b6fa3c1d2e9b470
Operating System: Ubuntu 24.04.3 LTS
          Kernel: Linux 6.8.0-87-generic
    Architecture: x86-64
 Hardware Vendor: Lenovo
  Hardware Model: ThinkPad T480
Firmware Version: N24ET76W (1.51 )

Es el comando para empezar cuando se entra por primera vez a una máquina desconocida: en doce líneas dice si es física o virtual, qué distribución tiene y sobre qué equipo corre. La línea Virtualization es la manera directa de saber si lo que parece un servidor es en realidad una máquina virtual.

El mismo comando cambia el nombre, y esta sí es una operación de administrador:

$ sudo hostnamectl set-hostname portatil-ana
$ hostname
portatil-ana

El cambio es inmediato y permanente, pero el indicador de la terminal abierta seguirá mostrando el nombre viejo: PS1 tomó el dato al arrancar la shell, por la razón que explicamos en el tema 34. Una terminal nueva muestra el actual. Un nombre de máquina lleva letras minúsculas, dígitos y guiones, sin espacios ni puntos. En los ejemplos seguimos con equipo.

4. uptime: tiempo encendido y carga

$ uptime
 09:41:07 up  1:12,  1 user,  load average: 0,42, 0,35, 0,30
    │        │        │                      │     │     │
    │        │        │                      │     │     └─ en los últimos 15 minutos
    │        │        │                      │     └─ en los últimos 5 minutos
    │        │        │                      └─ en el último minuto
    │        │        └─ las sesiones de usuario abiertas
    │        └─ el tiempo que lleva encendido: 1 hora y 12 minutos
    └─ la hora actual

Es la misma línea que encabeza top y la salida de w, del tema 16. El tiempo encendido cambia de forma según cuánto sea: up 12 min, up 1:12 para horas y minutos, up 37 days, 4:20 cuando pasa de un día.

El tiempo encendido responde preguntas concretas. Si un servicio falló a las tres de la madrugada y uptime -s dice que el sistema arrancó a las tres y dos minutos, la máquina se reinició, y hay que averiguar por qué. Si un equipo lleva cuatrocientos días encendido, es seguro que tiene actualizaciones del kernel instaladas y sin aplicar. En Linux, un tiempo encendido muy largo no es una medalla: es una señal de que falta un reinicio de mantenimiento.

Los tres números del final llevan coma decimal porque el sistema está en español, y entre ellos el separador también es una coma, lo que dificulta la lectura y más aún el filtrado. Con la variable del tema 34, LC_ALL=C uptime los escribe con punto. Para procesarlos conviene ir a la fuente, que usa siempre el punto:

$ cat /proc/loadavg
0.42 0.35 0.30 1/912 7480
$ cut -d' ' -f1 /proc/loadavg           # la carga del último minuto
0.42

Los tres primeros campos son la carga. El cuarto, 1/912, dice que en ese instante hay una tarea ejecutándose, de 912 que existen en total, contando los hilos; el quinto es el PID del último proceso creado.

5. Interpretar la carga media

La carga media, load average, es el promedio de procesos que, a lo largo de un período, estuvieron usando el procesador o esperando para usarlo. En Linux se cuentan además los que esperan una respuesta del disco.

Es una cantidad de procesos, no un porcentaje, y por sí sola no dice nada. Una carga de 4 significa que, en promedio, hubo cuatro procesos queriendo trabajar a la vez. Si eso es poco o mucho depende de cuántos pueden trabajar a la vez de verdad, que es la cantidad de procesadores:

$ nproc
8

Tener tres promedios en lugar de uno permite leer la tendencia, que suele importar más que el valor:

El orden desconcierta: el primer número es el más reciente. Se ve funcionando con un comando que ya conocemos del tema 24, yes, que escribe sin parar y ocupa un procesador entero. Lanzamos cuatro en segundo plano, con las herramientas del tema 33:

$ for i in 1 2 3 4; do yes > /dev/null & done
[1] 7512
[2] 7513
[3] 7514
[4] 7515
$ uptime                               # un minuto después
 09:44:20 up  1:15,  1 user,  load average: 2,91, 0,98, 0,55
$ kill %1 %2 %3 %4
$ uptime                               # otro minuto después
 09:45:31 up  1:16,  1 user,  load average: 1,24, 1,02, 0,61

La primera línea es un bucle, una construcción del curso siguiente: aquí basta con saber que repite cuatro veces el comando yes > /dev/null &. Con cuatro procesos pidiendo procesador todo el tiempo, la carga del último minuto sube hacia 4; al matarlos, cae, mientras el promedio de quince minutos apenas se enteró. Y en este equipo de ocho procesadores, una carga de 3 no se nota en absoluto.

6. free: la memoria

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       3.6Gi       1.2Gi       412Mi       3.1Gi       4.0Gi
Swap:          2.0Gi          0B       2.0Gi

Dos filas: Mem es la memoria física, la RAM, y Swap, el área de intercambio en disco, de la que nos ocupamos en la sección 8. Sin opciones, free escribe las cantidades en kibibytes, que nadie lee con comodidad; por eso se lo usa casi siempre con -h.

Las unidades terminan en i: Gi es un gibibyte, 1024 mebibytes, la unidad en que se mide la memoria desde siempre. Y el total es menor que lo que dice la caja del equipo. Este tiene 8 GB instalados, que son 8192 MiB, y free informa 7836: la diferencia la reservan el firmware, la placa de video integrada —que no tiene memoria propia y toma de la principal— y el propio kernel. No falta nada.

7. Libre no es lo mismo que disponible

Quien mira free por primera vez lee la columna free, ve que de casi 8 GiB quedan 1.2, y concluye que la máquina está al límite. Es la lectura equivocada más común de todo el sistema, y tiene una explicación que cambia la manera de mirar la memoria.

La caché de disco es la memoria que el kernel usa para conservar copias de los archivos leídos y escritos recientemente. Leer de la memoria es miles de veces más rápido que leer del disco, de modo que el kernel guarda todo lo que puede, y lo entrega de inmediato si un programa necesita esa memoria.

El razonamiento del kernel es que la memoria sin usar no sirve a nadie. Mientras ningún programa la pida, la aprovecha para acelerar el acceso a los archivos; cuando alguien la pide, descarta lo guardado —que sigue estando en el disco— y la cede. Por eso, en un sistema que lleva un rato encendido, la memoria «libre» tiende a ser poca, y eso es señal de que funciona bien.

Se lo puede ver ocurrir. Leemos un gran número de archivos, descartando su contenido, y comparamos antes y después:

$ free -m | sed -n '1p;2p'
               total        used        free      shared  buff/cache   available
Mem:            7836        3735        1210         412        3223        4101
$ cat /usr/lib/x86_64-linux-gnu/*.so* > /dev/null 2>&1
$ free -m | sed -n '2p'
Mem:            7836        3743         640         412        3801        4093

La lectura de unos seiscientos mebibytes de bibliotecas quedó guardada en la caché: buff/cache creció y free bajó en la misma medida. Lo disponible casi no cambió, porque esa caché se entrega a quien la pida. Si se repite el cat, termina en una fracción del tiempo: esta vez no tocó el disco.

Las columnas no suman el total, y eso también confunde. En las versiones actuales de free, used se calcula como total menos available, y una parte de la caché —la que no se puede descartar— queda contada en los dos lados. La cuenta que sí cierra es la de la figura: lo usado más lo disponible es el total.

Los datos salen de /proc/meminfo, que tiene medio centenar de líneas. Las que free resume son estas:

$ grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|Cached|SwapTotal|SwapFree)' /proc/meminfo
MemTotal:        8024474 kB
MemFree:          655360 kB
MemAvailable:    4191232 kB
Buffers:          145408 kB
Cached:          3512320 kB
SwapTotal:       2097148 kB
SwapFree:        2097148 kB

Para saber quién ocupa la memoria, la herramienta es la del tema 32: ps aux --sort=-%mem | head, o top ordenado con la tecla M.

8. El área de intercambio

El área de intercambio, o swap, es un espacio en el disco que el kernel usa como extensión de la memoria. Cuando la RAM no alcanza, traslada allí las partes de memoria que hace más tiempo que nadie usa, y las trae de vuelta cuando se las necesita.

Permite que el sistema siga funcionando cuando los programas piden más memoria de la que hay, a un precio alto: el disco es muchísimo más lento que la RAM. Puede ser una partición dedicada o un archivo; en Ubuntu es el /swap.img que encontramos en la raíz al recorrerla en el tema 8.

$ swapon --show
NAME      TYPE SIZE USED PRIO
/swap.img file   2G   0B   -2
$ ls -lh /swap.img
-rw------- 1 root root 2.0G sep  3 10:12 /swap.img

Los permisos rw------- de root no son un descuido: en ese archivo terminan fragmentos de la memoria de cualquier programa, contraseñas incluidas. Si swapon --show no escribe nada, el sistema no tiene intercambio, lo que es habitual en servidores en la nube y en contenedores.

Lo que hay que saber leer es la fila Swap de free, y sobre todo su evolución:

La última fila describe un mecanismo con nombre propio. Cuando la memoria y el intercambio se agotan, el kernel elige un proceso —por lo general, el que más memoria ocupa— y lo termina con la señal KILL del tema 33, sin aviso. Es el OOM killer, de out of memory. Desde afuera se ve como un programa que desaparece solo; la explicación queda anotada en el registro del kernel, que aprenderemos a leer en el tema 39.

Un sistema que intercambia sin cesar se reconoce sin mirar ningún número: el disco trabaja de continuo, y cada acción tarda segundos. No se arregla con un comando. Se arregla cerrando programas, o agregando memoria.

9. lscpu: el procesador

lscpu describe el procesador. Su salida completa tiene unas cuarenta líneas; las que interesan son las de arriba.

$ lscpu
Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          39 bits physical, 48 bits virtual
  Byte Order:             Little Endian
CPU(s):                   8
  On-line CPU(s) list:    0-7
Vendor ID:                GenuineIntel
  Model name:             Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
    CPU family:           6
    Model:                142
    Thread(s) per core:   2
    Core(s) per socket:   4
    Socket(s):            1
    Stepping:             10
    CPU max MHz:          3400.0000
    CPU min MHz:          400.0000
    Flags:                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr …
Virtualization features:
  Virtualization:         VT-x
Caches (sum of all):
  L1d:                    128 KiB (4 instances)
  L1i:                    128 KiB (4 instances)
  L2:                     1 MiB (4 instances)
  L3:                     6 MiB (1 instance)
…

Las líneas resaltadas resuelven una ambigüedad. La palabra «procesador» nombra tres cosas distintas, y lscpu las separa:

El último número es el que informa nproc, el que aparece como ocho barras en htop, y el que se usa para interpretar la carga. Conviene tener presente que no son ocho núcleos: dos hilos de un mismo núcleo comparten sus circuitos, y juntos rinden bastante menos que dos núcleos de verdad. Para el trabajo pesado y sostenido, este equipo se parece más a uno de cuatro que a uno de ocho.

Como toda salida en columnas, se filtra con lo conocido. Y nproc responde la pregunta más frecuente sin necesidad de filtrar nada:

$ lscpu | grep -E '^(Model name|CPU\(s\)|Thread|Core|Socket)'
CPU(s):                   8
$ lscpu | grep -E 'Model name|^CPU\(s\)|Thread|Core|Socket'
CPU(s):                   8
  Model name:             Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
    Thread(s) per core:   2
    Core(s) per socket:   4
    Socket(s):            1
$ nproc
8
$ grep -c '^processor' /proc/cpuinfo
8

El primer intento muestra una trampa del tema 28: el ancla ^ alcanzaba a todas las alternativas, y las líneas con sangría no empiezan con esas palabras. En el segundo, el ancla queda solo donde hace falta, para no confundir CPU(s) con On-line CPU(s).

El último comando va a la fuente: /proc/cpuinfo tiene un bloque de unas veinticinco líneas por cada procesador lógico, encabezado por la palabra processor. Es la forma antigua, y la que queda cuando lscpu no está, cosa que ocurre en algunos contenedores.

10. El resto del hardware

Para lo demás hay una familia de comandos que empiezan con ls, cada uno dedicado a una clase de dispositivos. No hace falta recordar sus opciones: alcanza con saber que existen, y filtrarlos con grep.

$ lspci | grep -iE 'vga|network|ethernet'
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (4) I219-V (rev 21)
03:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)
$ lsusb | wc -l
6
$ sudo dmidecode -t memory | grep -E '^\s(Size|Type|Speed|Locator):'
	Size: 8 GB
	Locator: ChannelA-DIMM0
	Type: DDR4
	Speed: 2400 MT/s
	Size: No Module Installed
	Locator: ChannelB-DIMM0
	Type: Unknown
	Speed: Unknown

La primera consulta es la que se hace cuando algo no funciona —la red inalámbrica, la placa de video— y hay que buscar ayuda: el modelo exacto del dispositivo es lo que permite encontrar la respuesta. Un truco con lsusb: ejecutarlo, conectar el dispositivo, ejecutarlo de nuevo, y comparar. Si la línea nueva no aparece, el problema es del cable o del puerto, y no hay nada que configurar.

La tercera es la que ahorra abrir el equipo. dmidecode lee las tablas del firmware, y por eso pide sudo: aquí dice que hay un módulo de 8 GB, DDR4, y que el segundo zócalo está vacío. Es todo lo que hay que saber para comprar una ampliación. En una máquina virtual estos datos son ficticios, y en un contenedor el comando no funciona.

11. vmstat: el sistema en movimiento

uptime y free dan una foto. Para saber si la memoria se está agotando o la carga está subiendo hace falta una secuencia. vmstat, de virtual memory statistics, escribe una línea con el estado de todo el sistema, y la repite con el intervalo que se le indique.

$ vmstat 2 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 655360 145408 3746816    0    0   118    64  412  893  4  1 94  1  0
 0  0      0 654980 145408 3746820    0    0     0    12  388  721  2  1 97  0  0
 0  0      0 655104 145416 3746820    0    0     0     0  402  760  3  1 96  0  0
 2  0      0 649216 145416 3748992    0    0     0   148  655 1310 14  3 83  0  0
 0  0      0 654720 145424 3746952    0    0     0     8  395  744  2  1 97  0  0

El primer argumento es el intervalo en segundos, y el segundo, la cantidad de líneas; sin el segundo, sigue hasta Ctrl+C. Las columnas vienen en seis grupos:

Hay un detalle que evita conclusiones falsas: la primera línea no es una medición. Es el promedio desde que arrancó el sistema, y por eso muestra lecturas de disco que las demás no tienen. Las mediciones de verdad empiezan en la segunda.

En el ejemplo se ve un equipo tranquilo, con un breve episodio en la cuarta línea: dos procesos en r, el procesador ocupado en un 17 %, una escritura en disco. Cada problema de rendimiento tiene su firma en esta tabla:

Con vmstat -S M 2 las cantidades de memoria se muestran en mebibytes, que se leen mejor.

12. watch: repetir un comando

vmstat y free -s saben repetirse. La mayoría de los comandos no, y para ellos existe watch: ejecuta el comando que se le dé cada dos segundos, y muestra su salida a pantalla completa, reemplazando la anterior.

$ watch free -h
Every 2.0s: free -h                             equipo: Tue Oct 13 09:52:14 2026

               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       3.6Gi       640Mi       412Mi       3.7Gi       4.0Gi
Swap:          2.0Gi          0B       2.0Gi

La línea de arriba muestra el intervalo, el comando, el nombre de la máquina y la hora de la última ejecución. Se sale con Ctrl+C.

Sirve con cualquier comando, y por eso es de los que se usan toda la vida: watch -d free -h para ver adónde va la memoria, watch -n 1 uptime para seguir la carga, watch ls -l descargas/ para ver crecer un archivo que se está copiando.

Cuando el comando lleva una tubería o una redirección, hay que encerrarlo entre comillas. De lo contrario, la shell corta la línea en la barra, y lo que se filtra es la salida de watch:

$ watch -n 1 'ps aux --sort=-%cpu | head -n 6'     # bien: watch repite la tubería entera
$ watch -n 1 ps aux --sort=-%cpu | head -n 6       # mal: head recibe la salida de watch

El primero es un top improvisado, hecho con piezas de los temas 24 y 32: los cinco procesos que más procesador usan, actualizados cada segundo.

13. Un diagnóstico en cinco pasos

Todo lo anterior se junta en la situación del comienzo: una máquina que responde con lentitud. Los recursos que pueden faltar son tres —procesador, memoria, disco—, y un minuto de comandos alcanza para saber cuál.

1. ¿Hay cola, y desde cuándo? uptime, comparando la carga con nproc y mirando la tendencia de los tres números. carga
2. ¿Alcanza la memoria? free -h: la columna available y la fila Swap. memoria
3. ¿Qué recurso es? vmstat 2 5: us para el procesador, wa y b para el disco, si y so para la memoria. recurso
4. ¿Qué proceso es? top, ordenado por procesador o, con M, por memoria. culpable
5. ¿Hay espacio en el disco? df -h. Un disco lleno produce fallos que parecen de cualquier otra cosa; es el tema 38. espacio

La última fila es un resultado tan útil como los otros: saber que la máquina no es el problema evita perder una tarde buscándolo en el lugar equivocado.

Como estos comandos escriben texto y terminan, se pueden agrupar para dejar constancia del estado en un momento dado. Con las llaves del tema 25, toda la salida va a un mismo archivo:

$ cd ~/practica
$ { echo "== $(hostname) · $(date '+%F %T')"; uname -r; uptime; free -h; } > estado.txt
$ cat estado.txt
== equipo · 2026-10-13 09:58:40
6.8.0-87-generic
 09:58:40 up  1:29,  1 user,  load average: 0,31, 0,52, 0,58
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       3.6Gi       652Mi       412Mi       3.7Gi       4.0Gi
Swap:          2.0Gi          0B       2.0Gi

Es una línea larga, incómoda de volver a escribir, y que uno querría ejecutar todos los días. Esa incomodidad es exactamente el motivo por el que existen los scripts, y a ella volvemos en el tema 41.

14. Recetas y errores comunes

La referencia del tema:

En ~/practica queda un archivo nuevo, estado.txt. Sabemos ya preguntarle al sistema por su kernel, su carga, su memoria y su procesador. Falta el recurso que, cuando se agota, produce los fallos más desconcertantes, y el que más se deja sin vigilar. En el tema 38 nos ocupamos de los discos: cuánto espacio queda, quién lo ocupa, y cómo se conecta un dispositivo al árbol de directorios.

15. Resumen

• Los comandos de estado leen de /proc y de /sys, no modifican nada y casi nunca requieren sudo. Son iguales en todas las distribuciones.
• uname -r muestra la versión del kernel en ejecución, y uname -m, la arquitectura: x86_64, aarch64.
• La versión del kernel y la de la distribución son datos distintos. La segunda está en /etc/os-release.
• hostnamectl reúne el nombre de la máquina, la distribución, el kernel, el modelo del equipo y si es virtual.
• uptime muestra cuánto lleva encendido el sistema y la carga media del último minuto, de los últimos cinco y de los últimos quince.
• La carga media es la cantidad promedio de procesos que usan el procesador o esperan por él o por el disco. Se interpreta comparándola con nproc.
• Los tres números de la carga muestran la tendencia: si el primero es el mayor, la carga sube; si es el menor, baja.
• free -h muestra la memoria. La columna que indica cuánta queda es available, no free.
• El kernel usa la memoria sobrante como caché de disco y la cede cuando hace falta: poca memoria libre es lo normal.
• El área de intercambio es disco usado como extensión de la memoria. Que crezca, con available bajo, indica que la memoria no alcanza.
• lscpu distingue zócalos, núcleos e hilos. Su producto es la cantidad de procesadores lógicos, que informa nproc.
• lspci, lsusb y dmidecode hacen el inventario del resto del hardware.
• vmstat 2 muestra la evolución del sistema: r y us señalan al procesador, b y wa al disco, si y so a la memoria. Su primera línea es un promedio desde el arranque.
• watch repite cualquier comando cada pocos segundos; con una tubería, el comando va entre comillas.
• Un sistema lento se diagnostica en orden: carga, memoria, recurso, proceso y espacio en disco.

16. Preguntas de repaso

Intenta responder cada una antes de abrir la respuesta.

Para practicar

1. Muestra por separado el nombre del kernel, su versión y la arquitectura. Compara la versión con la de cat /proc/version, y con la versión de la distribución en /etc/os-release.
2. Lista los kernels instalados con dpkg -l 'linux-image*' | grep '^ii', o el equivalente de tu distribución. ¿Coincide el más nuevo con el que informa uname -r?
3. Ejecuta hostnamectl. ¿Qué tipo de equipo declara? ¿Aparece la línea Virtualization? Compara el Boot ID con el de después de un reinicio.
4. Averigua cuándo arrancó el sistema de tres maneras: con uptime -s, con who -b y con el primer campo de /proc/uptime, convertido de segundos a horas con awk.
5. Anota la carga y la salida de nproc. Lanza en segundo plano tantos yes > /dev/null como procesadores tengas, y sigue la carga con watch -n 5 uptime durante dos minutos. Mátalos con kill y observa cuánto tarda cada uno de los tres números en volver a su valor.
6. Ejecuta free -h, free -m y free -h --si. Calcula qué porcentaje del total está disponible, y qué porcentaje figura como libre.
7. Repite la experiencia de la sección 7: anota free -m, lee muchos archivos grandes hacia /dev/null, y vuelve a mirar. ¿Qué columnas cambiaron? Antepón time al comando de lectura —informa cuánto tardó en ejecutarse— y compara la primera vez con la segunda.
8. Con lscpu, determina el modelo de tu procesador, cuántos zócalos, núcleos e hilos tiene, y si está dentro de una máquina virtual. Verifica el producto contra nproc.
9. Deja corriendo vmstat 2 en una terminal y, en otra, abre un programa pesado, copia un archivo grande y ejecuta sudo apt update. ¿Qué columnas reaccionan en cada caso?
10. Arma con llaves un informe que guarde en ~/practica/estado.txt la fecha, el nombre de la máquina, la versión de la distribución y del kernel, el modelo del procesador y la cantidad de procesadores, la carga y la memoria. Ejecútalo dos veces usando >>, y comprueba que el archivo conserva los dos informes.