23 Preguntas de Práctica de Resolución de problemas: red y rendimiento con Respuestas

1. 1. Un usuario informa de que no puede llegar a una aplicación interna desde un servidor Linux. En ese servidor, `ping 10.40.12.15` (la dirección del servidor de la aplicación) responde con tiempos normales, mientras que `ping app.corp.example` devuelve 'ping: app.corp.example: Name or service not known'. ¿Qué demuestra esta evidencia y qué debe revisarse a continuación?

   • A.La alcanzabilidad hasta la capa de enrutamiento está demostrada, así que el fallo está en la resolución de nombres: revise nameserver en /etc/resolv.conf y la salida de resolvectl status.✓ Respuesta
   • B.Falta la puerta de enlace predeterminada, por lo que ninguna red remota resulta alcanzable: compare las entradas que imprime ip route con la dirección configurada en esa interfaz.
   • C.El puerto de la aplicación está siendo filtrado, así que las sesiones nunca llegan a abrirse: revise la zona activa y sus puertos permitidos con firewall-cmd --list-all.
   • D.La interfaz no tiene ninguna concesión utilizable, así que nada sale del host: compruebe el estado del dispositivo y el perfil de conexión activo con nmcli device status.

   Un ping correcto a la dirección literal ejercita la interfaz, la ruta y el host remoto, así que todo hasta la capa de enrutamiento funciona; que el mismo ping por nombre falle con un error del resolutor y no con un tiempo agotado aísla el problema en la resolución de nombres, que en un host con systemd-resolved se configura en /etc/resolv.conf y se consulta con resolvectl status.

   Ref. QB-6BF9YNFuente: CompTIA Linux+ exam objectives, Troubleshooting domain — analyzing networking issues (DNS issues); resolv.conf(5) and systemd-resolved(8) manual pagesReportar un problema con esta pregunta

2. 2. En un host Linux, `dig +short files.corp.example` devuelve '10.60.4.20', pero `getent hosts files.corp.example` no imprime nada y la aplicación falla con 'Temporary failure in name resolution'. ¿Qué archivo debe revisarse primero y por qué?

   • A./etc/resolv.conf, porque dig lee su propia configuración aparte y la biblioteca de C toma su lista de nameserver solo de ese archivo.
   • B./etc/nsswitch.conf, porque su línea hosts decide qué fuentes consulta la biblioteca de C, mientras dig pregunta directamente a los DNS.✓ Respuesta
   • C./etc/hosts, porque una entrada estática allí se devuelve a dig antes de contactar con cualquier nameserver, y por eso ambos discrepan.
   • D./etc/services, porque la biblioteca traduce el nombre del servicio a un número de puerto antes de intentar resolver la dirección del host.

   dig envía su consulta directamente a un servidor DNS, así que un dig correcto demuestra que el DNS responde; getent recorre toda la ruta del Name Service Switch que usan los programas normales, de modo que si uno funciona y el otro no, la discrepancia está en esa configuración: la línea hosts de /etc/nsswitch.conf, que enumera y ordena las fuentes permitidas a la biblioteca de C.

   Ref. QB-NT94DNFuente: nsswitch.conf(5) and getent(1) manual pages; CompTIA Linux+ exam objectives, network services and configuration (/etc/nsswitch.conf)Reportar un problema con esta pregunta

3. 3. Un servicio web se migró a una dirección nueva. En un cliente Linux, `dig +short reports.corp.example` devuelve '172.18.9.60', pero `getent hosts reports.corp.example` imprime '172.18.9.31 reports.corp.example' y curl sigue conectando a 172.18.9.31. ¿Cuál es la causa más probable?

   • A.El tiempo de vida del registro aún no ha caducado en el servidor autoritativo, así que toda consulta sigue recibiendo la dirección previa.
   • B.curl mantiene su propia caché de direcciones entre ejecuciones y reutiliza la dirección de la última conexión que logró completar.
   • C.Una entrada obsoleta de ese nombre en /etc/hosts se consulta antes que DNS, así que la biblioteca devuelve la dirección antigua.✓ Respuesta
   • D.Un segundo sufijo de búsqueda de /etc/resolv.conf se añade primero, así que otra zona responde al nombre que dig había consultado.

   En un host cuyo Name Service Switch pone files antes de dns, una entrada de /etc/hosts gana sin más y no se consulta al DNS para ese nombre, mientras dig nunca lee /etc/hosts y por eso informa de la respuesta actual del DNS. La divergencia entre dig y getent o curl es la firma de una entrada estática local, que además nunca caduca por sí sola.

   Ref. QB-5B4XSMFuente: hosts(5) and nsswitch.conf(5) manual pages; CompTIA Linux+ exam objectives, Troubleshooting domain — DNS issuesReportar un problema con esta pregunta

