98 Preguntas y Respuestas para la Entrevista sobre Solución de Problemas en Linux

Las habilidades en Linux tienen una gran demanda, lo que convierte a los profesionales de Linux en activos valiosos en el panorama de TI actual; las empresas quieren asegurarse de contratar a los mejores. Asegurar que los candidatos posean las habilidades de resolución de problemas adecuadas es tan importante como verificar su comprensión de los conceptos de Linux, al igual que cualquier otra habilidad.

Esta publicación de blog ofrece una lista categorizada de preguntas de entrevista sobre resolución de problemas de Linux, diseñadas para evaluar a los candidatos en diferentes niveles de experiencia, desde básico hasta experto; también incluimos un conjunto de preguntas de opción múltiple (MCQ) para evaluaciones rápidas.

Al usar estas preguntas, puede medir mejor las capacidades de resolución de problemas y administración de sistemas de un candidato y, antes de eso, puede usar la prueba en línea de Linux de Adaface para evaluar más rápido.

Tabla de contenido

Preguntas de entrevista básicas sobre resolución de problemas de Linux

Preguntas de entrevista intermedias sobre resolución de problemas de Linux

Preguntas de entrevista avanzadas sobre resolución de problemas de Linux

Preguntas de entrevista de expertos en resolución de problemas de Linux

MCQ de resolución de problemas de Linux

¿Qué habilidades de resolución de problemas de Linux debe evaluar durante la fase de la entrevista?

Optimice la adquisición de talento para la resolución de problemas de Linux con pruebas de habilidades

Descargue la plantilla de preguntas de entrevista sobre resolución de problemas de Linux en múltiples formatos

Preguntas de entrevista básicas sobre resolución de problemas de Linux

1. Si un programa se ejecuta lentamente, ¿cómo investigaría la causa?

Para investigar un programa que se ejecuta lentamente, comenzaría recopilando datos. Usaría herramientas de perfilado (como perf en Linux o los perfiladores integrados en lenguajes como Python o Java) para identificar los puntos críticos: funciones o bloques de código que consumen la mayor cantidad de tiempo de CPU. Alternativamente, podría examinar la utilización de los recursos del sistema (CPU, memoria, E/S de disco, E/S de red) usando herramientas como top, htop o iostat para ver si hay un cuello de botella fuera del código del programa en sí. La depuración también puede ayudar al inspeccionar el estado de las variables y las estructuras de datos en tiempo de ejecución para descubrir ineficiencias en los algoritmos o el manejo de datos.

Luego, analizaría los datos recopilados. Si el perfilado apunta a código específico, examinaría la complejidad del algoritmo, consideraría optimizar las estructuras de datos o refactorizar el código ineficiente. Si la utilización de recursos es alta, investigaría la fuente de la carga y optimizaría en consecuencia (por ejemplo, reducir el consumo de memoria, optimizar las consultas de la base de datos o mejorar la comunicación de la red). Por ejemplo, optimizar las consultas de la base de datos con EXPLAIN o reescribir bucles ineficientes pueden ser soluciones. Comprender el diseño del sistema y la carga de trabajo prevista es importante para identificar las ineficiencias.

2. ¿Cómo se comprueba la cantidad de espacio libre en disco en un sistema Linux?

Para comprobar la cantidad de espacio libre en disco en un sistema Linux, se puede usar el comando df. El comando df muestra información sobre el uso del espacio en disco. Un uso común es df -h, que muestra el espacio en disco en un formato legible por humanos (por ejemplo, KB, MB, GB).

Alternativamente, el comando du se puede usar para estimar el uso del espacio de los archivos. Por ejemplo, du -sh mostrará el uso total del disco del directorio actual en formato legible por humanos. Para ver el uso del disco de un directorio específico: du -sh /ruta/al/directorio.

3. Explica cómo encontrar un archivo específico en todo el sistema cuando no conoces su ubicación exacta.

Para encontrar un archivo cuando no conoces su ubicación exacta, puedes usar el comando find en sistemas tipo Unix. La sintaxis básica es find / -name "nombre_del_archivo". Este comando comienza a buscar desde el directorio raíz (/) y busca archivos o directorios que coincidan con "nombre_del_archivo". Reemplaza "nombre_del_archivo" con el nombre real (o un patrón usando comodines como *) que estás buscando. Por ejemplo, find / -name "*.txt" encontraría todos los archivos .txt. Ten en cuenta que buscar desde la raíz puede llevar mucho tiempo, por lo que reducir la ruta de búsqueda (por ejemplo, find /home -name "*.txt") mejorará significativamente la velocidad.

Alternativamente, el comando locate puede ser más rápido, pero se basa en una base de datos preconstruida. Antes de usar locate, actualice la base de datos con updatedb. Luego, locate nombre_de_archivo buscará rápidamente en la base de datos los nombres de archivo coincidentes. Tenga en cuenta que locate podría no reflejar los cambios más recientes en el sistema de archivos hasta que la base de datos se actualice nuevamente. Además, use find si tiene problemas de permisos, ya que la base de datos de locate puede contener entradas para las que no tiene permisos.

4. ¿Qué comando usaría para mostrar el contenido de un archivo de texto?

Para mostrar el contenido de un archivo de texto, normalmente usaría el comando cat.

Por ejemplo, para ver el contenido de un archivo llamado mi_archivo.txt, usaría el siguiente comando:

cat mi_archivo.txt

Otros comandos como less y more también se pueden usar, especialmente para archivos grandes, ya que permiten desplazarse y paginar por el contenido.

5. ¿Cómo puede determinar la dirección IP de su máquina Linux?

Puede determinar la dirección IP de su máquina Linux usando varios comandos. Los más comunes son:

• ip addr o ip a: Este comando muestra información detallada de la interfaz de red, incluidas las direcciones IP.
• ifconfig: (Puede que no esté instalado de forma predeterminada en los sistemas más nuevos) Muestra información sobre las interfaces de red. Busque el campo inet para encontrar la dirección IP.
• hostname -I: (I mayúscula) Imprime la(s) dirección(es) IP de las interfaces de la máquina en una sola línea, separadas por espacios.

6. ¿Cuál es el propósito del comando 'ping' y cómo se usa?

El comando ping es una utilidad de red utilizada para probar la accesibilidad de un host en una red de Protocolo de Internet (IP). Funciona enviando paquetes de solicitud de eco del Protocolo de mensajes de control de Internet (ICMP) al host de destino y escuchando los paquetes de respuesta de eco ICMP. Esencialmente, verifica si un host está en línea y responde.

Para usar ping, simplemente escribe ping seguido del nombre de host o la dirección IP del objetivo. Por ejemplo, ping google.com o ping 8.8.8.8. La salida muestra el tiempo de ida y vuelta para cada paquete, lo que indica la latencia de la red. Un ping exitoso indica conectividad de red al objetivo, mientras que un ping fallido sugiere un problema de red, como que el host esté inactivo, congestión de la red o problemas de firewall.

7. Describe cómo verificar qué procesos se están ejecutando actualmente en tu sistema.

Para verificar qué procesos se están ejecutando actualmente en un sistema, puedes usar diferentes comandos según el sistema operativo. En Linux y macOS, el comando ps se usa comúnmente. Por ejemplo, ps aux muestra una lista completa de procesos con detalles como usuario, PID, uso de CPU y uso de memoria. Otro comando es top, que proporciona una vista dinámica y en tiempo real de los procesos en ejecución, ordenados por uso de CPU de forma predeterminada.

En Windows, puedes usar el comando tasklist en el símbolo del sistema. Muestra una lista de los procesos que se están ejecutando actualmente, incluido su PID y uso de memoria. Alternativamente, el Administrador de tareas (accesible presionando Ctrl+Shift+Esc) proporciona una interfaz gráfica para ver y administrar los procesos en ejecución.

8. Si un programa no responde, ¿qué medidas puedes tomar para detenerlo?

Si un programa no responde, el primer paso suele ser intentar cerrarlo de forma correcta. Esto a menudo se puede hacer haciendo clic en el botón 'X' o seleccionando 'Archivo' -> 'Salir' del menú de la aplicación. Dale a la aplicación una cantidad razonable de tiempo para responder antes de asumir que realmente está congelada.

Si la aplicación permanece sin responder, el siguiente paso es forzar su cierre. En Windows, esto se hace a través del Administrador de tareas (Ctrl+Shift+Esc), seleccionando el programa que no responde en la pestaña 'Procesos' o 'Detalles', y haciendo clic en 'Finalizar tarea'. En macOS, puedes usar el Monitor de Actividad (en Aplicaciones/Utilidades) o la ventana Forzar salida de aplicaciones (Comando+Opción+Esc) para seleccionar la aplicación y forzar su cierre. En Linux, puedes usar el comando kill en la terminal, identificando el ID del proceso (PID) usando ps o top y luego ejecutando kill <PID> o, si es necesario, kill -9 <PID> para finalizar el proceso a la fuerza (aunque usar kill -9 debería ser el último recurso ya que no permite que el programa se limpie).

9. ¿Cómo se cambian los permisos de un archivo o directorio?

Para cambiar los permisos de un archivo o directorio en un sistema operativo tipo Unix (como Linux o macOS), normalmente se usa el comando chmod. chmod modifica los permisos de los archivos usando modos simbólicos o numéricos (octales). Por ejemplo, chmod u+x myfile.txt añade permiso de ejecución para el usuario que posee el archivo, mientras que chmod 755 midirectorio establece permisos de lectura, escritura y ejecución para el propietario, y permisos de lectura y ejecución para el grupo y otros.

El comando chown también se puede usar para cambiar la propiedad de archivos/directorios.

10. ¿Cuál es la diferencia entre los comandos 'sudo' y 'su'?

El comando su (substitute user, sustituir usuario) cambia la identidad del usuario del shell actual. Por defecto, intenta convertirse en el usuario root, pero se puede especificar otro usuario. Requiere la contraseña del usuario objetivo. Cuando se usa sin un nombre de usuario, su cambia el entorno al del usuario objetivo; esto incluye establecer variables de entorno según su perfil. Se utiliza principalmente para convertirse en otro usuario.

sudo (substitute user do, hacer como otro usuario) ejecuta un solo comando como otro usuario (típicamente root) pero sin cambiar la identidad del usuario del shell. Utiliza la contraseña del usuario invocador (o ninguna contraseña, dependiendo de la configuración de sudo) para autenticarse. sudo se usa comúnmente para otorgar privilegios administrativos limitados a los usuarios sin darles acceso root. Permite a los usuarios ejecutar comandos específicos como root u otro usuario, basándose en las reglas definidas en el archivo /etc/sudoers.

11. Explique cómo crear un nuevo directorio en Linux.

Para crear un nuevo directorio en Linux, usa el comando mkdir seguido del nombre del directorio que deseas crear. Por ejemplo, mkdir mi_nuevo_directorio creará un directorio llamado mi_nuevo_directorio en tu directorio de trabajo actual.

También puedes crear múltiples directorios a la vez usando mkdir dir1 dir2 dir3. Si necesitas crear directorios anidados (por ejemplo, padre/hijo) y el directorio padre no existe, puedes usar la opción -p: mkdir -p padre/hijo. Esto creará tanto el directorio padre como el directorio hijo.

12. ¿Cómo puedes copiar un archivo de un directorio a otro?

Puedes copiar un archivo de un directorio a otro utilizando herramientas de línea de comandos o lenguajes de programación.

Para la línea de comandos, puedes usar cp en Linux/macOS o copy en Windows. Por ejemplo, en Linux/macOS, cp /ruta/al/origen/archivo.txt /ruta/al/destino/. En Python, puedes usar el módulo shutil: import shutil; shutil.copy('/ruta/al/origen/archivo.txt', '/ruta/al/destino/'). Recuerda manejar las posibles excepciones como FileNotFoundError.

13. ¿Qué comando se usa para mover o renombrar archivos y directorios?

El comando mv se usa para mover o renombrar archivos y directorios.

Por ejemplo, mv archivo1.txt archivo2.txt renombra archivo1.txt a archivo2.txt. mv archivo.txt /ruta/al/nuevo/directorio/ mueve archivo.txt al directorio especificado.

14. ¿Cómo se elimina un archivo o directorio desde la línea de comandos?

Para eliminar un archivo desde la línea de comandos, puedes usar el comando rm. Por ejemplo, rm nombre_de_archivo eliminará el archivo llamado 'nombre_de_archivo'. Para eliminar un directorio, normalmente necesitas usar la opción -r o -rf con el comando rm. La opción -r significa recursivo, lo que significa que eliminará el directorio y todo su contenido. La opción -f significa forzar, lo que suprimirá cualquier aviso o error. Por ejemplo, rm -rf nombre_de_directorio eliminará forzadamente el directorio llamado 'nombre_de_directorio' y todo lo que contiene. Usa rm -rf con precaución, ya que puede eliminar datos de forma permanente.

15. Describe cómo ver las últimas líneas de un archivo de registro.

Para ver las últimas líneas de un archivo de registro, puedes usar el comando tail en la mayoría de los sistemas operativos tipo Unix (Linux, macOS, etc.). De forma predeterminada, tail muestra las últimas 10 líneas de un archivo.

Para ver un número específico de líneas (por ejemplo, las últimas 20 líneas), usa la opción -n: tail -n 20 nombre_de_archivo.log. Si deseas seguir el archivo de registro a medida que se escribe en él, usa la opción -f: tail -f nombre_de_archivo.log. Esto mostrará continuamente las nuevas líneas a medida que se agregan al archivo.

16. Explica cómo redirigir la salida de un comando a un archivo.

Para redirigir la salida de un comando a un archivo en un entorno tipo Unix (Linux, macOS), puedes usar los operadores de redirección. El operador más común es > que sobrescribe el archivo si existe o lo crea si no existe. Por ejemplo, ls -l > archivo.txt redirige la salida del comando ls -l a un archivo llamado archivo.txt.

Si deseas agregar la salida a un archivo existente, puedes usar el operador >>. Por ejemplo, echo "Hola" >> archivo.txt agrega la cadena "Hola" a archivo.txt. También puedes redirigir el error estándar usando 2> (por ejemplo, comando 2> error.log) y tanto la salida estándar como el error estándar usando &> o 2>&1 (por ejemplo, comando &> salida.log o comando > salida.log 2>&1).

17. ¿Cómo buscas una cadena de texto específica dentro de un archivo?

La forma más común de buscar una cadena de texto específica dentro de un archivo es usando herramientas de línea de comandos como grep (en sistemas tipo Unix) o findstr (en Windows). Por ejemplo, en grep, usarías grep "tu_cadena" nombre_archivo.txt. Similarmente en findstr es findstr "tu_cadena" nombre_archivo.txt. Estos comandos buscan líneas que contienen la cadena especificada e imprimen esas líneas en la consola.

Alternativamente, editores de texto como VS Code, Sublime Text o Notepad++ ofrecen potentes funcionalidades de búsqueda utilizando Ctrl+F (o Cmd+F en macOS). Estos editores permiten buscar con opciones como insensibilidad a mayúsculas y minúsculas, coincidencia de palabras completas y expresiones regulares. Los lenguajes de programación también ofrecen capacidades de lectura de archivos y búsqueda de cadenas, por ejemplo, en Python: with open("nombre_archivo.txt", "r") as file: for line in file: if "tu_cadena" in line: print(line).

18. ¿Cuál es el propósito del comando 'chmod' y cómo funciona?

El comando chmod se utiliza para cambiar los permisos de archivos o directorios en sistemas operativos tipo Unix. Controla quién puede leer, escribir y ejecutar un archivo. Los permisos se definen para tres clases de usuarios: el propietario del archivo, el grupo asociado al archivo y otros (todos los demás usuarios).

chmod funciona modificando los bits de modo del archivo. Estos bits representan los permisos de lectura (r), escritura (w) y ejecución (x) para cada clase de usuario. Se puede usar de dos maneras: modo simbólico (por ejemplo, chmod u+x file.txt agrega permiso de ejecución para el propietario) o modo octal (por ejemplo, chmod 755 file.txt establece lectura/escritura/ejecución para el propietario, y lectura/ejecución para el grupo y otros). El modo simbólico es a menudo más fácil de entender, mientras que el modo octal es más conciso para establecer múltiples permisos simultáneamente.

19. ¿Cómo se puede saber qué usuario está actualmente conectado?

El método para determinar el usuario actualmente conectado depende del contexto (sistema operativo, marco de aplicación, etc.).

• Sistema operativo (Linux/Unix): Use el comando whoami en la terminal. Alternativamente, examine variables de entorno como $USER o $LOGNAME.
• Sistema operativo (Windows): Use el comando echo %USERNAME% en el símbolo del sistema, o examine la variable de entorno USERNAME.
• Aplicación web (Python/Flask): Acceda al objeto de usuario desde la sesión, por ejemplo, session['user'] (suponiendo que los datos del usuario se almacenan en la sesión al iniciar sesión).
• Aplicación web (JavaScript/Navegador): Confíe en la lógica del lado del servidor para exponer la información del usuario, a menudo almacenada en una cookie o sesión. Luego se puede acceder a estos datos usando document.cookie o haciendo una llamada a la API para recuperar la información del usuario.