4. 4. Dos servidores Linux están en la misma subred. En serverA, `getent hosts vpn.corp.example` devuelve una dirección; en serverB el mismo comando no devuelve nada, aunque `ping` a esa dirección desde serverB funciona y ambos hosts llegan a internet. ¿Cuál es la causa más probable y por dónde debe empezar la comprobación?

   • A.La zona autoritativa responde de forma intermitente: consulte su nameserver con dig repetidamente desde ambos hosts hasta que difieran.
   • B.serverB anuncia una MTU menor y la respuesta grande se descarta en tránsito: mida la ruta desde serverB con ping -M do -s antes de nada.
   • C.Los dos hosts consultan resolutores distintos: compare con resolvectl status los valores de nameserver y de búsqueda que usa cada uno.✓ Respuesta
   • D.El reloj de serverB se ha desviado y la validación de las respuestas falla: compare la hora y la sincronización con timedatectl en ambos.

   La resolución de nombres es configuración por host: cada máquina tiene su propia lista de resolutores, sus dominios de búsqueda y su orden en el Name Service Switch, así que una misma consulta puede funcionar en un host y fallar en su vecino aun en una sola subred. Como el ping a la dirección funciona desde el host que falla, la conectividad y el enrutamiento están intactos, lo que señala al resolutor de ese host y no a la red ni a la zona.

   Ref. QB-RTB4WRFuente: resolv.conf(5) and resolvectl(1) manual pages; CompTIA Linux+ exam objectives, Troubleshooting domain — DNS issuesReportar un problema con esta pregunta

5. 5. Un cliente Linux ejecuta `curl http://10.44.2.18:8080/health` y el comando devuelve casi de inmediato 'curl: (7) Failed to connect to 10.44.2.18 port 8080: Connection refused'. El ping a 10.44.2.18 funciona. ¿Qué demuestra este error?

   • A.El servicio rechazó la sesión durante el saludo inicial, así que el transporte se abrió y cerró: pruebe la negociación con openssl s_client.
   • B.Un filtro de paquetes descartó la petición en la entrada y por eso el cliente dejó de esperar: revise las reglas con firewall-cmd --list-all.
   • C.Falta la ruta hacia esa red y la petición nunca salió del cliente: muestre la ruta que elegiría el kernel con ip route get 10.44.2.18.
   • D.El paquete llegó al host y el kernel respondió con un reset porque ningún proceso escucha en ese puerto: confirme los sockets con ss -tulnp.✓ Respuesta

   Un rechazo es una respuesta: el destino recibió el segmento y su kernel devolvió un reset, lo que ocurre cuando nada está enlazado a ese puerto, así que la interfaz, la ruta y el host quedan demostrados y la investigación pasa al servicio y su socket de escucha. Al ser una respuesta inmediata y no una espera, se descartan tanto el filtrado silencioso como la falta de ruta, y ss -tulnp muestra qué dirección y puerto tomó el servicio.

   Ref. QB-8B6XARFuente: ss(8) manual page and curl exit-code documentation; CompTIA Linux+ exam objectives, Troubleshooting domain — server unreachable versus a service that is not listeningReportar un problema con esta pregunta

6. 6. Contra el mismo host Linux, `nc -vz 10.44.2.18 8080` espera mucho tiempo y termina con 'Connection timed out', mientras `nc -vz 10.44.2.18 9100` responde de inmediato con 'Connection refused'. ¿Qué explicación encaja con ambos resultados?

   • A.Ninguno de los dos puertos tiene un proceso escuchando, y la espera del 8080 solo refleja una aplicación más lenta que la del 9100 al aceptar.
   • B.El proceso del 8080 está en espera ininterrumpible y no puede aceptar, mientras que el del 9100 está en marcha y rechaza las peticiones.
   • C.El tráfico al 8080 se descarta en silencio antes de que lo vea ningún proceso, y el 9100 devolvió un reset desde un host sin nada enlazado.✓ Respuesta
   • D.El 8080 lo bloquea el control de acceso de la propia aplicación y el 9100 lo filtra el cortafuegos de paquetes que hay delante del host.

   Los dos fallos provienen de mecanismos distintos: un filtro que descarta el paquete no da respuesta alguna, así que el cliente retransmite hasta agotar su propio tiempo de espera, mientras que un puerto sin proceso escuchando produce un reset inmediato que se informa como 'Connection refused'. El tiempo agotado apunta a filtrado silencioso o a una ruta sumidero, y el rechazo apunta a un host alcanzable cuyo servicio falta o está detenido.

   Ref. QB-QTYRQQFuente: CompTIA Linux+ exam objectives, Troubleshooting domain — misconfigured firewalls and server unreachable; firewalld and nftables documentation on drop versus reject targetsReportar un problema con esta pregunta