20. Explica cómo listar todos los archivos y directorios en el directorio actual, incluyendo los ocultos.

Para listar todos los archivos y directorios (incluyendo los ocultos) en el directorio actual, puedes usar el comando ls con la opción -a en sistemas tipo Unix (Linux, macOS).

ls -a

La opción -a le indica a ls que incluya todas las entradas, incluso aquellas que comienzan con un . (punto), que normalmente están ocultas. La salida mostrará entonces todos los archivos y directorios en la ubicación actual.

21. Si tu conexión a internet no funciona, ¿cuáles son algunos pasos básicos de solución de problemas que tomarías en Linux?

Primero, verificaría la conexión física: asegurándome de que el cable Ethernet esté correctamente conectado o que el Wi-Fi esté habilitado. Luego, usaría el comando ping para verificar la conectividad con la puerta de enlace o un servidor DNS público (por ejemplo, ping 8.8.8.8). Si ping a la puerta de enlace falla, el problema probablemente es local; si tiene éxito, el problema probablemente está más arriba en la cadena. También verificaría la configuración de red usando ip addr para ver si se ha asignado una dirección IP. Si se usa DHCP, reiniciar la interfaz de red con sudo ifdown <interfaz> seguido de sudo ifup <interfaz> puede ayudar. Finalmente, verificar el estado del administrador de red (systemctl status NetworkManager) puede revelar problemas con el servicio de red en sí.

22. ¿Cómo se puede determinar la cantidad de RAM instalada en un sistema Linux?

Puede determinar la cantidad de RAM instalada en un sistema Linux utilizando varios comandos. El más común y fácil de recordar es free -h. Este comando muestra la cantidad total, utilizada y libre de RAM en un formato legible por humanos (por ejemplo, GB, MB). Otro comando es cat /proc/meminfo. Este comando muestra mucha más información detallada sobre el uso de la memoria, incluyendo MemTotal, que representa la RAM total instalada. También puede utilizar vmstat -s para obtener un resumen de varias estadísticas del sistema, incluida la memoria total.

23. ¿Qué comando se utiliza para apagar o reiniciar un sistema Linux desde la línea de comandos?

Para apagar un sistema Linux desde la línea de comandos, puede utilizar el comando shutdown. Por ejemplo, sudo shutdown now iniciará un apagado inmediato. Para reiniciar, puede usar sudo reboot o sudo shutdown -r now. El comando shutdown con la opción -r es otra forma de reiniciar.

Alternativamente, podrías usar systemctl poweroff para apagar o systemctl reboot para reiniciar el sistema. Estos comandos interactúan con systemd, el gestor del sistema y de servicios para Linux, y generalmente son preferidos en sistemas que usan systemd.

24. Explica cómo comprimir un archivo o directorio usando el comando 'tar'.

Para comprimir un archivo o directorio usando el comando tar, normalmente lo combinas con un algoritmo de compresión como gzip o bzip2. Por ejemplo, para crear un archivo tar comprimido con gzip, puedes usar las opciones -czvf: tar -czvf nombre_del_archivo.tar.gz directorio_o_archivo. Este comando crea un archivo llamado nombre_del_archivo.tar.gz del directorio_o_archivo especificado usando la compresión gzip.

Para la compresión bzip2, usa -cjvf: tar -cjvf nombre_del_archivo.tar.bz2 directorio_o_archivo. Aquí, c crea, z usa gzip, j usa bzip2, v es verbose (muestra los archivos que se están procesando) y f especifica el nombre del archivo archivado. Recuerda reemplazar nombre_del_archivo, directorio_o_archivo con el nombre deseado para el archivo y la ruta a lo que quieres comprimir. Para la compresión de directorios, asegúrate de usar una barra diagonal después del nombre del directorio.

25. ¿Cómo se extraen archivos de un archivo '.tar.gz'?

Para extraer archivos de un archivo .tar.gz, puede usar el comando tar con las siguientes opciones:

tar -xzfv nombre_archivo.tar.gz

Donde:

• -x significa extraer.
• -z indica que el archivo está comprimido con gzip.
• -v significa detallado, enumerando los archivos que se están extrayendo.
• -f especifica el nombre del archivo.

26. Si accidentalmente elimina un archivo, ¿qué pasos podría seguir para intentar recuperarlo?

Si accidentalmente elimino un archivo, lo primero que haría es revisar la Papelera de reciclaje (Windows) o la Papelera (macOS/Linux). Los archivos eliminados a menudo se mueven allí en lugar de eliminarse permanentemente. Si el archivo se encuentra allí, simplemente lo restauraría.

Si el archivo no está en la Papelera de reciclaje/Papelera, o si la vacié recientemente, consideraría usar un software de recuperación de datos. Estas herramientas escanean el disco duro en busca de archivos eliminados e intentan recuperarlos. Algunas opciones populares incluyen Recuva (Windows) o TestDisk (multiplataforma). Es importante dejar de usar la unidad tanto como sea posible después de darse cuenta de que el archivo se eliminó para evitar que se sobrescriba. Finalmente, si se implementó una solución de copia de seguridad como Time Machine (macOS) o un servicio de copia de seguridad en la nube, restauraría el archivo de la última copia de seguridad.

Preguntas de la entrevista de solución de problemas de Linux intermedias

1. ¿Cómo diagnosticaría una situación en la que una aplicación específica está consumiendo recursos de CPU excesivos en un servidor Linux?

Primero, usaría top o htop para identificar el proceso que consume más CPU. top proporciona una vista en tiempo real de los procesos del sistema. Si es realmente la aplicación en cuestión, luego usaría pidstat -p <process_id> 1 para obtener un desglose más detallado del uso de la CPU a lo largo del tiempo. A continuación, intentaría identificar los hilos específicos que están causando el alto uso de la CPU mediante ps -Lp <process_id> -o pid,tid,%cpu,%mem,cmd. Esto proporcionará una lista de hilos junto con el uso de CPU y memoria. Después de identificar el hilo problemático, usaría jstack <process_id> (si es una aplicación Java) o gdb -p <process_id> (para aplicaciones nativas) para obtener rastros de la pila e identificar las secciones de código que se están ejecutando activamente. Analizar los rastros de la pila debería revelar la causa raíz, como un bucle ajustado, un algoritmo ineficiente o una operación de E/S bloqueante. También buscaría en los registros de la aplicación errores o advertencias potenciales que pudieran explicar el alto uso de la CPU. Finalmente, verificaría si hay tareas programadas o trabajos cron que estén relacionados con la aplicación, o cualquier factor externo como solicitudes de red, que podrían contribuir al problema.

2. Describa los pasos que tomaría para solucionar un problema de conectividad de red donde un servidor Linux no puede acceder a un sitio web externo.

Primero, verificaría la configuración básica de la red en el servidor Linux usando comandos como ip addr, route -n y cat /etc/resolv.conf para comprobar la dirección IP, la puerta de enlace y la configuración de DNS. Después, usaría ping para probar la conectividad con la puerta de enlace y los servidores DNS externos (por ejemplo, 8.8.8.8). Si falla el ping a la puerta de enlace, el problema probablemente está en la red local o en la configuración del servidor. Si el ping a la puerta de enlace es exitoso pero el ping a 8.8.8.8 falla, el problema podría estar en la resolución de DNS o en un cortafuegos que bloquea el tráfico saliente. Luego usaría traceroute o tracepath para identificar dónde falla la conexión a lo largo de la ruta al sitio web externo. Finalmente, usaría nslookup o dig para consultar el servidor DNS y asegurarme de que el sitio web externo se resuelva a una dirección IP válida. Si la resolución de DNS es exitosa y el traceroute identifica un cortafuegos, revisaría las reglas del cortafuegos en el servidor y cualquier cortafuegos de red para asegurar que el tráfico saliente en el puerto 80/443 esté permitido. También usaría tcpdump o wireshark para capturar el tráfico de red en el servidor y analizar los paquetes enviados y recibidos para aislar aún más el problema.

3. Explique cómo identificaría y resolvería una situación en la que un servidor Linux se está quedando sin espacio en disco.