7. 7. Un demonio de informes en un servidor Linux responde a `curl http://localhost:9000` en el propio servidor, pero todo cliente remoto agota el tiempo aunque el cortafuegos permite 9000/tcp. `ss -tulnp` muestra: 'LISTEN 0 128 127.0.0.1:9000 0.0.0.0:* users:(("reportd",pid=1422,fd=6))'. ¿Cuál es la causa?

   • A.La regla del cortafuegos quedó en una zona que la interfaz no usa, así que el filtro descarta los paquetes remotos antes de la entrega.
   • B.La cola de escucha de 128 la agotan los clientes locales, así que los saludos remotos esperan hasta que el cliente informa de un tiempo agotado.
   • C.El demonio está enlazado únicamente a la dirección de loopback, así que los paquetes que llegan por la interfaz física no encuentran socket.✓ Respuesta
   • D.El demonio se ejecuta sin privilegios, de modo que el kernel admite clientes locales pero rechaza las conexiones que llegan de fuera del host.

   Un socket enlazado a 127.0.0.1 existe solo en la ruta de loopback, así que un paquete que llega por una interfaz física al puerto 9000 no encuentra socket y recibe un reset o se descarta, sin importar lo que permita el cortafuegos. La corrección está en la configuración del propio servicio: enlazarlo a una dirección enrutable o al comodín y reiniciarlo, y ss es lo que revela qué dirección tomó el servicio.

   Ref. QB-7BTK5QFuente: ss(8) and ip(8) manual pages; CompTIA Linux+ exam objectives, Troubleshooting domain — services bound to the wrong addressReportar un problema con esta pregunta

8. 8. Un host Linux muestra 'inet 10.10.4.37/16 brd 10.10.255.255 scope global ens192' y una tabla de rutas con 'default via 10.10.4.1 dev ens192' y '10.10.0.0/16 dev ens192 proto kernel scope link'. El segmento al que está conectado es en realidad 10.10.4.0/24, y el resto de 10.10.0.0/16 se enruta detrás de la puerta de enlace. Los vecinos de 10.10.4.0/24 y los hosts de internet responden, pero `ssh 10.10.9.20` falla al instante con 'connect: No route to host'. ¿Por qué?

   • A.La dirección de difusión derivada de ese prefijo es incorrecta, así que la resolución de direcciones no se completa para ningún destino fuera de su propio /24.
   • B.La ruta predeterminada es inservible porque su siguiente salto cae dentro de una red de ámbito de enlace, así que el kernel descarta el tráfico saliente.
   • C.El prefijo es demasiado amplio: el host cree que 10.10.9.20 está conectado directamente e intenta resolverlo por ARP en el segmento en vez de usar la puerta de enlace.✓ Respuesta
   • D.La puerta de enlace no tiene ruta de retorno para un origen /16, así que las respuestas de 10.10.9.20 se pierden al volver y el cliente informa del fallo.

   La longitud del prefijo es lo que indica al kernel qué direcciones están en el enlace. Con /16 configurado, el kernel instala una ruta de ámbito de enlace para todo 10.10.0.0/16, y esa ruta más específica vence a la predeterminada, así que los paquetes para 10.10.9.20 nunca llegan a la puerta de enlace; el host intenta resolver por ARP una estación que no está en el cable y falla al instante con 'No route to host'. Corregir el prefijo a /24 restaura el camino por la puerta de enlace.

   Ref. QB-JT74VHFuente: ip-address(8) and ip-route(8) manual pages; CompTIA Linux+ exam objectives, Troubleshooting domain — interface misconfiguration (subnet) and routing issuesReportar un problema con esta pregunta

9. 9. Un servidor Linux recién aprovisionado y gestionado por NetworkManager llega a todos los hosts de su propia subred pero a nada más allá, y las consultas a un resolutor de otra subred agotan el tiempo. `ip route` imprime una sola línea: '10.50.8.0/24 dev eth0 proto kernel scope link src 10.50.8.22'. ¿Qué conclusión se sigue y cuál es el paso correcto?

   • A.El filtrado de ruta inversa descarta las respuestas cuando vuelven: relaje el ajuste rp_filter de esa interfaz con sysctl y repita la prueba.
   • B.El enlace está desactivado administrativamente y solo responden los vecinos que ya estaban en la caché: active la interfaz y compruebe el estado con ip link.
   • C.La lista de resolutores está vacía y las consultas de nombres no llegan a ningún servidor: añada las direcciones nameserver al perfil con nmcli.
   • D.No hay ruta predeterminada instalada, así que el tráfico hacia otras redes no tiene salida: fije la puerta de enlace con nmcli y reactive el perfil.✓ Respuesta

   El kernel reenvía un paquete solo si una ruta coincide con su destino, así que con una única ruta de ámbito de enlace para el /24 local y sin ruta predeterminada, todo lo que está fuera de 10.50.8.0/24 falla de inmediato y un resolutor de otra subred queda inalcanzable, y por eso también caducan las consultas de nombres. En un host con NetworkManager lo duradero es poner la puerta de enlace en el perfil de conexión para que sobreviva a la reactivación y al reinicio.

   Ref. QB-2B2X9HFuente: ip-route(8) and nmcli(1) manual pages; CompTIA Linux+ exam objectives, Troubleshooting domain — routing issues (gateway)Reportar un problema con esta pregunta

10. 10. A través de un túnel entre dos sedes, `ping -c 4` a un servidor Linux no informa de pérdidas, SSH conecta, imprime su banner y luego se congela, y las descargas HTTPS grandes se detienen tras unos kilobytes. Desde el cliente, `ping -M do -s 1472 remote` devuelve 'From 10.1.1.1 icmp_seq=1 Frag needed and DF set (mtu=1400)', mientras `ping -M do -s 1372 remote` funciona. ¿Qué ocurre?

    • A.El cortafuegos remoto limita la velocidad en cuanto empieza la transferencia masiva, así que el saludo se completa y el rendimiento cae a casi nada.
    • B.Los dos extremos del enlace local no coinciden en dúplex, así que los errores aparecen solo con tráfico sostenido en ambos sentidos.
    • C.La renegociación de cifrado del túnel falla a mitad, así que el banner se intercambia pero no pasa dato alguno tras renovar las claves.
    • D.Un salto de la ruta acepta un paquete menor que el que anuncia la interfaz, así que los segmentos completos se descartan y la sesión se detiene.✓ Respuesta

    Los paquetes pequeños y el saludo inicial caben en el enlace más estrecho de la ruta, así que las pruebas de alcance y el banner de acceso funcionan; en cuanto la sesión envía segmentos completos superan ese límite y se descartan, que es justo lo que informa la respuesta 'Frag needed and DF set (mtu=1400)', y la carga mayor que pasa con ping -M do mide el tamaño útil de la ruta. La solución es ajustar el tamaño de paquete de la interfaz o del túnel a esa ruta.

    Ref. QB-C7H6E4Fuente: ping(8) manual page and kernel networking documentation on path MTU discovery; CompTIA Linux+ exam objectives, Troubleshooting domain — interface misconfiguration (MTU mismatch)Reportar un problema con esta pregunta

11. 11. Un servidor Linux de base de datos con dirección estática se cae de la red durante segundos cada cierto tiempo. Un tcpdump en un host vecino muestra 'ARP, Reply 10.50.8.40 is-at 00:50:56:9a:11:22' y, poco después, 'ARP, Reply 10.50.8.40 is-at 52:54:00:3c:4d:5e', y el journal del servidor registra una colisión de direcciones. ¿Qué primera acción identifica al dispositivo culpable?

    • A.Reinicie el servicio de red del servidor de base de datos para que reclame la dirección y se limpie la entrada duplicada del segmento.
    • B.Tome la dirección física que no pertenece al servidor y rastréela hasta un puerto mediante la tabla de reenvío del conmutador.✓ Respuesta
    • C.Acorte con sysctl la vida de la caché de vecinos del servidor de base de datos para que las direcciones físicas viejas se descarten antes.
    • D.Cambie el servidor de base de datos a una dirección entregada por DHCP para que reciba una que ningún otro dispositivo esté usando.

    Que dos direcciones físicas distintas respondan por ARP a una misma dirección es la firma de un conflicto de direcciones, y el mensaje de colisión del journal confirma que el propio servidor detectó a un competidor. El único dato que conduce a la segunda máquina es la dirección física inesperada, que las tablas de reenvío del conmutador asocian a un puerto y por tanto a un dispositivo; renovar o cambiar la dirección del servidor oculta el síntoma sin eliminar al duplicado.

    Ref. QB-VPPBZ4Fuente: ip-neighbour(8) and arp(8) manual pages; CompTIA Linux+ exam objectives, Troubleshooting domain — IP conflictsReportar un problema con esta pregunta