Primero, usaría df -h para identificar qué particiones están cerca de su capacidad máxima. Luego, du -hsx /* | sort -rh | head -10 ayudaría a identificar los directorios más grandes que consumen espacio dentro de la partición problemática. A partir de ahí, investigaría esos directorios para determinar la causa: podrían ser registros excesivos, archivos temporales grandes o datos de usuario inesperadamente grandes. Una vez identificado, tomaría las medidas adecuadas, como eliminar archivos innecesarios, comprimir registros, mover datos a otra ubicación de almacenamiento o aumentar el tamaño de la partición si es factible.

Para evitar que esto vuelva a ocurrir, implementaría la supervisión y las alertas para el uso del espacio en disco. Se pueden usar herramientas como Nagios, Zabbix o incluso scripts de shell simples con trabajos cron para activar alertas cuando el espacio en disco alcance un umbral predefinido. Las políticas de rotación de registros también deben configurarse adecuadamente para evitar el crecimiento excesivo de los archivos de registro.

4. Guíeme a través del proceso de diagnóstico de una consulta de base de datos de bajo rendimiento en un servidor Linux que aloja una base de datos.

Diagnosticar una consulta de base de datos lenta implica un enfoque sistemático. Primero, identifique la consulta lenta. Use herramientas específicas de la base de datos, como los registros de consultas lentas (slow_query_log en MySQL, auto_explain en PostgreSQL) o herramientas de monitoreo de rendimiento para identificar la consulta problemática. Una vez identificada, use el comando EXPLAIN de la base de datos (por ejemplo, EXPLAIN SELECT ... en MySQL/PostgreSQL) para comprender el plan de ejecución de la consulta. Esto revela cómo la base de datos está accediendo a las tablas, usando índices y realizando uniones. Busque exploraciones completas de tablas, índices faltantes o estrategias de unión ineficientes.

A continuación, analiza el propio servidor Linux. Utiliza herramientas como top, htop, iostat y vmstat para monitorizar el uso de la CPU, la utilización de la memoria, la E/S del disco y la actividad de la red. Un uso elevado de la CPU podría indicar un procesamiento ineficiente de las consultas, mientras que una E/S de disco alta podría apuntar a una recuperación lenta de los datos. La memoria insuficiente puede provocar intercambio (swapping), lo que ralentiza aún más el rendimiento. Examina la latencia de la red entre el servidor de aplicaciones y el servidor de la base de datos, ya que los problemas de red pueden manifestarse como una lentitud percibida de la base de datos. Basándote en estas observaciones, optimiza la consulta (por ejemplo, añade índices, reescribe la consulta), ajusta los parámetros de configuración de la base de datos (por ejemplo, shared_buffers en PostgreSQL) o actualiza los recursos del servidor (CPU, memoria, disco).

5. ¿Cómo solucionarías un escenario en el que un usuario no puede iniciar sesión en un servidor Linux utilizando SSH?

En primer lugar, verifica la conectividad básica utilizando ping <server_ip>. Si el ping falla, soluciona los problemas de red (firewall, enrutamiento, DNS). Si el ping tiene éxito, comprueba el estado del servidor SSH utilizando systemctl status sshd (o el comando apropiado para tu distribución). Busca errores en los registros (/var/log/auth.log o /var/log/secure) que puedan indicar fallos de autenticación, como contraseñas incorrectas, problemas de claves o bloqueos de cuentas. Asegúrate de que el usuario existe localmente o a través de la autenticación configurada (por ejemplo, LDAP).

6. Describe los pasos que tomaría para identificar y solucionar un problema donde un servicio crítico del sistema no se inicia automáticamente al arrancar.

Primero, revisaría los registros del sistema (usando herramientas como journalctl en Linux o el Visor de eventos en Windows) en busca de mensajes de error relacionados con el servicio. Me centraría en los mensajes registrados en el momento en que el sistema arrancó. Estos registros pueden identificar la razón exacta de la falla, como dependencias faltantes, configuración incorrecta o problemas de permisos de archivos. También intentaría iniciar el servicio manualmente. Esta acción puede exponer mensajes de error que pueden no aparecer durante el proceso de arranque automático.

Luego, examinaría el archivo de configuración del servicio en busca de errores y verificaría que las dependencias del servicio estén correctamente instaladas y configuradas. También confirmaría que el servicio está habilitado para iniciarse al arrancar usando systemctl is-enabled <nombre-del-servicio> (en sistemas systemd) o herramientas similares. Si las dependencias son el problema, me aseguraría de que se inicien antes del servicio crítico. Después de implementar cualquier solución, reiniciaría el sistema para confirmar que el servicio se inicia automáticamente como se esperaba. Si el servicio aún falla, repetiré el proceso anterior, verificando si la solución aplicada desencadenó otros problemas.

7. Explique cómo diagnosticaría y resolvería una situación en la que un servidor Linux experimenta un alto uso de memoria.

Para diagnosticar un alto uso de memoria en un servidor Linux, comenzaría con free -m para obtener una vista general rápida de la memoria total, usada, libre, compartida, buff/cache y disponible. Luego, usaría top o htop para identificar los procesos que consumen la mayor cantidad de memoria, prestando mucha atención a las columnas RES (memoria residente) y VIRT (memoria virtual). También podría usar vmstat 1 para observar las estadísticas de memoria en tiempo real.

Una vez que haya identificado los procesos culpables, investigaría más a fondo. Si se trata de una aplicación Java, analizaría los volcados de heap. Para otros procesos, usaría pmap -x <pid> para examinar el mapa de memoria del proceso e identificar posibles fugas de memoria o un uso ineficiente de la misma. Las soluciones podrían variar desde reiniciar el servicio problemático, optimizar el código de la aplicación (por ejemplo, solucionar fugas de memoria), aumentar el espacio de intercambio (como medida temporal) o actualizar la RAM del servidor.

8. ¿Cómo solucionaría un escenario en el que un archivo se modifica o se elimina inesperadamente en un servidor Linux?

Para solucionar problemas de modificaciones o eliminaciones inesperadas de archivos en un servidor Linux, comenzaría por revisar los registros del sistema (/var/log/syslog, /var/log/auth.log, /var/log/audit/audit.log si auditd está habilitado) en busca de pistas sobre el usuario o proceso responsable. Utilizaría herramientas como auditd para monitorear los intentos de acceso, modificación y eliminación de archivos para los archivos/directorios afectados. Comandos como ls -l, stat y lsof pueden ayudar a determinar la última hora de modificación y cualquier manejador abierto en el archivo.

Además, investigaría los trabajos cron y las tareas programadas en busca de scripts o comandos inesperados que podrían estar modificando o eliminando el archivo. También se deben investigar los recursos compartidos de red y los sistemas de archivos montados de forma remota, ya que los cambios podrían originarse desde otro sistema. La realización de copias de seguridad periódicas de los archivos críticos puede mitigar la pérdida de datos durante la solución de problemas.

9. Describa los pasos que tomaría para diagnosticar un problema en el que un servidor Linux está experimentando cortes de red intermitentes.

Para diagnosticar interrupciones intermitentes de la red en un servidor Linux, comenzaría por recopilar información. Primero, revisaría los registros del sistema (/var/log/syslog, /var/log/kern.log, /var/log/messages) en busca de errores o advertencias relacionadas con la red alrededor del momento de las interrupciones. También usaría herramientas como ping y traceroute para probar la conectividad a recursos externos e identificar dónde falla la conexión. tcpdump o wireshark se pueden utilizar para capturar el tráfico de la red y analizar los paquetes en busca de anomalías.

Luego, examinaría la configuración de la red del servidor. Verificaría la configuración de la interfaz de red (ifconfig o ip addr), la tabla de enrutamiento (route -n) y la configuración de DNS (/etc/resolv.conf). También es crucial verificar el agotamiento de recursos (CPU, memoria, E/S de disco) utilizando herramientas como top, vmstat e iostat, ya que una alta carga a veces puede manifestarse como problemas de red. Revisaría las reglas del firewall (iptables -L o nft list ruleset) para asegurarme de que ninguna regla esté bloqueando el tráfico inesperadamente. Finalmente, analizaría los registros del conmutador y del enrutador para ver si hay problemas que afecten al servidor.

10. Explique cómo identificaría y resolvería una situación en la que un usuario en particular experimenta un rendimiento lento en un servidor Linux.

Para identificar y resolver el bajo rendimiento para un usuario específico en un servidor Linux, comenzaría por verificar la utilización de recursos. Usaría herramientas como top, htop o ps para monitorear el uso de CPU, memoria y E/S específicamente atribuido a los procesos de ese usuario. iotop podría ayudar a aislar cuellos de botella de E/S. Comandos como ps -u <nombre_usuario> -o %cpu,%mem,pid,comm muestran el consumo de recursos por un usuario específico. Si el agotamiento de recursos es el problema, investigaría qué procesos están consumiendo la mayor cantidad de recursos y consideraría opciones como optimizar la aplicación, limitar el uso de recursos (usando ulimit) o agregar más recursos al servidor.

Si los recursos no son el principal cuello de botella, investigaría la latencia de la red. ping y traceroute pueden ayudar a identificar problemas de red. También verificaría la E/S del disco usando iostat y buscaría signos de bajo rendimiento del disco o contención del disco. Si el usuario está accediendo a una base de datos, examinaría los registros de la base de datos y el rendimiento de las consultas. Otra cosa clave para verificar serían los procesos del usuario en busca de bloqueos, bucles infinitos o llamadas de bloqueo extensas. Finalmente, revisaría los registros de la aplicación relevantes para errores o advertencias específicos del usuario que podrían proporcionar pistas.

11. Explícame el proceso de diagnosticar una situación en la que un trabajo cron programado no se está ejecutando como se espera.

Cuando un trabajo cron falla, comienzo por verificar la configuración del trabajo cron usando crontab -l para asegurar que el programa sea correcto y el comando sea el esperado. Luego, reviso los registros del sistema (/var/log/syslog o /var/log/cron) para cualquier mensaje de error relacionado con el trabajo cron. Específicamente, busco mensajes que indiquen fallas, problemas de permisos o errores de comando no encontrado. Además, también verifico los permisos del script para asegurarme de que sea ejecutable.

A continuación, me aseguro de que el demonio cron se esté ejecutando con systemctl status cron. Si el demonio no se está ejecutando, lo iniciaré con systemctl start cron. También reviso el script en sí en busca de errores ejecutándolo manualmente como el usuario para el que está configurado el trabajo cron, para replicar el entorno cron. Me aseguro de que las variables de entorno necesarias estén configuradas correctamente dentro de la configuración de cron o del propio script, y considero redirigir la salida del script a un archivo para capturar cualquier error o salida para su examen utilizando > /ruta/al/archivo_log 2>&1 en el crontab.

12. ¿Cómo solucionaría un escenario en el que un servidor Linux no puede resolver nombres de dominio?

Primero, verificaría el archivo /etc/resolv.conf para asegurarme de que las entradas del servidor de nombres sean correctas y apunten a servidores DNS válidos. También usaría ping y traceroute para verificar la conectividad de red a esos servidores DNS. Luego, usaría nslookup o dig para consultar esos servidores de nombres directamente para un dominio conocido como google.com para aislar si el problema es específicamente con la resolución de DNS, y no un problema general de conectividad de red. También verificaría que el archivo /etc/nsswitch.conf tenga 'dns' listado para la resolución de nombres de host. Otra cosa que verificaría es que un resolvedor DNS local como systemd-resolved o dnsmasq esté correctamente configurado y en ejecución, si se pretende usar uno. Finalmente, revisaría las reglas del firewall para asegurarme de que el tráfico DNS (puerto 53, tanto TCP como UDP) no esté bloqueado.

13. Describe los pasos que tomaría para identificar y solucionar un problema donde una aplicación personalizada se bloquea frecuentemente en un servidor Linux.

Primero, recopilaría información. Revisaría los registros del sistema (/var/log/syslog, /var/log/messages, registros específicos de la aplicación) para buscar mensajes de error, seguimientos de pila y marcas de tiempo relacionadas con los bloqueos. También usaría herramientas como top, htop o vmstat para monitorear el uso de CPU, memoria y E/S, buscando picos o agotamiento de recursos que conduzcan al bloqueo. dmesg proporcionará información sobre posibles problemas a nivel de kernel. ulimit -a muestra los límites de recursos que podrían ser una causa raíz.

Luego, basándome en los registros y las métricas del sistema, intentaría determinar la causa. Si hay un seguimiento de la pila, lo analizaría para identificar el código problemático. Podría usar herramientas como gdb para adjuntarlo al proceso en ejecución y examinar su estado. Si parece un agotamiento de recursos, investigaría fugas de memoria o un uso ineficiente de recursos en el código de la aplicación. También revisaría los cambios de código recientes o las actualizaciones de la aplicación o del entorno del servidor, ya que a menudo son fuentes de nuevos problemas. Después de identificar la causa, implementaría una solución, la probaría a fondo en un entorno de prueba y luego la implementaría en producción mientras monitoreo el sistema para detectar cualquier fallo adicional.

14. Explique cómo diagnosticaría y resolvería una situación en la que un servidor Linux está experimentando un aumento repentino en la espera de E/S.

Para diagnosticar una alta espera de E/S en un servidor Linux, comenzaría usando top o htop para confirmar el alto porcentaje de wa (espera de E/S). Luego, iostat -xz 1 proporcionaría estadísticas detalladas de E/S por dispositivo, mostrando qué discos están experimentando una alta utilización, tiempos de espera y longitudes de cola. También verificaría vmstat 1 para comprender el uso de memoria y la actividad de paginación en todo el sistema, ya que el intercambio excesivo puede causar una alta E/S.

Para resolver el problema, las soluciones potenciales dependen de la causa raíz. Si un proceso específico está causando una alta E/S, investigaría y optimizaría sus operaciones de E/S. Esto podría implicar reducir la frecuencia o el tamaño de las escrituras, usar E/S asíncrona u optimizar las consultas de la base de datos. Si el disco en sí es el cuello de botella, consideraría actualizar a un almacenamiento más rápido (por ejemplo, SSD), agregar más RAM para reducir el intercambio o implementar mecanismos de almacenamiento en caché. Los problemas de E/S del sistema de archivos de red se pueden solucionar optimizando la conexión de red o actualizando el servidor NFS.

15. ¿Cómo solucionaría un escenario en el que un usuario informa que faltan sus archivos después de una actualización reciente del sistema?

Primero, recopilaría información: ¿Cuándo ocurrió la actualización? ¿Qué tipos de archivos faltan? ¿Hay otros usuarios afectados? ¿El usuario ha revisado la papelera de reciclaje? Luego, revisaría los registros de actualización del sistema en busca de errores o información de migración de archivos. Es posible que los archivos se hayan movido a un directorio diferente o se hayan renombrado durante el proceso de actualización. Es fundamental realizar una búsqueda en el sistema de archivos utilizando palabras clave relacionadas con los archivos faltantes. Si el servicio de copia de sombra de volumen (VSS) está habilitado, intentaría restaurar los archivos desde una versión anterior. Además, verificaría que el perfil del usuario no se haya dañado o que se haya cargado un perfil temporal.

Si los pasos simples fallan, es necesaria una inmersión más profunda. Comprobaría la integridad del disco usando chkdsk (Windows) o fsck (Linux/macOS). Revisar los registros del sistema en busca de errores del sistema de archivos también es clave. Es posible que el proceso de actualización haya provocado una falla de hardware o haya expuesto una vulnerabilidad existente. Considere examinar los registros de copia de seguridad para determinar si se puede restaurar una copia de seguridad reciente. En raras ocasiones, es posible que se necesite un software de recuperación de datos como último recurso. Siempre priorizaría la seguridad de los datos creando una imagen de disco antes de intentar cualquier procedimiento de recuperación potencialmente destructivo.

16. Describa los pasos que tomaría para diagnosticar un problema en el que un servidor Linux no puede autenticar a los usuarios contra un dominio de Active Directory.

Para diagnosticar fallos de autenticación de Active Directory en un servidor Linux, comenzaría por verificar la conectividad de red básica: asegurándome de que el servidor puede hacer ping a los controladores de dominio utilizando tanto la dirección IP como el nombre de host, y que la resolución DNS funciona correctamente. A continuación, comprobaría los archivos de configuración del servicio de autenticación que se utiliza (por ejemplo, sssd.conf para SSSD, krb5.conf para Kerberos). Buscaría específicamente errores en el nombre de dominio, el reino o las direcciones del servidor.

Luego examinaría los registros del sistema (/var/log/auth.log, /var/log/secure, /var/log/messages y registros específicos del servicio de autenticación) en busca de mensajes de error que indiquen la naturaleza del fallo. kinit se puede usar para Kerberos para recuperar un ticket y comprobar la configuración de kerberos. Las herramientas de depuración como tcpdump o wireshark para capturar el tráfico de red relacionado con la autenticación pueden proporcionar información más profunda. Por último, confirmaría que la hora del servidor Linux está sincronizada con los controladores de dominio de Active Directory utilizando NTP, ya que las discrepancias horarias pueden causar problemas de autenticación.

17. Explique cómo identificaría y resolvería una situación en la que un proceso particular consume un ancho de banda de red excesivo en un servidor Linux.

Para identificar el uso excesivo de ancho de banda de red por un proceso en un servidor Linux, comenzaría usando herramientas como iftop o nethogs para obtener una vista en tiempo real del tráfico de red e identificar los procesos que consumen la mayor cantidad de ancho de banda. tcpdump también se puede utilizar para capturar paquetes y analizar los patrones de tráfico si se necesita una investigación más profunda. Una vez identificado el proceso infractor, investigaría la configuración y los registros del proceso para comprender por qué está generando tanto tráfico.

Para resolver el problema, consideraría opciones como limitar la velocidad de uso de la red del proceso utilizando tc (control de tráfico), optimizar la configuración del proceso para reducir la actividad de red innecesaria o, como último recurso, terminar el proceso si no es crítico. Para problemas persistentes, revisar y potencialmente rediseñar los patrones de comunicación de red de la aplicación podría ser necesario. Por ejemplo: tc qdisc add dev eth0 root handle 1: htb default 10; tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit; tc class add dev eth0 parent 1:1 classid 1:10 htb rate 1mbit; tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 80 0xffff flowid 1:10

18. Guíeme por el proceso de diagnóstico de una situación en la que un sitio web alojado en un servidor Linux está experimentando tiempos de carga lentos.

Para diagnosticar los tiempos de carga lentos de un sitio web en un servidor Linux, comenzaría por verificar lo básico: el uso de recursos del servidor (CPU, memoria, E/S de disco) utilizando herramientas como top, htop, iostat y vmstat. El alto uso de recursos a menudo indica cuellos de botella. También examinaría la conectividad de red al servidor utilizando ping y traceroute para identificar posibles problemas de latencia de red. A continuación, revisaría los registros del servidor web (por ejemplo, Apache o Nginx) para buscar mensajes de error o registros de consultas lentas si hay una base de datos involucrada, lo que indica posibles problemas de rendimiento del código o de la base de datos. Usaría curl -w "%{time_total}" -o /dev/null <website_url> para medir el tiempo total empleado en recibir el sitio web. También examinaría el código del sitio web en busca de algoritmos ineficientes o imágenes/activos no optimizados, utilizando las herramientas de desarrollo del navegador para analizar el gráfico en cascada e identificar los recursos de carga lenta.

Un diagnóstico adicional implicaría perfilar el código de la aplicación para identificar funciones lentas o consultas de base de datos. Herramientas como strace o perf pueden proporcionar información sobre el rendimiento de las llamadas al sistema. Si se utiliza una base de datos, analizaría los planes de ejecución de consultas utilizando EXPLAIN para identificar oportunidades de optimización. Se evaluarían los mecanismos de almacenamiento en caché (por ejemplo, el uso de una CDN o el almacenamiento en caché del lado del servidor) para mejorar los tiempos de respuesta del contenido estático. Finalmente, considere herramientas como tcpdump o Wireshark para analizar el tráfico de red con más detalle, si es necesario.

19. ¿Cómo solucionarías un escenario en el que un servidor Linux está generando archivos de registro excesivos?

Primero, identifica la aplicación o el servicio que genera los registros excesivos. Utiliza herramientas como du -sh /var/log para verificar el tamaño de los archivos de registro y tail -f /var/log/syslog o journalctl -xe para monitorear los registros en tiempo real e identificar al culpable. Una vez identificado, investiga la causa raíz. Esto podría deberse a que el registro de depuración está habilitado, un error de la aplicación que causa el registro repetido, o incluso una configuración incorrecta.

Luego, implementa soluciones para mitigar el problema. Considera ajustar el nivel de registro de la aplicación, solucionar el error subyacente que causa el registro excesivo o implementar la rotación de registros utilizando logrotate. Configurar logrotate para comprimir y archivar los registros más antiguos puede ayudar a administrar el espacio en disco. Además, asegúrate de tener una monitorización adecuada para detectar problemas similares en el futuro. Si se necesita un registro detallado temporalmente, recuerda deshabilitarlo una vez que se complete la solución de problemas.

20. Describa los pasos que tomaría para diagnosticar un problema donde un archivo crítico del sistema se ha corrompido en un servidor Linux.

Primero, intentaría identificar el archivo corrupto. Esto podría implicar revisar los registros del sistema (/var/log/syslog, /var/log/messages, /var/log/audit/audit.log, etc.) en busca de mensajes de error o actividad inusual que preceda al mal funcionamiento del sistema. Herramientas como dmesg también pueden revelar errores a nivel de kernel. Una vez identificado el archivo, intentaría determinar el alcance de la corrupción, si está total o parcialmente corrupto.

Luego, dependiendo de la naturaleza y criticidad del archivo, intentaría reemplazarlo desde una fuente conocida y buena. Esto podría ser una copia de seguridad, una réplica de otro servidor en el clúster o desde el medio/paquete de instalación original. Si se trata de un archivo de configuración, podría recrearlo utilizando la configuración predeterminada o configuraciones anteriores conocidas. Verificaría el reemplazo ejecutando md5sum o sha256sum para compararlo con la suma de verificación conocida si está disponible, y luego reiniciaría el servicio relevante. Finalmente, implementaría medidas preventivas como copias de seguridad periódicas y comprobaciones de integridad del sistema de archivos (usando herramientas como AIDE o Tripwire) para evitar futuras ocurrencias. También podría ser beneficioso un escaneo de rootkit para descartar compromisos de seguridad.

21. Explique cómo identificaría y resolvería una situación en la que un paquete de software recién instalado está causando conflictos con las bibliotecas del sistema existentes.

Primero, intentaría identificar las bibliotecas del sistema específicas que causan el conflicto. Las herramientas comunes para esto incluyen ldd (Linux) u otool -L (macOS) para listar las dependencias del software recién instalado y compararlas con las bibliotecas del sistema existentes. También examinaría los registros del sistema (por ejemplo, /var/log/syslog, /var/log/messages o el Visor de eventos de Windows) en busca de mensajes de error o advertencias que apunten a conflictos de bibliotecas. Si el software tiene sus propios registros, también serían útiles.

Para resolver el conflicto, exploraría varias opciones. Una podría ser usar una tecnología de contenedorización como Docker para aislar el nuevo software y sus dependencias. Otro enfoque implicaría el uso de entornos virtuales (por ejemplo, venv de Python o Conda) para crear un entorno aislado para el software. Alternativamente, si las bibliotecas en conflicto están relacionadas con la versión, degradar o actualizar las bibliotecas en conflicto podría ser una solución, pero esto debe abordarse con cuidado para evitar romper otros componentes del sistema. Como último recurso, exploraría la vinculación estática de las bibliotecas requeridas con el nuevo software, pero esto puede aumentar el tamaño del software y podría introducir vulnerabilidades de seguridad.

22. ¿Cómo solucionaría un escenario en el que un servidor Linux está experimentando pánicos del kernel?

La solución de problemas de pánicos del kernel en un servidor Linux implica varios pasos. Primero, capture el mensaje de pánico desde la consola (física o serial). Analice los mensajes de error, prestando mucha atención al rastreo de llamadas que muestra las funciones que se estaban ejecutando cuando ocurrió el pánico. Esto dará pistas sobre la fuente del problema, posiblemente un controlador, hardware defectuoso o un error de software. Verifique los registros del sistema (/var/log/syslog, /var/log/kern.log) para detectar errores relacionados antes de que ocurriera el pánico.

Luego, si el pánico del kernel es reproducible, intente iniciar en una versión anterior del kernel desde el gestor de arranque (GRUB). Si el kernel anterior funciona, el problema podría estar relacionado con el kernel más reciente o sus módulos. Investigue las actualizaciones recientes del kernel, las instalaciones de controladores o los cambios de configuración. Herramientas como kdump se pueden configurar para capturar un volcado de memoria del kernel en el momento del pánico, que se puede analizar sin conexión utilizando herramientas como crash para proporcionar información más detallada. También se deben realizar diagnósticos de hardware (pruebas de memoria, comprobaciones de disco) para descartar fallos de hardware.

23. Describa los pasos que seguiría para diagnosticar un problema en el que un servidor Linux no puede comunicarse con una matriz de almacenamiento.

Para diagnosticar un problema de comunicación entre un servidor Linux y una matriz de almacenamiento, comenzaría con un enfoque en capas. Primero, verificaría la capa física: conexiones de cable, estado del puerto tanto en el servidor como en la matriz, y asegurarme de que haya luces de enlace. Luego, pasaría a la capa de red. Usaría ping y traceroute para verificar la conectividad de red básica entre el servidor y la dirección IP de la matriz de almacenamiento. Si eso falla, investigaría las tablas de enrutamiento (route -n) y las reglas del firewall (iptables -L o firewall-cmd --list-all) en el servidor para asegurar que el tráfico no esté siendo bloqueado. Además, confirmar la máscara de subred y la configuración de la puerta de enlace correctas es crucial.

A continuación, miraría la capa de protocolo de almacenamiento (por ejemplo, iSCSI, Fibre Channel). Para iSCSI, usaría iscsiadm para descubrir objetivos y verificar el estado de la sesión. Para Fibre Channel, herramientas como systool -c fc_host -v o lsscsi pueden mostrar los dispositivos conectados y sus estados. También examinaría los registros de la matriz de almacenamiento para detectar cualquier mensaje de error relacionado con los intentos de conexión del servidor. Finalmente, verificaría si el controlador HBA y el firmware del servidor son compatibles con la matriz de almacenamiento y están correctamente instalados. Cualquier software de multipath (por ejemplo, Device Mapper Multipath) también se inspeccionaría para detectar errores de configuración y fallos de ruta.

24. Explique cómo identificaría y resolvería una situación en la que un usuario no puede acceder a una unidad de red compartida en un servidor Linux.

Primero, verificaría las credenciales del usuario y la conectividad de la red. Comprobaría si el usuario puede hacer ping al servidor y si su nombre de usuario y contraseña son correctos. También verificaría si la cuenta del usuario está bloqueada o deshabilitada. Luego, investigaría la configuración del lado del servidor. Esto incluye verificar si el servicio Samba (o NFS) se está ejecutando, si el recurso compartido está correctamente configurado en el archivo smb.conf (o /etc/exports para NFS) con los permisos correctos para el usuario, y si el firewall del servidor permite el tráfico en los puertos necesarios (139, 445 para Samba; 111, 2049 para NFS). También verificaría los registros (/var/log/samba/log.smbd, /var/log/syslog) en busca de mensajes de error.

Para resolver el problema, comenzaría corrigiendo cualquier configuración incorrecta encontrada en los pasos anteriores. Si es un problema de permisos, usaría chmod y chown para ajustar los permisos de los archivos o modificar la configuración del recurso compartido de Samba. Si es un problema de firewall, usaría iptables o firewalld para abrir los puertos requeridos. Finalmente, reiniciaría el servicio Samba o NFS para aplicar los cambios. Si el problema persiste, analizaría los registros más a fondo o consultaría con otros miembros del equipo.

25. Explícame el proceso de diagnóstico de una situación en la que una máquina virtual que se ejecuta en un servidor Linux está experimentando problemas de rendimiento.

Para diagnosticar problemas de rendimiento de VM en un servidor Linux, comenzaría por verificar la utilización de recursos del servidor host (CPU, memoria, E/S de disco, red). Herramientas como top, htop, iostat y vmstat pueden ayudar a identificar cuellos de botella. Si el host está al máximo, el rendimiento de la VM se verá afectado. Luego, investigaría la propia VM utilizando herramientas como top o htop dentro de la VM para identificar procesos que consumen muchos recursos. También podemos verificar los registros específicos de la VM en busca de errores. Si el uso de CPU o memoria de la VM es alto, puede indicar un problema de aplicación o recursos insuficientes asignados a la VM.

Después de las comprobaciones básicas, investigaría el rendimiento de E/S del disco virtual. Herramientas como iotop dentro de la VM o el host pueden identificar procesos o VMs que consumen un exceso de E/S de disco. El rendimiento de la red se puede evaluar con iftop o tcpdump para identificar posibles cuellos de botella de red o un alto volumen de tráfico. Finalmente, considere las herramientas de monitoreo a nivel de hipervisor (como las que ofrece VMware o KVM) para una visión más holística de la asignación de recursos y las métricas de rendimiento en todas las VMs del host.

26. ¿Cómo solucionaría un escenario en el que un servidor Linux muestra síntomas de una posible violación de seguridad?

Primero, aísle el sistema de la red para evitar daños mayores. Luego, recopile información: revise los registros del sistema (/var/log/auth.log, /var/log/syslog, /var/log/secure), revise los procesos en ejecución (ps aux) y examine las conexiones de red (netstat -tulnp o ss -tulnp). Busque actividad sospechosa como inicios de sesión de usuario inusuales, procesos no autorizados o conexiones de red inesperadas. Use herramientas como chkrootkit o rkhunter para escanear en busca de rootkits.

A continuación, analice los datos recopilados. Correlacione las entradas del registro con la información del proceso y de la red para identificar la fuente y el alcance de la infracción. Investigue cualquier archivo o proceso sospechoso verificando sus sumas de verificación contra versiones buenas conocidas o enviándolos a servicios de análisis en línea como VirusTotal. Finalmente, según los hallazgos, implemente los pasos de remediación apropiados, como eliminar malware, parchear vulnerabilidades y restaurar desde copias de seguridad. Considere contratar a profesionales de seguridad para obtener ayuda.

27. Describa los pasos que tomaría para diagnosticar un problema en el que un servidor Linux no aplica las actualizaciones de seguridad.

Para diagnosticar por qué un servidor Linux no está aplicando actualizaciones de seguridad, comenzaría por verificar los archivos de configuración de actualización (por ejemplo, /etc/apt/sources.list para Debian/Ubuntu o /etc/yum.repos.d/ para Red Hat/CentOS) para asegurar que los repositorios estén definidos correctamente y sean accesibles. Luego, examinaría los registros del gestor de paquetes (/var/log/apt/history.log, /var/log/yum.log, /var/log/dnf.log) en busca de mensajes de error o intentos de actualización fallidos. También intentaría manualmente una actualización usando el gestor de paquetes (por ejemplo, sudo apt update && sudo apt upgrade o sudo yum update o sudo dnf upgrade) para ver cualquier salida de error inmediata.

Luego, investigaría posibles problemas de conectividad de red para descartar problemas al alcanzar los servidores de actualización, utilizando herramientas como ping o traceroute. También verificaría si hay problemas de espacio en disco, particularmente en las particiones /boot y /, ya que un espacio insuficiente puede impedir las actualizaciones. Finalmente, verificaría si hay paquetes o dependencias en conflicto que podrían estar bloqueando el proceso de actualización, lo que a menudo requiere una investigación de los mensajes de error del gestor de paquetes.

28. Explique cómo identificaría y resolvería una situación en la que un script personalizado no se ejecuta correctamente en un servidor Linux.

Para identificar y resolver un script personalizado fallido en un servidor Linux, primero verificaría los registros del script, si existen, en busca de mensajes de error o comportamiento inusual. También examinaría los registros del sistema (/var/log/syslog, /var/log/messages) en busca de errores relacionados con el tiempo de ejecución del script. Para identificar el problema, ejecutaría manualmente el script con flags de depuración (bash -x script.sh) o usando un depurador como pdb (si es un script de Python) para recorrer el código e inspeccionar los valores de las variables. Para problemas de permisos, usaría ls -l para verificar los permisos y la propiedad del archivo, y los corregiría con chmod o chown si fuera necesario.

Después de identificar la causa raíz, ya sea un error de sintaxis, una dependencia faltante, permisos de archivo incorrectos o un problema de entorno, aplicaría la solución adecuada. Esto podría implicar editar el script, instalar paquetes faltantes usando apt o yum, ajustar los permisos de archivo o modificar las variables de entorno. Finalmente, probaría el script a fondo después de aplicar la solución para asegurar que funcione correctamente y lo monitorizaría para detectar cualquier reaparición del problema.

29. Explique qué pasos tomaría para diagnosticar un servidor que de repente es inaccesible a través de la red, pero al que puede acceder localmente.

Primero, verificaría la configuración de red del servidor usando herramientas como ip addr, route -n y ping para verificar que su dirección IP, puerta de enlace y configuración de DNS sean correctas. También examinaría las reglas del firewall del servidor (iptables -L, firewall-cmd --list-all) para asegurar que el tráfico de red no esté siendo bloqueado. Luego, verificaría que el servicio de red se esté ejecutando usando systemctl status <network_service> por ejemplo systemctl status networking o systemctl status NetworkManager. También usaré netstat -tulnp o ss -tulnp para verificar si el servicio al que intento acceder está escuchando en el puerto y la dirección IP correctos.

A continuación, me centraría en la conectividad de red fuera del servidor. Usaría traceroute o mtr desde otra máquina en la red para identificar dónde falla la conexión. Revisaré las configuraciones del conmutador y del enrutador para detectar listas de control de acceso (ACL) o reglas de firewall que puedan estar bloqueando el tráfico al servidor. Si el servidor está en una subred diferente, verificaría las tablas de enrutamiento en los enrutadores intermedios.

Preguntas de entrevista avanzadas sobre resolución de problemas de Linux

1. ¿Cómo diagnosticaría una situación en la que una aplicación específica es constantemente lenta, pero el rendimiento general del sistema parece normal? Explique las herramientas y técnicas que emplearía.

Para diagnosticar una aplicación constantemente lenta a pesar del rendimiento normal del sistema, me centraría en los cuellos de botella específicos de la aplicación. Primero, usaría herramientas de monitoreo del rendimiento de la aplicación (APM) como New Relic, Dynatrace, o incluso herramientas de perfilado integradas (si están disponibles) para identificar rutas de ejecución de código lentas, el rendimiento de las consultas de la base de datos y la latencia de las llamadas a la API externa. Estas herramientas ayudan a identificar las funciones o transacciones exactas que causan retrasos. A continuación, examinaría los registros de la aplicación en busca de mensajes de error, advertencias o patrones inusuales que podrían indicar problemas subyacentes, como fugas de recursos o problemas de configuración.

Si APM no está disponible, usaría herramientas a nivel de sistema de manera más específica. Por ejemplo, strace en Linux o Process Monitor en Windows pueden rastrear las llamadas al sistema realizadas por la aplicación, revelando operaciones de E/S lentas o contención en recursos específicos. Los registros de consultas de la base de datos pueden resaltar consultas ineficientes, lo que incita a la optimización del índice o a la reescritura de la consulta. También es crucial verificar la configuración específica de la aplicación para detectar configuraciones subóptimas o limitaciones de recursos, por ejemplo, el tamaño del montón de Java para aplicaciones Java o el tamaño del grupo de conexiones para conexiones de bases de datos. La latencia de la red entre la aplicación y sus dependencias (por ejemplo, base de datos, API externas) también debe medirse utilizando herramientas como ping, traceroute o mtr para descartar problemas relacionados con la red.

2. Explique su enfoque para solucionar un problema de conectividad de red donde un servidor puede hacer ping a direcciones externas pero no puede resolver nombres de host. ¿Cuáles son las posibles causas y cómo investigaría?

Cuando un servidor puede hacer ping a direcciones externas pero no puede resolver nombres de host, el principal sospechoso es un problema de DNS. El servidor tiene conectividad de red básica, confirmada por pings exitosos, pero no está traduciendo los nombres de dominio en direcciones IP. Primero verificaría la configuración del servidor DNS configurada en el servidor (por ejemplo, en /etc/resolv.conf en Linux o en la configuración del adaptador de red en Windows) para asegurarme de que sean correctas y apunten a un servidor DNS válido y en funcionamiento.

Luego, usaría nslookup o dig para consultar el servidor DNS directamente y ver si puede resolver nombres de host. Si nslookup falla, esto indica un problema con el propio servidor DNS o la capacidad del servidor para acceder a él. Luego investigaría la conectividad de red con el servidor DNS (ping, traceroute), las configuraciones del servidor DNS y las reglas del firewall que podrían estar bloqueando el tráfico DNS (puerto 53). Otras causas potenciales incluyen una caché DNS defectuosa en el servidor (que purgaría) o un orden de búsqueda de sufijos DNS incorrecto que se puede configurar a través de la configuración de red del servidor.

3. Describe un escenario en el que un sistema de archivos se vuelve de solo lectura inesperadamente. ¿Qué pasos tomaría para identificar la causa raíz y restaurar el acceso de escritura?

Un sistema de archivos podría volverse de solo lectura inesperadamente debido a varias razones. Un escenario común es la corrupción o error del sistema de archivos detectado por el sistema operativo. Cuando esto sucede, el sistema operativo a menudo vuelve a montar el sistema de archivos en modo de solo lectura para evitar una mayor corrupción de datos. Esto también podría suceder debido a errores de disco (sectores defectuosos), espacio en disco insuficiente o una opción de montaje mal configurada.

Para identificar la causa raíz y restaurar el acceso de escritura, primero verificaría los registros del sistema (/var/log/syslog o similar) en busca de mensajes de error relacionados con el sistema de archivos. Luego ejecutaría dmesg para examinar los mensajes del kernel en busca de errores de E/S del disco o informes de corrupción del sistema de archivos. A continuación, usaría df -h para verificar que el disco no esté lleno. Si el sistema de archivos está corrupto, fsck (verificación del sistema de archivos) podría ser necesario para repararlo. Si el disco tiene errores, herramientas como smartctl (si es compatible) pueden proporcionar información sobre su estado. Finalmente, después de abordar la causa raíz, volvería a montar el sistema de archivos con permisos de lectura-escritura utilizando el comando mount -o remount,rw /mount/point. Si los errores del disco son evidentes, reemplazar el hardware defectuoso es generalmente el mejor curso de acción.

4. Un servicio crítico en su servidor Linux se bloquea intermitentemente sin dejar mensajes de error obvios. ¿Cómo procedería para depurar este problema?

Primero, me aseguraría de que el sistema esté configurado para capturar suficiente información de depuración. Esto incluye verificar /var/log/syslog y /var/log/messages para cualquier entrada relacionada con los momentos de la caída. También configuraría systemd-journald para el registro persistente si aún no lo está. Luego, examinaría el uso de recursos (CPU, memoria, E/S de disco) utilizando herramientas como top, vmstat e iostat para identificar el posible agotamiento de recursos.

Si el servicio se bloquea sin errores explícitos, usaría strace para rastrear las llamadas al sistema realizadas por el servicio antes del bloqueo. Esto puede revelar qué llamada al sistema está fallando o causando el bloqueo. Otra herramienta valiosa es gdb. Si se genera un volcado de memoria (verifique /proc/sys/kernel/core_pattern y asegúrese de que los volcados de memoria estén habilitados), analizaría el volcado de memoria utilizando gdb para determinar el punto exacto de la falla. Considere agregar un registro más detallado al servicio en sí, si es posible, y considere usar una solución de monitoreo para alertar cuando el servicio esté inactivo y recopilar estadísticas de rendimiento.

5. Sospecha una fuga de memoria en un proceso en ejecución. Detalle las herramientas y métodos que utilizaría para confirmar la fuga e identificar el código fuente responsable.

Para confirmar una fuga de memoria, comenzaría con herramientas como top, htop o ps para observar el consumo de memoria del proceso a lo largo del tiempo. Un tamaño de conjunto residente (RSS) o tamaño de memoria virtual (VSZ) en constante aumento indicaría una posible fuga. Luego, usaría herramientas de perfilado de memoria como valgrind (específicamente Memcheck) o AddressSanitizer (ASan) si la recompilación es factible, o herramientas como gdb con pmap o heaptrack si no lo es. Estas herramientas ayudarían a identificar los sitios de asignación que no se están liberando. Para aplicaciones Java, se pueden utilizar herramientas como VisualVM o Java Mission Control para analizar el montón e identificar fugas de memoria.

Una vez que haya identificado los sitios de asignación, examinaría el código fuente correspondiente. Buscaría patrones como asignaciones sin desasignaciones correspondientes, objetos que se agregan a colecciones sin ser eliminados, o referencias circulares que impiden la recolección de basura. Las herramientas de análisis estático también pueden ayudar a identificar posibles problemas de fuga de memoria en el código. Las revisiones de código, centradas en la gestión de la memoria, también ayudan a encontrar la fuente de las fugas de memoria.

6. ¿Cómo solucionaría una situación en la que un usuario no puede iniciar sesión en un sistema Linux, incluso con las credenciales correctas? Considere diferentes métodos de autenticación.

Primero, verificaría el estado de la cuenta del usuario usando passwd -S <nombre_de_usuario> para comprobar si la cuenta está bloqueada o deshabilitada. También revisaría /var/log/auth.log (o similar, dependiendo del sistema) en busca de fallos de autenticación, lo que podría proporcionar pistas sobre la causa (por ejemplo, shell no válido, problemas de configuración de PAM o intentos de fuerza bruta). Si se utilizan claves SSH, confirmaría que el archivo ~/.ssh/authorized_keys del usuario está configurado correctamente y que los permisos en el directorio .ssh y el archivo authorized_keys son lo suficientemente restrictivos (700 para .ssh y 600 para authorized_keys). Para la autenticación por contraseña, comprobaría si la contraseña del usuario ha caducado utilizando chage -l <nombre_de_usuario>. Finalmente, probaría si sudo su - <nombre_de_usuario> funciona, lo que a menudo omite algunas restricciones de inicio de sesión y ayuda a aislar el problema.

Si el problema persiste, investigaría la configuración de PAM (Módulos de Autenticación Enchufables) en /etc/pam.d/*, que controla las políticas de autenticación, especialmente los archivos common-auth, common-account y common-session. Las configuraciones incorrectas de PAM pueden impedir los inicios de sesión, incluso con credenciales correctas. Para sistemas que utilizan autenticación de red (como LDAP o Active Directory), verificaría la conectividad de red y el estado del servidor de autenticación. Comandos como id <nombredeusuario> deberían devolver información del servidor de directorio de red si está configurado correctamente.

7. Explique cómo diagnosticaría y resolvería un problema donde un módulo de kernel recién instalado está causando inestabilidad o bloqueos del sistema.

Para diagnosticar y resolver la inestabilidad del sistema después de instalar un nuevo módulo de kernel, primero intentaría reproducir el problema de manera consistente. Luego, verificaría los registros del sistema (/var/log/syslog, dmesg) en busca de errores o advertencias relacionadas con el módulo. Deshabilitar el módulo (usando rmmod si es posible, o incluyéndolo en la lista negra en /etc/modprobe.d/ y reiniciando si no lo es) sería el siguiente paso para confirmar si es realmente el culpable. También verificaría las dependencias del módulo y me aseguraría de que sean compatibles con el kernel actual.

Si el módulo es el problema, inspeccionaría su código fuente en busca de posibles errores o fugas de memoria. Herramientas como valgrind podrían usarse para analizar su comportamiento en un entorno controlado. Si se encuentra un error, intentaría solucionarlo y reconstruir el módulo. Si no hay errores aparentes, consideraría problemas de compatibilidad con otro hardware o software del sistema y consultaría la documentación o foros relevantes para posibles soluciones o problemas conocidos.

8. Describa su enfoque para solucionar una situación en la que un proceso en segundo plano consume recursos excesivos de la CPU, impactando el rendimiento general del sistema.

Mi enfoque para solucionar el alto uso de CPU por un proceso en segundo plano implica varios pasos. Primero, identificaría el proceso usando herramientas como top, htop o ps para señalar el proceso específico que consume CPU en exceso. Una vez identificado, analizaría los registros y la configuración del proceso para comprender su función y cualquier cambio reciente. También usaría herramientas como strace o perf para perfilar el proceso e identificar qué llamadas al sistema o funciones están consumiendo la mayor cantidad de tiempo de CPU.

A continuación, consideraría las posibles causas, como algoritmos ineficientes, bucles infinitos, E/S excesiva o contención de recursos. Basándome en los datos de perfilado, intentaría optimizar el código, ajustar las prioridades del proceso usando nice, limitar el uso de recursos (por ejemplo, memoria) o reprogramar el proceso para horas de menor actividad. Si el problema persiste, investigaría factores externos como consultas a la base de datos, actividad de la red o limitaciones de hardware que podrían estar contribuyendo al problema. Monitorearía de cerca el sistema después de implementar cualquier cambio para asegurar que el problema se resuelva y no vuelva a ocurrir.

9. Un trabajo cron programado no se está ejecutando como se esperaba. ¿Qué pasos tomaría para determinar la causa del fallo y asegurar que el trabajo se ejecute con éxito?

Primero, verificaría la configuración del trabajo cron utilizando crontab -l para verificar que la programación sea correcta y no haya sido modificada accidentalmente. Luego, examinaría los registros del sistema (por ejemplo, /var/log/syslog, /var/log/cron) en busca de mensajes de error relacionados con la ejecución del trabajo cron. Esto a menudo proporciona pistas sobre por qué falló el trabajo, como rutas de archivos incorrectas, dependencias faltantes o problemas de permisos. También examinaría la salida que el trabajo cron produce a la salida estándar y al error estándar, posiblemente redirigiendo la salida a archivos para facilitar la depuración. * * * * * /ruta/al/script.sh > /tmp/cron.log 2>&1

Para asegurar que el trabajo se ejecute correctamente, ejecutaría manualmente el script utilizando el mismo contexto de usuario que el trabajo cron (usando sudo -u <usuario> /ruta/al/script.sh) para reproducir el error y depurarlo en tiempo real. También agregaría manejo de errores y registro dentro del script para proporcionar información más detallada en caso de fallas futuras. Finalmente, volvería a verificar los permisos de los archivos y me aseguraría de que todas las dependencias necesarias estén instaladas y sean accesibles para el usuario que ejecuta el trabajo cron.

10. ¿Cómo investigaría un escenario en el que un servidor Linux experimenta una alta E/S de disco, pero ningún proceso específico parece ser el responsable? Considere diferentes herramientas de monitoreo.

Para investigar la alta E/S de disco en un servidor Linux cuando ningún proceso individual parece ser el responsable, comenzaría con iotop para obtener una vista en tiempo real del uso de E/S por proceso. Si iotop no identifica un proceso específico, sospecharía de actividad del kernel o tareas en segundo plano. Luego, usaría iostat -xz 1 para analizar la utilización general del disco, incluyendo métricas como %util (porcentaje de tiempo que el disco está ocupado) y await (tiempo promedio para operaciones de E/S). Además, revisaría /proc/vmstat para los contadores pswpin y pswpout para detectar actividad de intercambio (swapping), lo cual puede causar E/S de disco. Adicionalmente, usaría perf (Linux perf_events) para perfilar las funciones relacionadas con la E/S de disco del kernel para identificar con precisión las funciones del kernel que consumen E/S.

Si los pasos anteriores no revelan la causa, buscaría contención de recursos o problemas de almacenamiento subyacentes. Examinaría los registros del sistema (/var/log/syslog, /var/log/kern.log) para buscar errores de disco o advertencias relacionadas. Consideraría si alguna tarea programada (tareas cron) o demonios del sistema están causando intermitentemente la alta E/S. Los sistemas de archivos de red (NFS) u otro almacenamiento remoto también pueden ser una fuente, por lo que verificaría la conectividad de red y el estado de los montajes remotos usando df -h. Para sistemas de archivos específicos (por ejemplo, XFS, ext4), las herramientas específicas del sistema de archivos podrían ofrecer diagnósticos más granulares. Si se utiliza LVM, verificaría las estadísticas de LVM.

11. Explicaría cómo solucionaría una situación en la que una máquina virtual (VM) que se ejecuta en un host Linux está experimentando problemas de conectividad de red que las otras VM no.

Primero, verificaría la configuración de red de la máquina virtual (dirección IP, máscara de subred, puerta de enlace, DNS) usando ip addr, ip route y /etc/resolv.conf. Haría ping a la puerta de enlace y a otras máquinas virtuales en la misma red para verificar la accesibilidad básica. Luego, examinaría las reglas del firewall de la máquina virtual usando iptables -L o firewall-cmd --list-all para asegurarme de que no se bloquee el tráfico. Después de eso, revisaría el archivo de configuración de la interfaz de red de la máquina virtual (por ejemplo, /etc/network/interfaces o archivos en /etc/sysconfig/network-scripts/) en busca de errores. También me aseguraré de que la interfaz esté activa con ip link set <interface> up. Si todo eso parece estar bien, verificaría la configuración de red del host Linux para asegurarme de que no haya problemas de enrutamiento o puente que afecten solo a esa máquina virtual específica. Finalmente, me aseguraría de que el hipervisor no esté haciendo algo extraño.

12. Describa su enfoque para diagnosticar y resolver un problema donde un servicio systemd no se inicia automáticamente al arrancar. Considere los problemas de dependencia.

Cuando un servicio systemd no se inicia automáticamente al arrancar, primero verifico el estado del servicio usando systemctl status <nombre_del_servicio>. Esto mostrará los mensajes de error y la razón de la falla. Luego examino los registros del sistema (journalctl -u <nombre_del_servicio>) para obtener información más detallada, centrándome en las marcas de tiempo alrededor del proceso de arranque. Los problemas de dependencia son una causa común; inspeccionaría las directivas Requires, After y Before en el archivo de la unidad de servicio. Si un servicio requerido no se está iniciando, el servicio dependiente probablemente también fallará.

Para resolver problemas de dependencias, me aseguro de que todas las dependencias estén configuradas y habilitadas correctamente. El comando systemctl list-dependencies <nombre_del_servicio> es invaluable para comprender el árbol de dependencias del servicio. Si existe una dependencia circular, el archivo de servicio necesita modificación. Ajusto cuidadosamente las directivas After y Requires para resolver el bucle. Si un factor externo como el acceso a la red es una dependencia, verificaré network-online.target en la directiva After. Finalmente, intentaría iniciar manualmente cada dependencia en el orden correcto para señalar el punto exacto del fallo y abordar ese problema específico antes de volver a habilitar el servicio principal.

13. Sospecha de una violación de seguridad en su servidor Linux. ¿Qué pasos tomaría para investigar el incidente, identificar el punto de entrada del atacante y mitigar el daño?

Primero, aísle el servidor para evitar daños mayores. Esto implica desconectarlo de la red. Luego, recopile pruebas: examine los registros del sistema (/var/log/auth.log, /var/log/syslog, /var/log/secure), los registros del servidor web (si corresponde) y los registros de la aplicación. Busque procesos inusuales utilizando herramientas como ps, top y netstat para identificar actividades o conexiones sospechosas. Revise las cuentas de usuario en busca de cuentas no autorizadas o creadas recientemente, y verifique los archivos .bash_history en busca de comandos inusuales.

Para identificar el punto de entrada, analice los registros en busca de intentos de inicio de sesión sospechosos, intentos fallidos de SSH o vulnerabilidades explotadas. Busque modificaciones de archivos no autorizadas utilizando herramientas como find con parámetros de fecha/hora. Una vez que se identifica el punto de entrada, corrija la vulnerabilidad, elimine cualquier malware o puerta trasera y restaure el sistema desde una copia de seguridad limpia si está disponible. Cambie todas las contraseñas comprometidas e implemente la autenticación multifactor. Finalmente, analice la causa raíz para prevenir incidentes futuros y mejorar las medidas de seguridad, como la implementación de sistemas de detección de intrusiones y auditorías de seguridad periódicas.

14. ¿Cómo solucionaría una situación en la que una biblioteca compartida está causando conflictos entre diferentes aplicaciones en un sistema Linux? Considere los problemas de versionado.

Cuando una biblioteca compartida causa conflictos entre aplicaciones, especialmente debido al versionado, comenzaría por identificar la biblioteca en conflicto utilizando herramientas como ldd para verificar qué aplicaciones la están utilizando. Luego, usaría ls -l o file para determinar la versión exacta de la biblioteca cargada por cada aplicación.

Para resolver los conflictos, consideraría estos enfoques:

• Versionado de símbolos: Asegura que diferentes versiones de la misma biblioteca puedan coexistir mediante el uso de símbolos versionados.
• Usar diferentes rutas de bibliotecas: Establecer LD_LIBRARY_PATH para aplicaciones individuales para apuntar a la versión correcta de la biblioteca. Precaución: Esto debe usarse con cuidado, ya que puede causar consecuencias no deseadas.
• Contenedorización: Aislar las aplicaciones y sus dependencias en contenedores (por ejemplo, Docker) para evitar conflictos.
• Enlace estático: Enlazar la biblioteca estáticamente con cada aplicación, eliminando por completo la necesidad de una biblioteca compartida (si es factible y la licencia lo permite).

15. Explique cómo diagnosticaría y resolvería un problema en el que un servidor Linux está experimentando bloqueos frecuentes del kernel. ¿Qué herramientas y técnicas usaría para recopilar información?

Para diagnosticar los frecuentes pánicos del kernel en un servidor Linux, comenzaría por recopilar información utilizando estas herramientas y técnicas. Primero, examinaría los registros del sistema, especialmente /var/log/syslog, /var/log/kern.log y la salida de dmesg inmediatamente después de un reinicio. Estos registros a menudo contienen pistas valiosas sobre la causa del pánico, como problemas de controladores, errores de hardware o corrupción de la memoria. También configuraría kdump para capturar un volcado de memoria (vmcore) cuando ocurra un pánico del kernel. Esto permite el análisis fuera de línea utilizando herramientas como crash o gdb para identificar la ubicación exacta del código y el estado que desencadenó el pánico.

Luego, analizaría el volcado de memoria del kernel utilizando crash o gdb. Esto implica examinar la pila de llamadas, los registros y otras regiones de memoria relevantes para identificar la causa raíz. Los posibles culpables incluyen hardware defectuoso (memoria, CPU), módulos o controladores del kernel con errores y problemas de configuración del kernel. Para descartar problemas de hardware, ejecutaría pruebas de memoria (por ejemplo, Memtest86+) y monitorearía las temperaturas y voltajes de la CPU. Si se sospecha de un controlador específico, intentaría actualizarlo o eliminarlo. Además, revisar los cambios recientes del sistema, como las actualizaciones del kernel o las modificaciones de configuración, puede ayudar a identificar las posibles causas. Finalmente, habilitar sysrq puede proporcionar una forma de activar un fallo manual y recopilar información cuando el sistema está a punto de entrar en pánico, lo que ayuda a depurar.

16. Describe su enfoque para solucionar una situación en la que un servidor de base de datos en un sistema Linux está experimentando una degradación del rendimiento debido a consultas lentas. Considere herramientas de perfilado.

Al solucionar problemas de consultas lentas en la base de datos en Linux, comenzaría por identificar las consultas problemáticas utilizando herramientas como mysqladmin processlist (para MySQL) o pg_stat_activity (para PostgreSQL). También buscaría en el registro de consultas lentas del servidor de la base de datos, si está habilitado. Después de identificar las consultas lentas, usaría herramientas de perfilado como EXPLAIN para analizar el plan de ejecución de la consulta e identificar cuellos de botella como índices faltantes o escaneos de tabla completos. pt-query-digest o pgBadger pueden agregar registros de consultas lentas para facilitar el análisis.

A nivel del sistema, monitorearía el uso de recursos utilizando herramientas como top, vmstat e iostat para verificar los cuellos de botella de CPU, memoria o E/S de disco. La latencia de la red podría verificarse usando ping o traceroute. Si los recursos del sistema están restringidos, investigaría la causa raíz y consideraría agregar más recursos u optimizar la configuración de la base de datos. Por ejemplo, aumentar el tamaño del grupo de búferes. Finalmente, ejecutaré las consultas lentas con strace para verificar las llamadas al sistema y obtener más información.

17. ¿Cómo investigaría un escenario en el que un servidor Linux está enviando correos electrónicos no deseados (spam)? ¿Qué pasos tomaría para identificar la cuenta o el proceso comprometido?

Para investigar un servidor Linux que envía spam, comenzaría por examinar los registros de correo (/var/log/mail.log o similar) en busca de patrones, IPs de envío y marcas de tiempo relacionadas con el spam. Usaría herramientas como grep, awk y tail para filtrar y analizar estos registros. También verificaría la cola de correo utilizando mailq o postqueue -p para identificar los mensajes y sus remitentes.

A continuación, intentaría identificar la cuenta o proceso comprometido. Esto implica verificar la actividad del usuario, buscar tareas cron sospechosas y examinar los procesos en ejecución con top o ps aux en busca de un uso inusual de recursos o conexiones. Revisaría el historial de inicio de sesión del usuario (/var/log/auth.log o /var/log/secure) para detectar accesos no autorizados. Herramientas como netstat o ss pueden ayudar a identificar procesos que establecen conexiones con servidores de correo externos. También verificaría cualquier paquete instalado recientemente. Una vez que se identifique la cuenta o el proceso, aseguraría la cuenta (por ejemplo, cambiando las contraseñas, deshabilitando la cuenta) e investigaría cómo ocurrió el compromiso.

18. Explique cómo solucionaría un problema en el que una aplicación en contenedores que se ejecuta en un sistema Linux no se inicia debido a restricciones de recursos. Considere cgroups.

Primero, verificaría los registros del contenedor y los registros del sistema (por ejemplo, journalctl) en busca de mensajes de error que indiquen agotamiento de recursos (CPU, memoria, E/S de disco). Luego, usaría docker stats o kubectl top (si se usa Kubernetes) para monitorear el uso de recursos del contenedor fallido y otros contenedores en el mismo host. Usar docker inspect <container_id> mostrará los límites de recursos configurados. Si el contenedor está alcanzando los límites configurados, ajustaría los límites de recursos en el sistema de orquestación de contenedores (Docker Compose, implementaciones de Kubernetes, etc.) o el comando docker run. Además, verificaría el uso de recursos del host con herramientas como top, htop o free -m para identificar la presión general de recursos del sistema. Si el host está bajo restricciones de recursos, consideraría escalar el host, mover los contenedores a otros hosts u optimizar el uso de recursos por otras aplicaciones.

Para investigar los límites de cgroup directamente, navegaría al directorio de cgroup para el contenedor, típicamente ubicado en /sys/fs/cgroup/memory/docker/<container_id> o /sys/fs/cgroup/cpu/docker/<container_id>. Aquí, podría inspeccionar archivos como memory.limit_in_bytes y cpu.shares para verificar los límites de recursos aplicados. La mala configuración o los valores inesperados en estos archivos también podrían apuntar a la causa raíz. También es posible que ocurriera un evento OOMKilled que se puede verificar a través de dmesg.

19. Describe su enfoque para diagnosticar y resolver un problema donde un servidor Linux está experimentando alta latencia de red. ¿Qué herramientas y técnicas usaría para identificar el cuello de botella?

Para diagnosticar la alta latencia de la red en un servidor Linux, comenzaría por confirmar el problema con ping o traceroute a diferentes destinos, tanto internos como externos. Luego usaría herramientas para identificar el cuello de botella. tcpdump o Wireshark pueden capturar el tráfico de la red para su análisis, buscando retransmisiones, retrasos o tamaños de paquetes inusuales. iftop o nload ayudan a monitorear la utilización de la interfaz de red para ver si se está produciendo saturación. ethtool puede verificar errores de interfaz o discrepancias de velocidad/dúplex.

Una investigación más profunda implicaría examinar el uso de recursos del servidor con herramientas como top o htop para descartar la contención de CPU o memoria que afecta el rendimiento de la red. netstat o ss pueden revelar las conexiones establecidas y sus estados, lo que ayuda a identificar aplicaciones o hosts específicos que contribuyen a la latencia. También verificaría los registros del sistema (/var/log/syslog, /var/log/kern.log) en busca de mensajes de error relevantes. Si el problema persiste, analizaría la ruta de la red, verificando conmutadores y enrutadores en busca de congestión o configuración incorrecta utilizando sus respectivas herramientas de monitoreo o interfaces de línea de comandos.

20. ¿Cómo solucionaría un problema en el que un usuario informa que sus archivos se están corrompiendo en un sistema de archivos de red compartido (NFS)? Considere problemas de bloqueo de archivos.

Primero, verificaría el informe del usuario y recopilaría detalles como qué archivos se ven afectados, la hora de la corrupción y el flujo de trabajo del usuario. Revisaría los registros del servidor NFS (/var/log/messages, /var/log/syslog) en busca de errores de NFS, problemas relacionados con el bloqueo o problemas de conectividad de la red. También examinaría los registros del lado del cliente si están disponibles. Luego, investigaría posibles conflictos de bloqueo de archivos. Las configuraciones incorrectas de NFS, ya sea en el servidor o en el cliente, pueden provocar esto. Comprobaría la salida de nfsstat tanto en el servidor como en el cliente para ver las estadísticas de NFS e identificar la posible contención o errores de bloqueo.

Para abordar el bloqueo, revisaría las opciones de exportación NFS en /etc/exports en el servidor, asegurando que nolock no esté habilitado sin intención y que los mecanismos de bloqueo apropiados (como lockd y statd) se estén ejecutando y configurados correctamente tanto en el cliente como en el servidor. Verificaría que el servidor y los clientes NFS estén utilizando versiones NFS compatibles y que todos los sistemas tengan suficiente espacio en disco y memoria. Si el problema persiste, capturaría el tráfico de red utilizando tcpdump o Wireshark para analizar la comunicación NFS e identificar posibles problemas a nivel de paquete. Finalmente, deshabilitaría temporalmente los oplocks o habilitaría configuraciones de bloqueo más estrictas para ver si mitiga la corrupción mientras investigo las causas raíz.

21. Explique cómo diagnosticaría y resolvería un problema en el que un servidor Linux no puede conectarse a una API externa debido a problemas con el certificado SSL/TLS. Considere la validación del certificado.

Primero, verificaría la conectividad de red usando ping y traceroute al punto final de la API. Si eso está bien, me enfocaría en SSL/TLS. Usaría openssl s_client -connect host:port para verificar el certificado presentado por la API. Este comando ayuda a determinar si el certificado es válido, confiable y si hay algún error durante el handshake. Revisaría la fecha de vencimiento del certificado, el emisor y el sujeto. Los problemas de validación del certificado pueden provenir de certificados vencidos, Autoridades de Certificación (CA) no confiables o discrepancias en el nombre de host.

Para resolver, primero me aseguraría de que la fecha y hora del servidor sean correctas, ya que una hora incorrecta puede invalidar los certificados. Luego, verificaría que los certificados CA necesarios estén instalados en el servidor. Estos suelen estar ubicados en /etc/ssl/certs/. Si falta una CA, la instalaría utilizando el gestor de paquetes de la distribución (por ejemplo, apt install ca-certificates en Debian/Ubuntu). Si la API utiliza un certificado autofirmado, lo agregaría manualmente al almacén de confianza, entendiendo las implicaciones de seguridad. Finalmente, revisaría el código de la aplicación en busca de cualquier configuración SSL/TLS que pudiera estar anulando los valores predeterminados del sistema o causando problemas, como deshabilitar explícitamente la verificación de certificados (lo cual generalmente debe evitarse).

22. Describa su enfoque para solucionar una situación en la que una aplicación Python se bloquea debido a un fallo de segmentación. ¿Cómo usaría herramientas de depuración para encontrar el error?

Cuando me enfrento a una aplicación Python que se bloquea debido a un fallo de segmentación, mi enfoque implica una combinación de técnicas y herramientas de depuración. Dado que los fallos de segmentación generalmente indican un problema con la gestión de la memoria (a menudo en extensiones C), comenzaría por verificar posibles problemas en cualquier biblioteca externa o extensiones C personalizadas utilizadas por la aplicación Python. Usaría herramientas como gdb (GNU Debugger) o lldb para adjuntarlas al proceso en ejecución o examinar un volcado de núcleo si está disponible. Dentro de gdb, establecería puntos de interrupción en el código de extensión C (si corresponde) o usaría retrocesos (bt command) para identificar la ubicación exacta donde ocurre el fallo. También usaría herramientas como valgrind o AddressSanitizer (ASan) para detectar errores de memoria como desbordamientos de búfer o problemas de uso después de la liberación durante la ejecución del programa. Finalmente, si ocurre con bibliotecas de terceros, crear un ejemplo reproducible mínimo permitiría un mejor aislamiento y presentación de informes a los mantenedores de la biblioteca.

Si no hay extensiones C involucradas, me centraría en el código Python que podría estar interactuando con el sistema operativo de una manera de bajo nivel (por ejemplo, usando ctypes o mmap). Analizar la pila de llamadas del volcado de memoria puede ayudar a identificar el código Python problemático. También consideraría actualizar Python y las bibliotecas relevantes a las últimas versiones, ya que el problema podría haberse resuelto en una versión más reciente. El uso de bloques try...except alrededor de secciones de código sospechosas también puede ayudar a detectar excepciones y proporcionar mensajes de error más informativos antes de que ocurra el fallo de segmentación, aunque eso no será una solución en todos los casos.

23. ¿Cómo solucionaría una situación en la que sospecha que una condición de carrera está causando un comportamiento impredecible en una aplicación multi-hilo? ¿Qué herramientas usaría?

Para solucionar una posible condición de carrera, comenzaría por tratar de reproducir el problema de manera confiable. Las condiciones de carrera son a menudo intermitentes, por lo que la reproducción consistente es clave. Luego usaría varias técnicas para identificar y aislar el problema. Las herramientas de análisis estático pueden ayudar a detectar posibles condiciones de carrera analizando el código en busca de estado mutable compartido y falta de sincronización adecuada. Las herramientas de análisis dinámico, como los saneadores de hilos (por ejemplo, ThreadSanitizer en GCC/Clang), pueden detectar carreras de datos en tiempo de ejecución. El registro y la depuración son esenciales; agregar registros estratégicos para rastrear la ejecución de hilos y el acceso a recursos compartidos puede revelar intercalaciones inesperadas. Las herramientas de depuración como GDB o Visual Studio Debugger permiten establecer puntos de interrupción e inspeccionar los estados de los hilos para identificar la ubicación exacta de la carrera.

Específicamente, usaría herramientas como valgrind --tool=helgrind o ThreadSanitizer (si es aplicable al lenguaje). Además, las revisiones de código pueden ayudar a identificar posibles problemas. Para resolver la condición de carrera, usaría mecanismos de sincronización adecuados, como bloqueos (mutexes), semáforos u operaciones atómicas, para proteger los recursos compartidos y garantizar la seguridad de los hilos. Considere cuidadosamente el alcance de los bloqueos para evitar interbloqueos y asegurar la integridad de los datos. El uso de estructuras de datos concurrentes como colas concurrentes o mapas hash también puede reducir la probabilidad de condiciones de carrera.

Preguntas de entrevista sobre solución de problemas de Linux para expertos

1. ¿Cómo diagnosticaría una situación en la que un servicio crítico deja de ejecutarse inesperadamente, sin dejar mensajes de error inmediatamente obvios en sus registros?

Primero, verificaría el estado básico del sistema: uso de CPU, memoria, espacio en disco y conectividad de red. También verificaría si el servicio realmente se ha detenido utilizando herramientas del sistema como ps, systemctl status <servicio>, o similares. Si el servicio está caído, ampliaría mi búsqueda de registros más allá de los propios registros del servicio, buscando en los registros del sistema (/var/log/syslog, /var/log/messages, Visor de eventos de Windows) errores relacionados como eventos de OOM killer, pánicos del kernel o errores de E/S de disco que podrían haber precedido a la falla del servicio. Verificar las implementaciones recientes o los cambios de configuración también es fundamental. También verificaría las dependencias y los servicios externos utilizados por el servicio crítico.

Si las comprobaciones básicas no revelan la causa, investigaría posibles fugas de recursos o interbloqueos utilizando herramientas para examinar los patrones de consumo de recursos del servicio antes del fallo. Examinar los volcados de memoria si están disponibles o habilitar los volcados de memoria si aún no están habilitados puede ser invaluable para determinar el punto de fallo. Finalmente, consideraría aumentar temporalmente el nivel de registro del servicio (si es factible sin causar problemas de rendimiento) para capturar información más detallada sobre su comportamiento antes del próximo fallo potencial.

2. Explique su enfoque para solucionar problemas de un sistema que experimenta problemas intermitentes de conectividad de red.

Al solucionar problemas de conectividad de red intermitente, comenzaría por recopilar información: ¿Quiénes se ven afectados? ¿Qué aplicaciones se ven impactadas? ¿Cuándo comenzó el problema? ¿Hay algún patrón? Luego, verificaría la capa física (cables, conectores) y la conectividad básica de la red usando ping y traceroute para identificar dónde se interrumpe la conexión. Investigaría los registros de los dispositivos de red (enrutadores, conmutadores, cortafuegos) en busca de errores o configuraciones incorrectas, y analizaría el tráfico de red usando herramientas como Wireshark para identificar la pérdida de paquetes o patrones inusuales. Los problemas de DNS son un culpable común, por lo que verificaría la accesibilidad y resolución del servidor DNS. Finalmente, procedería probando diferente hardware para identificar el problema a un dispositivo o ubicación de red específica, y luego seguiría con una solución permanente.

3. Describe una situación en la que sospecha que una fuga de memoria está afectando el rendimiento del sistema. ¿Cómo confirmaría e identificaría el proceso con fugas?

Si el rendimiento de un sistema se degrada gradualmente con el tiempo sin ninguna razón aparente, y reiniciar el sistema resuelve temporalmente el problema, sospecharía una fuga de memoria. Observaría una alta utilización de la memoria utilizando herramientas como top o htop en Linux, o el Administrador de tareas en Windows. La memoria disponible disminuiría con el tiempo, incluso cuando el sistema está relativamente inactivo.

Para confirmar, usaría herramientas como valgrind en Linux o el Monitor de rendimiento en Windows para identificar el proceso específico que consume una cantidad excesiva de memoria. Revisaría los patrones de uso de memoria de los procesos y buscaría aquellos con un uso de memoria en constante aumento, especialmente aquellos sin un aumento correspondiente en la actividad. Analizar volcados de montón (heap dumps) puede ayudar a identificar la ubicación exacta de la fuga dentro del código del proceso. Herramientas como jmap y jhat para aplicaciones basadas en Java pueden ser útiles para identificar fugas de memoria.

4. Un usuario informa de un rendimiento lento de la aplicación. Guíeme a través de los pasos que tomaría para identificar el cuello de botella, considerando la CPU, la memoria, la E/S del disco y la red.

Primero, recopile información: nombre de la aplicación, usuarios afectados, hora de la ocurrencia, operaciones lentas específicas. Luego, supervise la utilización de recursos. Para la CPU, use herramientas como top o perf en Linux o el Administrador de tareas en Windows para identificar procesos con uso intensivo de CPU. Para la memoria, supervise el uso de memoria y busque un intercambio excesivo. Herramientas como free, vmstat o el monitor de recursos pueden ayudar. El alto rendimiento de E/S del disco se puede verificar con iotop en Linux o el Monitor de recursos en Windows; investigue consultas lentas u operaciones de archivos grandes. Los problemas de red se pueden diagnosticar usando ping, traceroute o tcpdump para verificar la latencia, la pérdida de paquetes y el ancho de banda de la red. Finalmente, analice los registros de la aplicación en busca de errores, advertencias o consultas lentas y correlacione el uso de recursos con el comportamiento de la aplicación. Si se sospecha de una parte específica del código, las herramientas de perfilado pueden identificar cuellos de botella.

5. ¿Cómo solucionaría una situación en la que un servidor Linux se está ejecutando, pero no puede acceder a él por SSH?

Primero, verificaría la conectividad de la red: ¿puedo hacer ping al servidor? Si el ping falla, el problema podría estar relacionado con la red (firewall, enrutamiento). Si el ping tiene éxito, el servidor es accesible, por lo que el problema es específico de SSH. Luego, verificaría si el servicio SSH se está ejecutando en el propio servidor. Si tengo acceso físico u otra forma de ejecutar comandos (por ejemplo, a través de una consola de administración), ejecutaría systemctl status sshd (o service ssh status) para confirmar que SSH está activo. Si no se está ejecutando, lo iniciaría con sudo systemctl start sshd. También, revisaría el archivo sshd_config (/etc/ssh/sshd_config) en busca de configuraciones incorrectas (como autenticación de contraseña deshabilitada, puerto incorrecto o acceso de usuario restringido). También podría verificar el firewall del servidor (usando iptables, firewalld, o ufw) para asegurar que el tráfico SSH (puerto 22 por defecto) no esté siendo bloqueado. Examinaría los registros SSH en el servidor (generalmente en /var/log/auth.log o /var/log/secure) en busca de mensajes de error relacionados con intentos de conexión o fallas de autenticación. Si la autenticación por contraseña está deshabilitada, confirmaría que estoy usando la clave SSH correcta y que está configurada correctamente tanto en el cliente como en el servidor. Finalmente, consideraría si existen restricciones de recursos en el servidor (alto uso de CPU/memoria) que podrían estar afectando la capacidad de respuesta de SSH.

6. Explique su metodología para diagnosticar y resolver un pánico del kernel.

Cuando me enfrento a un pánico del kernel, mi objetivo principal es recopilar la mayor cantidad de información posible sobre el contexto en el que ocurrió. Primero, examino cuidadosamente los mensajes de error del kernel en la consola o en los registros del sistema. El rastreo de la pila, si está disponible, es crucial. Ayuda a identificar la función o el módulo donde se originó el pánico. También presto atención a los códigos de error o valores de registro que se muestran. Las herramientas clave para una mayor depuración incluyen kdump y crash, que permiten el análisis post-mortem del estado de la memoria del sistema en el momento del fallo. Esto permite la inspección de variables, estructuras de datos e historial de llamadas a funciones. Los pasos para la resolución dependen de la causa, que podría implicar la aplicación de parches a controladores defectuosos, la corrección de errores del kernel o el ajuste de la configuración del sistema.

A continuación, intentaría reproducir el problema en un entorno controlado, si es posible. Esto ayuda a validar que la solución aborda la causa raíz. Los símbolos de depuración son esenciales para interpretar los rastros de la pila. Si el pánico se debe a un módulo de kernel personalizado, usaría herramientas de depuración como gdb o kgdb para recorrer el código e identificar la línea exacta que causa el problema. También verificaré los cambios recientes del sistema, las actualizaciones o las modificaciones de configuración que podrían desencadenar el pánico, posiblemente volviendo a un estado estable para la depuración y dividiendo cualquier cambio usando herramientas como git bisect.

7. Describa su proceso para identificar y mitigar un proceso descontrolado que consume recursos excesivos del sistema.

Primero, identificaría el proceso descontrolado usando herramientas como top, htop o ps combinado con grep y sort para señalar los procesos que consumen mucha CPU, memoria o E/S. Una vez identificado, analizaría los detalles del proceso, incluido su ID de proceso principal (PPID), los argumentos de la línea de comandos y el contexto del usuario para comprender su propósito y origen. Las herramientas de monitoreo de red como netstat o tcpdump también pueden revelar una actividad de red excesiva.

La mitigación implica varios pasos. Inicialmente, intentaría una terminación elegante usando kill -15 <PID>. Si eso falla, usaría kill -9 <PID> como último recurso. Posteriormente, investigaría la causa raíz. Esto podría implicar examinar registros, verificar trabajos cron o revisar el código recientemente implementado. Basado en los hallazgos, implementaría medidas preventivas como límites de recursos (usando ulimit o cgroups), parcheando vulnerabilidades de software o modificando las configuraciones de la aplicación para evitar la recurrencia. La configuración de sistemas de monitoreo y alerta asegura la identificación proactiva de problemas similares en el futuro.

8. ¿Cómo determinaría si un sistema ha sido comprometido por un rootkit y qué medidas tomaría para remediar la situación?

Para determinar si un sistema ha sido comprometido por un rootkit, emplearía varias técnicas. Esto incluye el uso de escáneres de rootkit (como chkrootkit o rkhunter), la realización de comprobaciones de integridad de los archivos del sistema (utilizando herramientas como AIDE), el análisis de los registros del sistema en busca de actividad sospechosa y el examen de los procesos en ejecución en busca de entradas inesperadas u ocultas. Además, compararía las sumas de comprobación de los binarios críticos del sistema con versiones buenas conocidas y buscaría inconsistencias en las tablas de llamadas al sistema. El análisis del tráfico de red en busca de patrones inusuales y la realización de volcado de memoria para su análisis también pueden revelar la presencia de rootkits.

Los pasos de remediación dependen de la gravedad y el tipo de rootkit. Generalmente, el enfoque más fiable es reformatear la unidad del sistema y reinstalar el sistema operativo desde una fuente confiable. Si eso no es factible de inmediato, intentaría aislar el sistema infectado de la red. Luego usaría herramientas especializadas anti-rootkit para intentar eliminar el malware, pero esto no siempre es fiable. Después de la remediación, se debe realizar una evaluación de vulnerabilidades exhaustiva y un proceso de endurecimiento para prevenir futuras infecciones, incluida la actualización de todo el software, la implementación de políticas de contraseñas seguras y el uso de un sistema de detección de intrusiones basado en el host (HIDS).

9. Sospecha que una llamada específica al sistema está fallando. ¿Cómo puede rastrear las llamadas al sistema realizadas por un proceso para verificar esto y comprender el fallo?

Para rastrear las llamadas al sistema, usaría strace. Ejecutaría strace -p <pid> para adjuntar a un proceso en ejecución o strace <comando> para rastrear un nuevo proceso. Filtraría la salida usando strace -e trace=<syscall> para centrarme en la llamada al sistema específica que sospecho que está fallando. Por ejemplo, si sospechara que open está fallando, usaría strace -e trace=open <comando>.

Analizar la salida de strace revela los argumentos pasados a la llamada al sistema, el valor de retorno y cualquier código de error (por ejemplo, ENOENT para "No existe el archivo o directorio"). Esto ayuda a comprender por qué la llamada al sistema falla, como parámetros incorrectos, problemas de permisos o limitaciones de recursos. También podría usar strace -t para agregar marcas de tiempo, strace -f para seguir los procesos secundarios o strace -o <nombre_archivo> para guardar la salida en un archivo para análisis posterior. Para una decodificación más detallada de los códigos de error, se puede usar la herramienta de línea de comandos errno, por ejemplo, errno 2 devuelve ENOENT.

10. Explique su enfoque para solucionar un problema de dependencia complejo que impide que una aplicación crítica se inicie.

Mi enfoque para solucionar un problema de dependencia complejo implica un proceso sistemático. Primero, identificaría la aplicación y sus dependencias utilizando la documentación, las herramientas de gestión de dependencias (como npm list, mvn dependency:tree o pip show) y los archivos de configuración de la aplicación. Luego, aislaría el componente que falla examinando los registros de la aplicación, los registros del sistema y usando herramientas de depuración. Me centraría en los mensajes de error relacionados con dependencias faltantes o incompatibles. Una vez aislado, reproduciría el problema en un entorno controlado, quizás una máquina de desarrollo local o un entorno de prueba, para experimentar de forma segura.

Luego, probaría sistemáticamente las versiones y configuraciones de las dependencias. Esto podría implicar la degradación o actualización de las dependencias, la comprobación de las matrices de compatibilidad y la verificación de los archivos de configuración para conocer las rutas y ajustes correctos. Las herramientas como los "dependency walkers" o las funciones de depuración de los marcos de inyección de dependencias pueden ser útiles aquí. También consideraría los problemas de conectividad de red si la dependencia es externa. Finalmente, documentaría la solución y actualizaría las configuraciones de gestión de dependencias para evitar que se repita. El monitoreo es importante para asegurar que las correcciones funcionen en producción.

11. Describa una vez que tuvo que depurar un script bash complejo. ¿Qué herramientas y técnicas utilizó?

En una ocasión, tuve que depurar un script bash complejo responsable de automatizar las implementaciones. El script fallaba de forma intermitente y los mensajes de error no eran informativos. Para abordar esto, empleé varias técnicas. Primero, agregué set -x para habilitar el rastreo detallado, que mostraba cada comando que se estaba ejecutando. Luego, inserté estratégicamente declaraciones echo para imprimir los valores de las variables en diferentes puntos, lo que me ayudó a rastrear el estado del script. También utilicé #!/bin/bash -xv para ejecutar el script.

Para una lógica más compleja, utilicé bashdb, el depurador de bash, para recorrer el código línea por línea, inspeccionar variables y establecer puntos de interrupción. Adicionalmente, utilicé shellcheck, una herramienta de análisis estático, para identificar posibles errores de sintaxis y problemas de estilo en el script. Finalmente, refactoricé partes del script en funciones más pequeñas y manejables para aislar la fuente del problema.

12. ¿Cómo aborda la solución de problemas de degradación del rendimiento en un entorno virtualizado?

La solución de problemas de degradación del rendimiento en un entorno virtualizado requiere un enfoque sistemático. Primero, identifique el alcance: ¿Es una sola VM, múltiples VMs en un host, o todo el entorno? Monitorice métricas clave como la utilización de la CPU, el uso de la memoria, la E/S del disco y la latencia de la red tanto a nivel de invitado como de host utilizando herramientas nativas del hipervisor (por ejemplo, Gráficos de rendimiento de vSphere, Monitor de rendimiento de Hyper-V). Busque contención de recursos o cuellos de botella.

A continuación, investigue las posibles causas basadas en las métricas. Los culpables comunes incluyen la sobreasignación de recursos (CPU, memoria), vecinos ruidosos que impactan la E/S, saturación de la red, problemas de rendimiento del almacenamiento (por ejemplo, SAN lento) y controladores o software de hipervisor desactualizados. Solucione el problema ajustando las asignaciones de recursos, migrando las máquinas virtuales a hosts menos congestionados, optimizando las configuraciones de almacenamiento y actualizando los componentes de software. Supervise continuamente después de cada cambio para verificar la mejora.

13. Explique cómo solucionaría una situación en la que un usuario no puede imprimir en una impresora de red.

Para solucionar el problema de un usuario que no puede imprimir en una impresora de red, comenzaría por verificar lo básico: ¿Está la impresora encendida y en línea? ¿Está la computadora del usuario conectada a la red? ¿Pueden otros usuarios imprimir en la misma impresora? A continuación, verificaría la computadora del usuario. ¿Está la impresora correcta seleccionada como predeterminada? ¿Están actualizados los controladores de la impresora? ¿Hay algo atascado en la cola de impresión? Intentaría borrar la cola de impresión, reiniciar el servicio de cola de impresión y reinstalar los controladores de la impresora si fuera necesario.

En el lado del servidor (si corresponde), verificaría el servidor de impresión para asegurarme de que se está ejecutando y que la impresora se comparte correctamente. Examinaría los registros de eventos tanto en la computadora del usuario como en el servidor de impresión en busca de mensajes de error relacionados con la impresión. Finalmente, verificaría que no haya problemas de conectividad de red que impidan la comunicación entre la computadora del usuario y la impresora. Puedo hacer ping a la dirección IP de la impresora y también probar las reglas del firewall para asegurarme de que el tráfico de impresión (puertos como 515, 9100) no esté bloqueado.

14. Un servidor de base de datos crítico está experimentando alta latencia. Describa sus pasos de solución de problemas.

Cuando me enfrento a una alta latencia en un servidor de base de datos crítico, primero confirmaría el problema monitoreando métricas clave como el tiempo de respuesta, la utilización de la CPU, el uso de la memoria, la E/S del disco y el tráfico de la red. Se podrían usar herramientas como top, iostat, vmstat y herramientas de monitoreo de red. Luego investigaría las posibles causas:

• Contención de recursos: Verifique los picos de CPU, la presión de la memoria (intercambio) y los cuellos de botella de E/S del disco. Identifique los procesos principales que consumen recursos.
• Problemas de red: Examine la latencia de la red entre el servidor de aplicaciones y el servidor de base de datos utilizando herramientas como ping o traceroute.
• Problemas de base de datos: Analice las consultas de ejecución lenta utilizando el analizador de consultas de la base de datos o el registro de consultas lentas. Verifique los bloqueos de tablas, los interbloqueos y los índices ineficientes. Examine los registros del servidor de base de datos en busca de errores.
• Agotamiento del grupo de conexiones: Verifique que la aplicación esté configurada correctamente para manejar el número apropiado de conexiones de base de datos.

Basado en los hallazgos, tomaría acciones correctivas como optimizar consultas, agregar índices, aumentar los recursos del servidor, resolver problemas de red o ajustar los parámetros de configuración de la base de datos. Después de cada cambio, monitorearía nuevamente las métricas para confirmar que la latencia se reduce.

15. ¿Cómo abordaría la solución de problemas en una situación en la que un servicio no se inicia después de reiniciar el sistema?

Al solucionar problemas de un servicio que no se inicia después de reiniciar, comenzaría por verificar el estado y los registros del servicio. systemctl status <nombre_del_servicio> mostrará si el servicio está activo, fallido o inactivo, junto con los registros recientes. Examinaría estos registros en busca de mensajes de error que indiquen por qué el servicio no pudo iniciarse, prestando atención a las dependencias que podrían no estar disponibles todavía.

Luego, verificaría que el servicio esté habilitado para iniciarse al arrancar usando systemctl is-enabled <nombre_del_servicio>. Si no está habilitado, lo habilitaría con systemctl enable <nombre_del_servicio>. También verificaría si hay errores en el archivo de configuración que podrían estar impidiendo que el servicio se inicie. Si los registros no proporcionan suficiente información, podría intentar iniciar el servicio manualmente en modo de depuración (si está disponible) para obtener una salida más detallada. Finalmente, revisaría los cambios o actualizaciones recientes del sistema que podrían haber introducido el problema.

16. Explique cómo solucionaría los problemas en una situación en la que el directorio de inicio de un usuario tiene permisos incorrectos.

Primero, recopilaría información: ¿qué está pasando, cuáles deberían ser los permisos y cuáles son ahora? Luego, usaría ls -ld /home/<nombre_de_usuario> para examinar los permisos y la propiedad actuales. El propietario correcto debería ser el usuario, y los permisos típicos son 700 (drwx------). Si el propietario es incorrecto, chown <nombre_de_usuario>:<nombre_de_usuario> /home/<nombre_de_usuario> lo corrige. Si los permisos son incorrectos, chmod 700 /home/<nombre_de_usuario> lo soluciona. Finalmente, corregiría recursivamente los permisos de los archivos y carpetas dentro del directorio de inicio usando chmod -R u=rwX,g=,o= /home/<nombre_de_usuario>. Esto asegura que el usuario tenga permisos de lectura/escritura/ejecución para sí mismo y que no haya permisos para el grupo u otros. También verificaría que ningún ACL esté interfiriendo con los permisos correctos de los archivos usando getfacl /home/<nombre_de_usuario>. Si se encuentran ACL y son problemáticos, deberían modificarse usando setfacl o eliminarse con setfacl -b.

Después de realizar los cambios, probaría cuidadosamente iniciando sesión como el usuario y verificando que pueda acceder a sus archivos, crear nuevos y que otros no puedan acceder a sus archivos. Es crucial hacer una copia de seguridad de los datos antes de realizar cambios potencialmente destructivos, particularmente cuando se trata de comandos recursivos. También documentaría los cambios realizados para referencia futura.

17. Describa su metodología para diagnosticar y resolver una situación en la que una matriz RAID está degradada.

Cuando me enfrento a una matriz RAID degradada, mi primer paso es siempre evaluar la situación. Esto implica verificar los registros del controlador RAID para obtener mensajes de error específicos que indiquen qué unidad(es) han fallado o están experimentando problemas. Usaría las herramientas apropiadas para el controlador RAID (por ejemplo, mdadm para RAID de software o utilidades específicas del proveedor para RAID de hardware) para obtener el estado de la matriz. Esto incluiría la identificación de la unidad defectuosa, su ubicación y el estado general de las unidades restantes. Luego intentaría eliminar de forma segura la unidad fallida de la matriz.

A continuación, reemplazaría la unidad fallida con una unidad nueva y compatible. Finalmente, iniciaría una reconstrucción de la matriz RAID utilizando las herramientas apropiadas. Durante todo el proceso, supervisaría de cerca el progreso de la reconstrucción para asegurar que no se produzcan más errores. Después de que se complete la reconstrucción, verificaría la integridad de los datos y la salud general de la matriz RAID. También podría ejecutar una verificación del sistema de archivos (por ejemplo, fsck) si hubiera alguna indicación de corrupción de datos.

18. ¿Cómo investigaría una situación en la que un servidor está experimentando una utilización de CPU inusualmente alta sin que ningún proceso obvio consuma recursos?

Primero, usaría top, htop o vmstat para confirmar la alta utilización de la CPU y buscar cualquier proceso oculto que pueda estar experimentando picos breves. Si no se ven procesos obvios, investigaría posibles problemas a nivel del kernel utilizando herramientas como perf o eBPF para perfilar la actividad del kernel e identificar la fuente del uso de la CPU. Buscaría un manejo excesivo de interrupciones, llamadas al sistema o problemas relacionados con los controladores. La entrada/salida de red o de disco también podría estar causando indirectamente un alto uso de la CPU si están experimentando problemas.

19. Explique cómo solucionaría un problema en el que un sitio web devuelve intermitentemente errores 502 Bad Gateway.

Para solucionar los errores intermitentes 502 Bad Gateway, comenzaría por investigar los componentes del lado del servidor. Primero, revisaría los registros del servidor de la aplicación (por ejemplo, servidor web, servidor de aplicaciones, servidor de base de datos) en busca de mensajes de error o excepciones que ocurran en el momento de los errores 502. El alto uso de CPU o memoria en el servidor también podría ser una causa. Luego, examinaría cualquier proxy inverso o equilibrador de carga frente a los servidores de aplicaciones para asegurarme de que funcionen correctamente y que los servidores de backend estén en buen estado. Herramientas como ping, traceroute y curl pueden ayudar a verificar la conectividad de la red y los tiempos de respuesta.

Si el problema no es inmediatamente evidente, habilitaría un registro más detallado en todos los servidores relevantes para capturar más información sobre las solicitudes y respuestas. Correlacionar estos registros con las marcas de tiempo de los errores 502 a menudo puede identificar la causa raíz. Los pasos adicionales incluirían revisar las implementaciones de código recientes o los cambios de configuración que podrían haber introducido el problema, y probar las dependencias de la aplicación (bases de datos, API) para descartar factores externos. Si un punto final específico desencadena los errores consistentemente, me enfocaría en el código responsable de manejar las solicitudes a ese punto final.

20. ¿Cómo diagnosticaría y resolvería una situación en la que un contenedor Docker no se inicia, pero los registros no proporcionan información suficiente?

Cuando un contenedor Docker no se inicia y los registros son insuficientes, comenzaría por verificar el estado del demonio Docker (systemctl status docker). Luego, inspeccionaría la configuración del contenedor usando docker inspect <container_id> para verificar el nombre de la imagen, el punto de entrada, las variables de entorno, los volúmenes y la configuración de la red en busca de cualquier configuración incorrecta. Los problemas de red son causas comunes, por lo que verificaría si el contenedor intenta enlazar a un puerto ya en uso o tiene problemas para resolver DNS. También verificaría las restricciones de recursos (CPU, memoria) configuradas para el contenedor.

Si los pasos anteriores no revelan el problema, crearía un Dockerfile mínimo basado en la misma imagen base y agregaría capas incrementalmente desde el Dockerfile original para aislar qué capa está causando la falla de inicio. Podría usar la función de verificación de estado en Docker para obtener un estado de salud más detallado. Finalmente, podría intentar ejecutar el contenedor con registros o opciones de depuración aumentadas (si la aplicación dentro lo admite) y examinar los registros del sistema del host (journalctl -u docker.service) en busca de pistas. Si nada de lo anterior ayuda, ejecutaría la imagen localmente en modo interactivo (docker run -it <image> bash) para tratar de identificar la causa de la falla a través de la inspección directa y la ejecución de comandos.

Solución de problemas de Linux MCQ

Pregunta 1.

Un usuario informa que no puede acceder a un sitio web específico (www.example.com) desde su estación de trabajo Linux. Puede hacer ping a la dirección IP del sitio web con éxito, pero ping www.example.com falla. ¿Cuál es la causa MÁS probable del problema?

Opciones:

Opciones:

La interfaz de red está inactiva.

Hay un problema con la configuración DNS del sistema.

El servidor web está inactivo.

La cuenta del usuario está bloqueada.

Pregunta 2.

Un servidor Linux experimenta un alto uso de CPU, lo que causa problemas de rendimiento. ¿Qué comando sería MÁS útil para identificar el proceso o procesos específicos responsables de consumir la mayor cantidad de recursos de CPU?

Opciones:

Opciones:

`ls -lht`

`df -h`

`top`

`netstat -an`

Pregunta 3.

¿Dónde se registran típicamente los mensajes relacionados con el kernel en un sistema Linux?

Opciones:

/var/log/kern.log

/var/log/syslog

/var/log/messages

/var/log/dmesg

Pregunta 4.

Un usuario informa que no puede guardar ningún archivo nuevo en su sistema. Tras la investigación, sospecha un problema de espacio en disco. ¿Qué comando sería MÁS apropiado para identificar rápidamente qué directorio está consumiendo la mayor cantidad de espacio en disco?

Opciones:

ls -lht

df -h

du -hsx /* | sort -rh | head -10

cat /proc/meminfo

Pregunta 5.

Un servidor Linux está experimentando una degradación del rendimiento. Sospecha que un solo proceso está consumiendo memoria excesiva. ¿Qué comando utilizaría para identificar el proceso con la mayor utilización de memoria?

Opciones:

ps aux --sort=-%cpu | head

top -o %MEM | head

df -h

netstat -tulnp

Pregunta 6.

Un usuario informa que no puede modificar un archivo que posee. Después de verificar, confirma que es el propietario y no hay ACL en su lugar. ¿Cuál de las siguientes es la causa MÁS probable?

Opciones:

El atributo inmutable del archivo está configurado.

El archivo está actualmente abierto por otro proceso.

El sistema de archivos está montado de solo lectura.

La cuenta del usuario está bloqueada.

Pregunta 7.

Un servicio crítico no se inicia al arrancar. Necesita diagnosticar la razón de la falla. ¿Cuál de los siguientes es el primer paso MÁS apropiado?

Opciones:

Verifique el uso de la CPU del sistema para identificar posibles conflictos de recursos.

Examine el archivo de configuración del servicio en busca de errores de sintaxis o configuraciones incorrectas.

Inspeccione los registros del diario systemd para el servicio para identificar mensajes de error durante el inicio.

Reinstale el paquete del servicio para asegurarse de que todos los archivos estén presentes.

Pregunta 8.

Un usuario informa que no puede acceder a sitios web por nombre (por ejemplo, google.com), pero puede acceder a ellos por dirección IP. ¿Cuál de las siguientes es la causa más probable de este problema?

Opciones:

Opciones:

La puerta de enlace predeterminada del usuario está mal configurada.

El servidor DNS del sistema no está configurado correctamente o no es accesible.

La caché del navegador web está dañada.

El cortafuegos del sistema está bloqueando el tráfico HTTP.

Pregunta 9.

No puede conectarse a un servidor Linux remoto mediante SSH. El mensaje de error indica un rechazo de conexión. ¿Cuál de las siguientes es la causa MÁS probable?

Opciones:

El cliente SSH está usando un nombre de usuario incorrecto.

El servicio SSH no se está ejecutando en el servidor remoto, o un cortafuegos está bloqueando el puerto 22.

El reloj del sistema del servidor remoto está desincronizado.

El archivo de configuración del cliente SSH se ha corrompido.

Pregunta 10.

Una aplicación no está escribiendo archivos en un directorio específico. Ha confirmado que la aplicación se está ejecutando y el directorio existe. ¿Cuál de las siguientes es la causa MÁS probable de este problema?

Opciones:

Opciones:

La aplicación no está instalada correctamente.

La cuenta de usuario que ejecuta la aplicación no tiene permisos de escritura en el directorio.

El cortafuegos del sistema está bloqueando el acceso de la aplicación al directorio.

El disco que contiene el directorio está lleno.

Pregunta 11.

Una aplicación crítica está terminando inesperadamente en su servidor Linux. Después de revisar los registros del sistema, observa entradas de 'Out of Memory Killer' (OOM Killer) relacionadas con el proceso. ¿Cuál de las siguientes acciones es el primer paso MÁS apropiado para diagnosticar y mitigar este problema?

Opciones:

Deshabilitar el OOM Killer para evitar que finalice los procesos.

Aumentar el espacio de intercambio para proporcionar más memoria virtual.

Disminuir el valor de swappiness para obligar al sistema a usar la RAM de forma más agresiva.

Desinstalar la aplicación, ya que está claramente defectuosa.

Pregunta 12.

Un usuario informa un rendimiento lento de la red al transferir archivos grandes. ¿Cuál de las siguientes es la causa MÁS probable si otros servicios de red funcionan normalmente?

Opciones:

Configuración incorrecta del servidor DNS.

Desajuste dúplex de la interfaz de red.

Firewall bloqueando el tráfico SSH.

Espacio en disco insuficiente en el servidor receptor.

Pregunta 13.

Un usuario no puede instalar un paquete usando apt install <nombre_del_paquete>. La instalación falla con un error que indica dependencias incumplidas. ¿Cuál de las siguientes es la causa MÁS probable?

Opciones:

El reloj del sistema no está sincronizado con un servidor de tiempo.

La lista de repositorios de paquetes está desactualizada o contiene entradas incorrectas.

El usuario no tiene suficiente espacio en disco en el directorio /tmp.

El archivo de bloqueo del administrador de paquetes está corrupto.

Pregunta 14.

Un sistema Linux no arranca. Después de la investigación, ve el siguiente mensaje de error en la pantalla: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0). ¿Cuál de las siguientes es la causa MÁS probable de este problema?

Opciones:

El sistema de archivos raíz está corrupto.

Hay un problema con la configuración del espacio de intercambio.

El nombre de host del sistema está configurado incorrectamente.

El directorio de inicio de un usuario está lleno.

Pregunta 15.

Un usuario informa que no puede iniciar sesión en un sistema Linux. Después de verificar que el nombre de usuario y la contraseña son correctos, ¿cuál es la causa MÁS probable y cómo solucionaría inicialmente este problema?

Opciones:

Configuración SSH incorrecta; Verifique `/etc/ssh/sshd_config` para ver si hay configuraciones incorrectas.

Directorio personal de usuario corrupto; Verifique si hay errores en el sistema de archivos y restaure desde la copia de seguridad.

Configuración de PAM que impide el acceso; Verifique `/var/log/secure` o `/var/log/auth.log` y los archivos de configuración de PAM relacionados en `/etc/pam.d/` en busca de errores de autenticación.

El cortafuegos está bloqueando los intentos de inicio de sesión; Verifique las reglas de `iptables` o `firewalld` para asegurarse de que se permita el tráfico de inicio de sesión.

Pregunta 16.

Una aplicación no se puede conectar a un servidor de base de datos en la misma red. Puede hacer ping al servidor de base de datos, pero los registros de la aplicación muestran 'Conexión rechazada'. ¿Cuál de las siguientes es la causa MÁS probable?

Opciones:

La aplicación está configurada para usar un número de puerto de base de datos incorrecto.

El cortafuegos del servidor de base de datos está bloqueando las conexiones desde el servidor de la aplicación.

El resolvedor DNS del servidor de aplicaciones no está configurado correctamente.

La aplicación está utilizando una versión desactualizada de la biblioteca cliente de la base de datos.

Pregunta 17.

Un servidor Linux se apagó inesperadamente. Después de un reinicio, necesita determinar la causa del apagado. ¿Qué archivo de registro sería MÁS útil para diagnosticar el problema?

Opciones:

Opciones:

/var/log/auth.log

/var/log/syslog

/var/log/dpkg.log

/var/log/cron.log

Pregunta 18.

Una aplicación está experimentando un rendimiento lento. La investigación inicial sugiere un posible cuello de botella de E/S. ¿Cuál de las siguientes herramientas es la MEJOR para identificar qué proceso está generando la mayor actividad de E/S?

Opciones:

top

vmstat

iotop

free

Pregunta 19.

Un usuario informa que no puede imprimir en una impresora de red. Otros usuarios de la misma red pueden imprimir sin problemas. ¿Cuál es la causa MÁS probable?

Opciones:

El controlador de la impresora está dañado en la máquina del usuario.

La impresora no tiene tóner.

El cable de red conectado a la impresora es defectuoso.

El servidor de impresión está sobrecargado.

Pregunta 20.

Una aplicación se bloquea consistentemente con un fallo de segmentación. Necesita analizar el fallo para identificar la causa. ¿Cuál de los siguientes es el primer paso MÁS eficaz para diagnosticar el problema en un sistema Linux?

Opciones:

Examina la utilización de la CPU del sistema usando `top` o `htop`.

Verifica los archivos de registro de la aplicación en busca de mensajes de error o trazas de la pila.

Usa `ping` para probar la conectividad de la red.

Ejecuta `df -h` para verificar la utilización del espacio en disco.

Pregunta 21.

Un usuario informa que no puede acceder a un sitio web alojado en un servidor Linux. Otros usuarios también están experimentando el mismo problema. Ha confirmado que el servidor está funcionando y tiene conectividad de red. ¿Cuál de las siguientes es la causa MÁS probable de la inaccesibilidad del sitio web?

Opciones:

El proceso del servidor web (por ejemplo, Apache, Nginx) no se está ejecutando o no está escuchando en el puerto correcto.

La máquina local del usuario está infectada con un virus.

El nombre de host del sistema es incorrecto.

El kernel está desactualizado y necesita ser actualizado.

Pregunta 22.

Una aplicación no se inicia y muestra un mensaje de error que indica que falta una biblioteca compartida. ¿Cuál de los siguientes es el primer paso MÁS apropiado para diagnosticar y resolver este problema?

Opciones:

Reinstale todo el sistema operativo para asegurarse de que todas las bibliotecas estén presentes.

Usa el comando `ldd` en el ejecutable de la aplicación para identificar la biblioteca que falta, luego usa el administrador de paquetes del sistema (por ejemplo, `apt`, `yum`, `dnf`) para instalar el paquete que contiene la biblioteca que falta.

Copia todos los archivos `.so` de `/lib` y `/usr/lib` al directorio de la aplicación.

Deshabilita SELinux o AppArmor para permitir que la aplicación acceda a cualquier biblioteca.

Un usuario informa problemas intermitentes de conectividad de red. A veces puede acceder a sitios web y recursos de red, pero en otras ocasiones, la conexión se interrumpe por completo. ¿Cuál de los siguientes es el primer paso MÁS probable para diagnosticar este problema?

Opciones:

Verifique el archivo de nombre de host del sistema en busca de entradas incorrectas.

Use `ping` o `traceroute` para identificar posibles puntos de falla y pérdida de paquetes a lo largo de la ruta de la red.

Examine los registros del kernel del sistema en busca de eventos de limitación de la CPU.

Ejecute `fsck` en todos los sistemas de archivos montados para verificar errores.

Pregunta 24.

Varias aplicaciones se ejecutan lentamente y sospecha un alto uso de la CPU. Cuando ejecuta top, ve múltiples procesos con porcentajes de CPU consistentemente altos. ¿Qué comando proporciona un desglose más detallado del uso de la CPU por proceso, incluidos los subprocesos individuales?

Opciones:

ps aux

vmstat 1

htop

free -m

Pregunta 25.

Un usuario informa que un script bash llamado myscript.sh no se ejecuta. Cuando ejecutan ./myscript.sh, reciben un error "Permiso denegado" o "No existe el archivo o el directorio". ¿Cuál de las siguientes es la causa MÁS probable? opciones:

Opciones:

El script no tiene permisos de ejecución.

El script requiere privilegios de root para ejecutarse.

La línea shebang del script es incorrecta o falta.

La variable de entorno PATH del usuario no está configurada correctamente.

¿Qué habilidades de solución de problemas de Linux debería evaluar durante la fase de entrevista?

No se puede evaluar todo en una entrevista, pero centrarse en áreas clave puede revelar la destreza de un candidato para solucionar problemas de Linux. Aquí están las habilidades principales para evaluar y medir las habilidades de solución de problemas de Linux del candidato.

Conocimiento del sistema

Para medir su conocimiento del sistema, utilice una prueba de evaluación de habilidades con preguntas de opción múltiple (MCQ) relevantes. Nuestra prueba en línea de Linux puede ayudarle a filtrar a los candidatos con una base sólida.

Para evaluar su comprensión, haga preguntas específicas durante la entrevista.

Explique la diferencia entre un enlace duro y un enlace simbólico en Linux.

Busque candidatos que puedan articular claramente las diferencias, incluyendo cómo afectan el acceso y la eliminación de archivos, y los casos de uso potenciales.

Resolución de problemas

Evalúe su aptitud para la resolución de problemas con preguntas que exijan pensamiento crítico. También puede considerar el uso de nuestras pruebas de Razonamiento Lógico o Pensamiento Crítico.

Pregúnteles sobre su enfoque para resolver problemas con el fin de evaluar sus habilidades de resolución de problemas.

Describa una situación en la que se encontró con un escenario de solución de problemas de Linux particularmente difícil. ¿Qué medidas tomó para diagnosticar y resolver el problema?

Preste atención a un enfoque estructurado, a la capacidad del candidato para aislar el problema y a su ingenio para buscar soluciones. ¿Mostraron atención al detalle?

Dominio de la línea de comandos

Evalúe su familiaridad con los comandos comunes de Linux con una prueba de evaluación de habilidades. Puede explorar nuestra evaluación de Shell Scripting para evaluar sus habilidades en la línea de comandos.

Plantee un escenario que requiera conocimientos de la línea de comandos para ver cómo responden.

¿Cómo usaría la línea de comandos para identificar el proceso que está consumiendo la mayor cantidad de recursos de la CPU?

Busque candidatos que puedan usar comandos como top, ps o htop y que entiendan cómo interpretar la salida para identificar procesos que consumen muchos recursos.

Optimice la adquisición de talentos para la resolución de problemas de Linux con pruebas de habilidades

Al contratar para roles de resolución de problemas de Linux, es fundamental evaluar con precisión las habilidades de los candidatos. Asegurarse de que posean las habilidades requeridas puede mejorar significativamente el rendimiento del equipo y reducir el tiempo de incorporación.

El uso de pruebas de habilidades proporciona una forma eficiente de validar la competencia de un candidato. Considere aprovechar nuestra Prueba en línea de Linux o Prueba en línea de administración de sistemas para una evaluación exhaustiva.

Una vez que haya utilizado las pruebas de habilidades para identificar a los mejores, puede preseleccionar con confianza a los candidatos para las entrevistas. Concentre sus esfuerzos de entrevista en los candidatos que hayan demostrado una sólida comprensión de los principios de resolución de problemas de Linux.

¿Está listo para encontrar al experto en resolución de problemas de Linux adecuado? Visite nuestra Plataforma de evaluación en línea para obtener más información y comenzar. También puede registrarse directamente.

Prueba en línea de Linux

30 minutos | 12 preguntas de opción múltiple

La prueba en línea de Linux utiliza preguntas de opción múltiple (MCQ) basadas en escenarios para evaluar a los candidatos sobre su conocimiento del sistema operativo Linux, incluida su competencia en el uso de comandos de Linux, el sistema de archivos, las redes, la creación de scripts de shell y la administración de Linux. La prueba tiene como objetivo evaluar la capacidad de un candidato para trabajar con el sistema operativo Linux de manera eficiente y efectiva, así como para diseñar y mantener sistemas basados en Linux.

Prueba Linux en línea

Descargar la plantilla de preguntas de entrevista de solución de problemas de Linux en múltiples formatos

Preguntas frecuentes sobre preguntas de entrevista de solución de problemas de Linux

Las preguntas básicas a menudo cubren comandos fundamentales, navegación del sistema de archivos y gestión de usuarios. Estas evalúan la familiaridad de un candidato con los conceptos básicos de Linux.

Las preguntas intermedias exploran la gestión de procesos, los conceptos de red y el análisis de registros. Miden la capacidad de un candidato para diagnosticar problemas más complejos.

Las preguntas avanzadas a menudo involucran la depuración del kernel, la optimización del rendimiento y problemas relacionados con la seguridad. Estas preguntas evalúan una comprensión profunda.

Las preguntas de nivel experto suelen implicar el diseño de la arquitectura, la creación de scripts para la automatización y una inmersión profunda en nuevas funciones o cambios importantes.

Las pruebas de habilidades proporcionan una evaluación objetiva de las capacidades prácticas de un candidato, ahorrando tiempo y mejorando la precisión del proceso de contratación.