12. 12. En un servidor basado en RPM con firewalld, un administrador ejecutó 'firewall-cmd --zone=public --add-port=8443/tcp' y los clientes conectaron correctamente. Tras el siguiente reinicio las conexiones vuelven a agotar el tiempo y 'firewall-cmd --list-ports' no imprime nada. ¿Qué lo explica?

    • A.La interfaz quedó asignada a su zona predeterminada al arrancar, así que el puerto está permitido en una zona a la que no hay interfaz enlazada.
    • B.Se permitió el puerto sin una definición de servicio correspondiente, y firewalld elimina al arrancar las reglas de puerto que ningún servicio reclama.
    • C.El cambio nunca llegó a aplicarse, porque un puerto de tiempo de ejecución solo admite conexiones nuevas después de ejecutar firewall-cmd --reload.
    • D.El puerto entró en la configuración de tiempo de ejecución, que firewalld descarta al recargar o reiniciar si no se escribe con --permanent.✓ Respuesta

    firewalld mantiene dos configuraciones: la de tiempo de ejecución, que surte efecto al instante y se pierde al recargar, reiniciar el servicio o el equipo, y la permanente, que se carga al arrancar. Un cambio hecho sin --permanent funciona hasta que el servicio recarga y luego desaparece, por eso la secuencia duradera es añadir el puerto con --permanent y después recargar para que lo guardado pase a estar en vigor.

    Ref. QB-B76U83Fuente: firewall-cmd(1) and firewalld.zone(5) documentation on runtime versus permanent configuration; CompTIA Linux+ exam objectives, firewall configurationReportar un problema con esta pregunta

13. 13. Los usuarios informan de que las aplicaciones de un servidor Linux de ocho núcleos van lentas. 'uptime' muestra 'load average: 16.42, 15.98, 14.21' y la línea resumen de top dice '%Cpu(s): 3.1 us, 2.4 sy, 0.0 ni, 12.0 id, 82.1 wa, 0.0 hi, 0.4 si, 0.0 st'. ¿Qué indican estas cifras?

    • A.El trabajo está en cola esperando entrada y salida, no tiempo de procesador, así que el cuello de botella es el almacenamiento pese a la carga alta.✓ Respuesta
    • B.Los procesadores están saturados porque la carga media supera con holgura el número de núcleos, así que hay que mover trabajo o añadir núcleos.
    • C.La memoria está agotada y el kernel reclama páginas sin parar, y ese reclamo es lo que representa la porción de espera del procesador aquí.
    • D.Las cifras son normales para un host de este tamaño, porque la carga media cuenta todos los hilos que el planificador sigue, se ejecuten o no.

    La carga media cuenta los procesos que quieren ejecutarse más los bloqueados en espera ininterrumpible, así que mide demanda y no utilización del procesador, y solo significa algo junto al número de núcleos y al desglose del tiempo de CPU. Aquí el tiempo de usuario y de sistema es mínimo mientras el 82,1 por ciento es espera, de modo que los procesadores están ociosos esperando al almacenamiento y ahí está la investigación.

    Ref. QB-UPBZT3Fuente: proc(5) description of /proc/loadavg and top(1) manual page; CompTIA Linux+ exam objectives, Troubleshooting domain — high load average and high I/O wait timeReportar un problema con esta pregunta

14. 14. A un administrador le dicen que un servidor Linux se ha quedado sin memoria. 'free -h' informa 'Mem: total 31Gi, used 9.8Gi, free 0.6Gi, shared 0.4Gi, buff/cache 21Gi, available 20Gi' y 'Swap: total 4.0Gi, used 0Ki, free 4.0Gi'. ¿Qué muestra realmente esta salida?

    • A.El host está casi sin memoria, porque la columna free es la única memoria que el kernel puede entregar de inmediato a un proceso que pida más.
    • B.Hay una fuga en curso, ya que una caché que crece mientras la memoria libre baja es como un proceso con fuga consume el resto.
    • C.La mayor parte de la memoria es caché recuperable, y la columna available es lo que puede obtener trabajo nuevo, así que no falta memoria.✓ Respuesta
    • D.El intercambio ya absorbió la presión, así que la cifra de swap sin usar demuestra que la escasez se alivió y no hace falta actuar.

    Linux usa a propósito la memoria ociosa como caché de páginas, así que una cifra pequeña en free es normal en un servidor ocupado porque esa caché es recuperable a demanda. El número que describe el margen real es 'available', que estima cuánto puede reservar una carga nueva sin empujar al sistema al intercambio, y aquí la mayor parte del total está disponible con el swap intacto, de modo que no hay escasez.

    Ref. QB-A7TG32Fuente: free(1) manual page and proc(5) description of MemAvailable in /proc/meminfo; CompTIA Linux+ exam objectives, Troubleshooting domain — out of memory and memory leaksReportar un problema con esta pregunta

15. 15. Un host Linux va lento incluso en el intérprete de comandos. Una línea estable de 'vmstat 1' dice: 'r 6 b 3 swpd 3891200 free 71232 buff 1024 cache 96256 si 2144 so 2560 bi 8412 bo 9100 in 6210 cs 14820 us 12 sy 9 id 4 wa 75 st 0'. ¿Qué lectura de esta salida es correcta?

    • A.El host pagina memoria anónima de forma continua, y ese tráfico de disco es lo que produce la espera alta y el terminal lento.✓ Respuesta
    • B.El procesador es la limitación, porque una cola de ejecución por encima de los núcleos y cambios de contexto constantes lo saturan.
    • C.Las columnas muestran actividad de archivos normal, porque las columnas de swap informan solo del espacio de intercambio configurado.
    • D.Habría que retirar el intercambio para eliminar el tráfico de disco, porque un host que pagina se recupera al quitarle el dispositivo swap.

    Las columnas si y so cuentan la memoria que se mueve cada segundo entre la RAM y el dispositivo de intercambio, así que valores sostenidos distintos de cero significan que el sistema pagina de verdad, lo cual es consecuencia de la falta de memoria y no su causa. Los procesos bloqueados y la espera elevada se derivan de ese tráfico compitiendo con la actividad de disco normal, así que hay que reducir la demanda o ampliar la memoria.

    Ref. QB-TPYNN2Fuente: vmstat(8) manual page and proc(5) memory fields; CompTIA Linux+ exam objectives, Troubleshooting domain — swapping and system unresponsivenessReportar un problema con esta pregunta

16. 16. Un servicio Java desaparece de madrugada sin dejar nada en su propio registro. 'journalctl -k' de ese periodo contiene: 'Out of memory: Killed process 8123 (java) total-vm:9814232kB, anon-rss:7521288kB, file-rss:0kB, shmem-rss:0kB, UID:994 pgtables:15100kB oom_score_adj:0'. ¿Qué demuestra esto y cuál es el seguimiento adecuado?

    • A.El kernel se quedó sin memoria utilizable y mató al mayor consumidor: compare el consumo del servicio con el host y ajuste sus límites o amplíe memoria.✓ Respuesta
    • B.Un administrador o una tarea programada terminó el servicio con una señal: audite las definiciones de tareas y el historial de shell de esa franja.
    • C.La asignación falló porque no hay dispositivo de intercambio: añadir swap evitará que el kernel elija este proceso la próxima vez que falte memoria.
    • D.El servicio terminó por su cuenta y el kernel solo registró el suceso: habilite volcados de memoria y analice el próximo fallo desde la aplicación.

    La línea 'Out of memory: Killed process' la escribe el terminador por falta de memoria del kernel, que elige una víctima por su puntuación cuando no puede satisfacer una reserva, así que su presencia demuestra que fue el host y no la aplicación quien terminó el proceso, y la cifra anon-rss indica cuánta memoria anónima residente ocupaba. El seguimiento es capacidad o un límite de memoria por servicio, ya que el swap solo aplaza la escasez.

    Ref. QB-DYDTWTFuente: kernel documentation on the out-of-memory killer and proc(5) oom_score_adj; CompTIA Linux+ exam objectives, Troubleshooting domain — out of memory and killed processesReportar un problema con esta pregunta

17. 17. Un trabajo por lotes nocturno en un host Linux tarda mucho más de lo habitual mientras 'top' muestra el host casi inactivo. 'mpstat -P ALL 1' informa 'all: %usr 12.60 %sys 0.75 %iowait 0.10 %steal 0.00 %idle 86.50', 'CPU 0: %usr 99.00 %sys 1.00 %idle 0.00', y el resto de núcleos por encima del 95 por ciento inactivos. ¿Qué indica esto?

    • A.El planificador no reparte la carga, así que conviene fijar el trabajo con taskset en un núcleo menos ocupado para distribuir la demanda.
    • B.Un proceso de un solo hilo ha saturado un núcleo, así que la cifra agregada de inactividad oculta un cuello de botella real para ese trabajo.✓ Respuesta
    • C.El host está inactivo y el retraso viene de otra parte, porque la cifra agregada es la que decide si el procesador limita el trabajo.
    • D.Una tormenta de interrupciones consume un núcleo, y la solución es repartir las interrupciones de ese dispositivo cambiando la afinidad de IRQ.

    Las cifras agregadas del procesador son promedios de todos los núcleos, así que un núcleo totalmente ocupado en un host por lo demás tranquilo aparece solo como un porcentaje global modesto, y es la vista por núcleo la que revela la saturación. Como el tiempo del núcleo ocupado es de usuario, con interrupciones y espera insignificantes, el límite es el hilo único que hace el trabajo, así que toca identificar ese proceso y paralelizarlo o reprogramarlo.

    Ref. QB-WFKYGUFuente: mpstat(1) and top(1) manual pages; CompTIA Linux+ exam objectives, Troubleshooting domain — CPU bottleneck and high CPU usageReportar un problema con esta pregunta

18. 18. Las consultas de una base de datos en un servidor Linux son lentas mientras los procesadores están casi inactivos. 'iostat -xz 1' informa para el dispositivo de datos: 'sdb r/s 412.0 w/s 128.0 rkB/s 6592.0 wkB/s 2048.0 aqu-sz 23.40 r_await 52.80 w_await 61.30 %util 99.80'. ¿Qué muestra esta evidencia?

    • A.Las tasas de transferencia son modestas, así que el dispositivo no es la limitación y el retraso viene de los planes de consulta de la base de datos.
    • B.El sistema de archivos del dispositivo está casi lleno, y por eso la utilización se informa cerca del cien por cien para cada petición que recibe.
    • C.Las peticiones son demasiado pequeñas, así que subir el valor de lectura anticipada hasta que crezcan es lo que bajará la utilización del disco.
    • D.El dispositivo trabaja en su límite, con una cola larga y decenas de milisegundos de servicio, así que las consultas esperan por la latencia del disco.✓ Respuesta

    Una utilización por dispositivo cercana al cien por cien, junto con una profundidad media de cola muy superior a uno y valores de await de decenas de milisegundos, describe un dispositivo saturado cuyas peticiones pasan casi todo su tiempo en cola y no siendo atendidas. Como el procesador está ocioso mientras se acumula la espera, el cuello de botella es el almacenamiento, y %util indica lo ocupado que está el dispositivo, no lo lleno que esté el sistema de archivos.

    Ref. QB-CY2GRSFuente: iostat(1) manual page; CompTIA Linux+ exam objectives, Troubleshooting domain — high disk latency, low throughput and high I/O wait timeReportar un problema con esta pregunta

19. 19. En un host Linux, 'ps -eo pid,stat,wchan:20,comm' imprime ' 4411 D wait_on_page_bit backupd' y ' 4520 Z - reportgen'. A ambos ya se les envió SIGKILL y los dos siguen apareciendo. ¿Cómo debe tratarse cada uno?

    • A.Envíe SIGKILL a ambos por segunda vez, porque un proceso ininterrumpible y un zombi desaparecen en cuanto la misma señal se entrega de nuevo.
    • B.Repare la ruta de entrada y salida atascada del primero y deje que el padre recoja al segundo, pues ninguno de los dos estados atiende señales.✓ Respuesta
    • C.Suba la prioridad de ambos con renice para que el planificador pueda terminarlos y liberar así los recursos que todavía mantienen ocupados.
    • D.Reinicie el host, porque un proceso en cualquiera de esos estados ha filtrado memoria del kernel que no se recupera con el sistema en marcha.

    Un proceso en estado D está bloqueado dentro del kernel en una operación que no puede interrumpirse, así que no se le entrega ninguna señal hasta que esa entrada o salida termine o falle, y lo que hay que arreglar es el dispositivo, el sistema de archivos o la ruta de red que espera. Un zombi ya terminó y no retiene más que su entrada en la tabla de procesos, que desaparece cuando su padre llama a wait, de modo que actuar sobre el padre lo limpia y señalar al zombi no sirve de nada.

    Ref. QB-VF8NBTFuente: ps(1) process state codes and proc(5); CompTIA Linux+ exam objectives, process states including blocked and zombie, and signal handlingReportar un problema con esta pregunta

20. 20. Una aplicación web en un servidor Linux empieza a rechazar conexiones nuevas bajo carga y su registro se llena de 'accept: Too many open files'. El host tiene procesadores ociosos y varios gigabytes de memoria disponible. ¿Cuál es la causa y cómo se confirma?

    • A.El proceso alcanzó su límite de archivos abiertos: cuente con lsof los descriptores que mantiene y compárelos con /proc/<PID>/limits.✓ Respuesta
    • B.El rango de puertos de salida está agotado: no puede asignarse ningún socket nuevo, lo que se comprueba con sysctl en ip_local_port_range.
    • C.La cola de escucha es corta para el ritmo de llegada: las conexiones se pierden en la capa de socket, lo que sysctl muestra en somaxconn.
    • D.El sistema de archivos agotó los inodos: queda espacio pero no puede crearse ningún archivo nuevo, algo que df -i confirma en cada montaje.

    'Too many open files' es el error que recibe un proceso al alcanzar su número máximo de descriptores de archivo abiertos, y cada socket aceptado consume un descriptor igual que un archivo abierto, así que un servidor ocupado puede agotar ese techo mientras la máquina tiene procesador y memoria de sobra. Contar los descriptores del proceso y leer los límites registrados para él lo confirma, y el techo se sube para el servicio, no para un intérprete interactivo.

    Ref. QB-DWFNWTFuente: RLIMIT_NOFILE as described in proc(5) and the POSIX shell ulimit specification; CompTIA Linux+ exam objectives, process limitsReportar un problema con esta pregunta

21. 21. Un usuario solo informa de que 'el servidor va lento'. El host Linux ejecuta varias aplicaciones y ninguna alerta de supervisión se ha disparado. ¿Qué enfoque sigue el orden de resolución de problemas aceptado?

    • A.Determine qué recurso está limitado, atribuya esa limitación a un proceso concreto y luego cambie una sola cosa y verifique el efecto.✓ Respuesta
    • B.Reinicie primero la aplicación más grande, ya que un reinicio limpia la memoria filtrada y las conexiones viejas antes que cualquier medición.
    • C.Ajuste primero las prioridades de planificación de los procesos más activos y observe después si la queja desaparece con el cambio aplicado.
    • D.Capture primero el tráfico de la interfaz, porque la lentitud que los usuarios notan suele ser un problema de red antes que del propio host.

    La resolución de problemas estrecha el síntoma paso a paso: una queja tan vaga como 'lento' debe atribuirse primero a un recurso —procesador, memoria, almacenamiento o red— con los contadores del propio sistema, y solo después al proceso que lo consume. Actuar antes de medir, reiniciando o cambiando prioridades, destruye la evidencia y puede enmascarar la causa, y cambiar una sola variable es lo que permite atribuir la mejora al verificar.

    Ref. QB-VDAGBTFuente: CompTIA Linux+ exam objectives, Troubleshooting domain — analyzing performance issues, and the methodology of identifying the problem, testing one change and verifying the resultReportar un problema con esta pregunta

22. 22. Los usuarios informan de que un servidor Linux no respondió durante unos diez minutos por la noche. Por la mañana funciona con normalidad y las herramientas en vivo no muestran nada raro. ¿Qué enfoque recupera evidencia útil sobre el suceso?

    • A.Ejecute ahora top y los contadores por proceso, porque los valores máximos que muestran se acumulan desde el arranque y describen el episodio nocturno.
    • B.Relea los mensajes del kernel y de las unidades de esa franja exacta con journalctl --since y --until, tras confirmar que el journal se guarda de forma persistente.✓ Respuesta
    • C.Reproduzca el bloqueo cargando el host durante el día, ya que observar los recursos en vivo es la única forma de atribuir un problema ya terminado.
    • D.Revise el historial de shell y la tabla de procesos, porque lo que causó el bloqueo seguirá presente esta mañana con el mismo identificador de proceso.

    La evidencia de un suceso ya terminado solo puede venir de algo que lo registrara mientras ocurría. El journal guarda mensajes del kernel y de las unidades con marca de tiempo y admite consultas por cualquier franja con --since y --until, pero solo si está configurado para persistir entre reinicios en vez de vivir en memoria, y por eso confirmar la persistencia forma parte de la respuesta; las herramientas en vivo describen el presente y no se rebobinan.

    Ref. QB-CW4BRSFuente: journalctl(1) and journald.conf(5) documentation on time filtering and persistent storage; CompTIA Linux+ exam objectives, Troubleshooting domain — monitoring, logging and log correlationReportar un problema con esta pregunta

23. 23. A un administrador le preguntan si un 85 por ciento de utilización del procesador y una carga media de 6 en un host de lotes de ocho núcleos representan un problema. ¿Qué consideración resuelve la pregunta?

    • A.Todo host por encima del 80 por ciento de utilización está sobrecargado, así que estas cifras son un problema al margen de lo que deba hacer el host.
    • B.Una línea base tomada cuando el host estaba sano indica si estas cifras son normales para esta carga, y eso vuelve anómala una lectura.✓ Respuesta
    • C.Una carga media por debajo del número de núcleos siempre es segura, así que las cifras pueden descartarse sin mirar lo que este host informa.
    • D.Las cifras del procesador no significan nada hasta que memoria y disco estén en calma, así que no cabe concluir nada con otro recurso en uso.

    Una lectura aislada no es evidencia por sí sola: la misma utilización puede ser sana en un host de lotes pensado para exprimir sus procesadores y alarmante en un servicio sensible a la latencia, y la carga media además debe leerse frente al número de núcleos. Una línea base tomada con el sistema en buen estado aporta la comparación que convierte un número en una señal, y los umbrales y avisos solo valen si se derivan de ella.

    Ref. QB-UDX56SFuente: CompTIA Linux+ exam objectives, Troubleshooting domain — monitoring concepts including baselines, thresholds and alerts (exceeding baselines)Reportar un problema con esta pregunta

Preguntas de práctica redactadas según los objetivos publicados del examen CompTIA Linux+ y la práctica estándar de administración de Linux. CompTIA y Linux+ son marcas de CompTIA, y Linux es una marca registrada de Linus Torvalds; este sitio no está afiliado ni respaldado por CompTIA. El examen real combina preguntas de opción múltiple con preguntas basadas en desempeño que piden ejecutar una tarea en un entorno simulado: eso no puede reproducirse en un formato de cuatro opciones, así que este banco cubre la mitad teórica y conviene practicar en un sistema real en paralelo. CompTIA revisa y numera las versiones de los objetivos periódicamente: confirma los objetivos, el código de examen y los requisitos vigentes con CompTIA antes de examinarte. Sobre la certificación CompTIA Linux+ →