Administracion del sistema

Guía de solución de problemas GNU/Linux General para principiantes

Guía de solución de problemas GNU/Linux General para principiantes

En esta guía, nuestro objetivo es aprender sobre las herramientas y el entorno proporcionados por un sistema típico de GNU/Linux para poder comenzar la solución de problemas incluso en una máquina desconocida.
En este tutorial aprenderás:

  • Cómo verificar el espacio del disco
  • Cómo verificar el tamaño de la memoria
  • Cómo verificar la carga del sistema
  • Cómo encontrar y matar procesos del sistema
  • Cómo los registros de usuarios para encontrar información relevante de solución de problemas del sistema
Guía de solución de problemas GNU/Linux General para principiantes

Requisitos y convenciones de software utilizados

Requisitos de software y convenciones de línea de comandos de Linux
Categoría Requisitos, convenciones o versión de software utilizada
Sistema Ubuntu 20.04, Fedora 31
Software N / A
Otro Acceso privilegiado a su sistema Linux como root o a través del sudo dominio.
Convenciones # - requiere que los comandos de Linux dados se ejecuten con privilegios raíz directamente como un usuario raíz o mediante el uso de sudo dominio
ps - Requiere que los comandos de Linux dados se ejecuten como un usuario regular no privilegiado

Introducción

Si bien GNU/Linux es conocido por su estabilidad y robustez, hay casos en los que algo puede salir mal. La fuente del problema puede ser interna y externa. Por ejemplo, puede haber un proceso de mal funcionamiento que se ejecuta en el sistema que come recursos, o un disco duro antiguo puede ser defectuoso, lo que resulta en errores de E/S reportados.

En cualquier caso, necesitamos saber dónde mirar y qué hacer para obtener información sobre la situación, y esta guía está tratando de proporcionar casi eso, una forma general de hacer que la idea se haya equivocado. La resolución de cualquier problema comienza con conocer el problema, encontrar los detalles, encontrar la causa raíz y resolverlo. Como con cualquier tarea, GNU/Linux proporciona innumerables herramientas para ayudar al progreso, este es el caso en la solución de problemas también. Los siguientes consejos y métodos son solo algunos comunes que pueden usarse en muchas distribuciones y versiones.

Síntomas

Supongamos que tenemos una buena computadora portátil en la que trabajamos. Está ejecutando el último Ubuntu, Centos o Red Hat Linux, con actualizaciones siempre para mantener todo fresco. La computadora portátil es para uso general diario: procesamos correos electrónicos, chatea, navegamos por Internet, tal vez produzca algunas hojas de cálculo, etc. No se instala nada especial, una suite de oficina, un navegador, un cliente de correo electrónico, etc. De un día a otro, de repente la máquina se vuelve extremadamente lenta. Ya trabajamos en ello durante aproximadamente una hora, por lo que no es un problema después del arranque. Lo que está sucediendo… ?

Verificación de recursos del sistema

GNU/Linux no se vuelve lento sin una razón. Y lo más probable es que nos dirá dónde duele, siempre y cuando sea capaz de responder. Al igual que con cualquier programa que se ejecute en una computadora, el sistema operativo utiliza recursos del sistema, y ​​con aquellos que se ejecutan gruesos, las operaciones tendrán que esperar hasta que haya suficientes para continuar. Esto hará que las respuestas se vuelvan cada vez más lentas, por lo que si hay un problema, siempre es útil verificar el estado de los recursos del sistema. En general, nuestros recursos (locales) del sistema consisten en disco, memoria y CPU. Vamos a verlos todos.

Espacio del disco

Si el sistema operativo en ejecución está fuera del espacio en disco, son malas noticias. Como los servicios que se ejecutan no pueden escribir sus archivos de registro, se bloquearán en su mayoría si se ejecutan o no comenzarán si los discos ya están llenos. Además de los archivos de registro, los enchufes y los archivos PID (identificador de proceso) deben escribirse en el disco, y aunque estos son de tamaño pequeño, si no hay absolutamente más espacio, estos no se pueden crear.

Para verificar el espacio de disco disponible que podemos usar df en la terminal y agregar -H argumento, para ver los resultados redondeados a megabytes y gigabytes. Para nosotros, las entradas de interés serían volúmenes que han usado% del 100%. Eso significaría que el volumen en cuestión está lleno. La siguiente salida de ejemplo muestra que estamos bien con respecto al espacio en disco:

$ DF -H Tamaño del sistema de archivos Usado disponible% Montado en devTMPFS 1.8g 0 1.8g 0% /dev tmpfs 1.8g 0 1.8g 0% /dev /shm tmpfs 1.8G 1.3m 1.8g 1% /run /dev /mapper /lv-raot 49g 11g 36g 24% /tmpfs 1.8g 0 1.8g 0% /tmp /dev /sda2 976m 261m 649m 29% /boot /dev /mapper /lv-home 173g 18g 147g 11% /home tmpfs 361m 4.0K 361m 1%/ejecución/usuario/1000
Copiar

Entonces tenemos espacio en el disco (s). Tenga en cuenta que en nuestro caso de la computadora portátil lenta, el agotamiento del espacio del disco no es la causa raíz. Cuando los discos están llenos, los programas se bloquearán o no comenzarán en absoluto. En un caso extremo, incluso el inicio de sesión fallará después del arranque.

Memoria

La memoria también es un recurso vital, y si estamos por debajo, el sistema operativo puede necesitar escribir piezas actualmente no utilizadas en el disco temporal (también llamado "intercambio") para dar la memoria liberada al siguiente proceso, luego leer De vuelta cuando el proceso que posee el contenido intercambiado lo necesita nuevamente. Todo este método llamado intercambio, y de hecho ralentizará el sistema, ya que escribir y leer hacia y desde los discos son mucho más lentos que trabajar dentro de la RAM.

Para verificar el uso de la memoria, tenemos el Handy gratis comandar que podemos agregar con argumentos para ver los resultados en megabytes (-metro) o gigabytes (-gramo)

$ Free -M Total usado Usado Buff/caché compartido gratis MEM: 7886 3509 1547 1231 2829 2852 Swap: 8015 0 8015
Copiar

En el ejemplo anterior tenemos 8 GB de memoria, 1,5 GB gratis y alrededor de 3 GB en cachés. El gratis El comando también proporciona el estado del intercambio: En este caso, está perfectamente vacío, lo que significa que el sistema operativo no necesitaba escribir ningún contenido de memoria en el disco desde el inicio, ni siquiera en las cargas máximas. Esto generalmente significa que tenemos más memoria que realmente usamos. Entonces, con respecto a la memoria, somos más que buenos, tenemos mucho.

Carga del sistema

Como los procesadores realizan los cálculos reales, quedarse sin tiempo de procesador para calcular puede provocar nuevamente la desaceleración del sistema. Los cálculos necesarios deben esperar hasta que cualquier procesador tenga el tiempo libre para calcularlos. La forma más fácil de ver la carga en nuestros procesadores es el tiempo de actividad dominio:

$ tiempo de actividad 12:18:24 Up 4:19, 8 usuarios, promedio de carga: 4,33, 2,28, 1,37
Copiar

Los tres números después de la carga promedio significa promedio en los últimos 1, 5 y 15 minutos. En este ejemplo, la máquina tiene 4 núcleos de CPU, por lo que estamos tratando de usar más de nuestra capacidad real. Observe también que los valores históricos muestran que la carga está aumentando significativamente en los últimos minutos. Tal vez encontramos al culpable?

Los principales procesos del consumidor

Veamos la imagen completa de la CPU y el consumo de memoria, con los procesos superiores utilizando estos recursos. Podemos ejecutar el arriba Comando para ver la carga del sistema en (cerca) en tiempo real:

Verificar los mejores procesos de consumidores.

La primera línea de la parte superior es idéntica a la salida de tiempo de actividad, A continuación podemos ver el número si se ejecutan, durmiendo, etc. Tenga en cuenta el recuento de procesos zombie (desfuncionales); Este caso es 0, pero si hubiera algunos procesos en el estado de zombie, deben investigarse. La siguiente línea muestra la carga en las CPU en porcentaje, y los porcentajes acumulados de exactamente qué Los procesadores están ocupados con. Aquí podemos ver que los procesadores están ocupados sirviendo programas de espacio de usuario.

A continuación se presentan dos líneas que pueden ser familiares desde el gratis salida, el uso de la memoria si el sistema. Debajo de estos están los procesos superiores, ordenados por el uso de la CPU. Ahora podemos ver qué está comiendo nuestros procesadores, es Firefox en nuestro caso.

Procesos de verificación

¿Cómo sé eso, ya que el proceso de consumo superior se muestra como "contenido web" en mi arriba producción? Mediante el uso PD Para consultar la tabla de proceso, utilizando el PID que se muestra al lado del proceso superior, que es en este caso 5785:

$ PS -EF | GREP 5785 | Grep -V "Grep" Sandmann 5785 2528 19 18:18 TTY2 00:00:54/usr/lib/firefox/firefox -ContentProc -Childid 13 -ISforbrowser -Prefslen 9825 -PrefMapsize 226230 -ParentBuildid 20200720193547 --apapdir/liB/LIB/LIB/LIB/LIB/LIB/LIB/LIB/LIB/LIB/LIB/LIB/LIB/LIB Firefox/Browser 2528 Pestaña Verdadero

Con este paso encontramos la causa raíz de nuestra situación. Firefox está comiendo nuestro tiempo de CPU hasta el punto de que nuestro sistema comienza a responder a nuestras acciones más lento. Esto no es necesariamente culpa del navegador,
Debido a que Firefox está diseñado para mostrar páginas de la World Wide Web: para crear un problema de CPU con el propósito de demostración, todo lo que hice es abrir algunas docenas de instancias de una página de prueba de estrés en distintas pestañas del navegador hasta el punto de la escasez de CPU superficie. Así que no necesito culpar a mi navegador, sino a mí mismo por abrir páginas hambrientas de recursos y dejarlas en funcionamiento en paralelo. Al cerrar algunos, mi CPU
El uso vuelve a la normalidad.

Destrucción de procesos

El problema y la solución se descubren anteriormente, pero ¿qué pasa si no puedo acceder al navegador para cerrar algunas pestañas?? Digamos que mi sesión gráfica está bloqueada y no puedo volver a iniciar sesión, o un general
Proceso que se ha vuelto salvaje ni siquiera tiene ninguna interfaz donde podamos cambiar su comportamiento? En tal caso, podemos emitir el cierre del proceso por parte del sistema operativo. Ya conocemos el pid del
proceso deshonesto con el que tenemos PD, y podemos usar el matar Comandar para apagarlo:

$ Kill 5785

Los procesos de bienestar saldrán, algunos no pueden. Si es así, agregar el -9 La bandera forzará la terminación del proceso:

$ Kill -9 5785

Tenga en cuenta que esto puede causar pérdida de datos, porque el proceso no tiene tiempo para cerrar archivos abiertos o terminar de escribir sus resultados para el disco en absoluto. Pero en el caso de alguna tarea repetible, la estabilidad del sistema puede tener prioridad sobre la pérdida de algunos de nuestros resultados.

Encontrar información relacionada

Interactuar con procesos con algún tipo de interfaz no siempre es el caso, y muchas aplicaciones solo tienen comandos básicos que controlan su comportamiento, a saber, iniciar, detener, recargar y tal, porque sus trabajos internos son proporcionados por su configuración. El ejemplo anterior fue más de escritorio, veamos un ejemplo del lado del servidor, donde tenemos un problema con un servidor web.

Supongamos que tenemos un servidor web que sirve algo de contenido al mundo. Es popular, por lo que no es una buena noticia cuando recibimos una llamada de que nuestro servicio no está disponible. Podemos verificar la página web en un navegador solo para obtener un mensaje de error que diga "No se puede conectar". Veamos la máquina que ejecuta el servidor web!

Referencia de archivos de registro

Nuestra máquina aloja el servidor web es una caja de Fedora. Esto es importante debido a las rutas del sistema de archivos que debemos seguir. Fedora, y todas las otras variantes de Red Hat almacenan los archivos de registro del servidor web de Apache en la ruta /var/log/httpd. Aquí podemos consultar el registro de errores usando vista, pero no encuentre ninguna información relacionada sobre cuál podría ser el problema. La verificación de los registros de acceso tampoco muestra ningún problema a primera vista, pero pensar dos veces nos dará una pista: en un servidor web con tráfico lo suficientemente bueno, las últimas entradas del registro de acceso deberían ser muy recientes, pero la última entrada ya tiene una hora de edad. Sabemos por experiencia que el sitio web recibe visitantes cada minuto.

System

Nuestra instalación de Fedora usa system como sistema init. Consultemos algo de información sobre el servidor web:

# systemCTL status httpd ● httpd.Servicio: el servidor apache http cargado: cargado (/usr/lib/systemd/system/httpd.servicio; desactivado; Vendor preestablecido: deshabilitado) Drop-in:/usr/lib/systemd/system/httpd.servicio.D └─PhP-FPM.conf activo: fallido (resultado: señal) desde el domingo 2020-08-02 19:03:21 cest; Docios de hace 3min 5s: Hombre: httpd.Servicio (8) Proceso: 29457 Execstart =/usr/sbin/httpd $ options -dforeground (code = killed, señal = kill) pid principal: 29457 (código = killed, señal = kill) Estado: "Solicitudes totales: 0; inactividad; /Trabajadores ocupados 100/0; solicitudes/sec: 0; bytes servidos/seg: 0 b/seg "CPU: 74ms agosto 02 19:03:21 myWebServer1.Foobar Systemd [1]: httpd.Servicio: Proceso de asesinato 29665 (N/A) con señal Sigkill. 02 de agosto 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Servicio: Proceso de asesinato 29666 (N/A) con señal Sigkill. 02 de agosto 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Servicio: Proceso de asesinato 29667 (N/A) con señal Sigkill. 02 de agosto 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Servicio: Proceso de asesinato 29668 (N/A) con señal Sigkill. 02 de agosto 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Servicio: Proceso de asesinato 29669 (N/A) con señal Sigkill. 02 de agosto 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Servicio: Proceso de asesinato 29670 (N/A) con Signal Sigkill. 02 de agosto 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Servicio: Proceso de asesinato 29671 (N/A) con señal Sigkill. 02 de agosto 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Servicio: Proceso de asesinato 29672 (N/A) con Signal Sigkill. 02 de agosto 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Servicio: Proceso de asesinato 29673 (N/A) con señal Sigkill. 02 de agosto 19:03:21 mywebserver1.Foobar Systemd [1]: httpd.Servicio: Falló con el resultado 'señal'.
Copiar

El ejemplo anterior es nuevamente uno simple, el httpd Proceso principal hacia abajo porque recibió una señal de matar. Puede haber otro Sysadmin que tenga el privilegio de hacerlo, para que podamos verificar quién
iniciado sesión (o estaba en el momento del cierre contundente del servidor web), y pregúntele sobre el problema (una parada de servicio sofisticada habría sido menos brutal, por lo que debe haber una razón detrás de esto
evento). Si somos los únicos administradores en el servidor, podemos verificar de dónde proviene esa señal: podemos tener un problema de violación o el sistema operativo envió la señal de asesinato. En ambos casos podemos usar el
archivos de registro del servidor, porque ssh Los inicios de sesión se registran en los registros de seguridad (/var/log/seguro en el caso de Fedora), y también hay entradas de auditoría que se encuentran en el registro principal (que es
/var/log/mensajes en este caso). Hay una entrada que nos dice lo que sucedió en este último:

2 de agosto 19:03:21 MyWebServer1.Auditoría de Foobar [1]: Service_Stop Pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = "unit = httpd comx =" systemd "exe ="/usr/lib/systemd "hostname = =? ADDR =? Terminal =? res = fallido "

Conclusión

Para fines de demostración, maté el proceso principal de mi propio servidor de laboratorio en este ejemplo. En un problema relacionado con el servidor, la mejor ayuda que podemos obtener rápido es verificar los archivos de registro y consultar el sistema para ejecutar procesos (o su ausencia), y verificar su estado informado, acercarse al problema. Para hacerlo de manera efectiva, necesitamos conocer los servicios que estamos ejecutando: ¿dónde escriben sus archivos de registro, cómo
Podemos obtener información sobre su estado, y saber qué se registra en los tiempos de operación normales también ayuda mucho a identificar un problema, tal vez incluso antes de que el servicio mismo experimente problemas.

Hay muchas herramientas que nos ayudan a automatizar la mayoría de estas cosas, como un subsistema de monitoreo, y soluciones de agregación de registros, pero todas estas comienzan con nosotros, los administradores que saben cómo los servicios que ejecutamos
trabajar, dónde y qué verificar para saber si están saludables. Las herramientas simples demostradas anteriormente son accesibles en cualquier distribución, y con su ayuda podemos ayudar a resolver problemas con los sistemas que no somos
incluso familiarizado con. Ese es un nivel avanzado de resolución de problemas, pero las herramientas y su uso que se muestran aquí son algunos de los ladrillos que cualquiera puede usar para comenzar a desarrollar sus habilidades de solución de problemas en GNU/Linux.

Tutoriales de Linux relacionados:

  • Cosas para instalar en Ubuntu 20.04
  • Cosas que hacer después de instalar Ubuntu 20.04 fossa focal Linux
  • Una introducción a la automatización, herramientas y técnicas de Linux
  • Descarga de Linux
  • Cosas que hacer después de instalar Ubuntu 22.04 Jellyfish de Jammy ..
  • Lista de las mejores herramientas de Kali Linux para pruebas de penetración y ..
  • Instale Arch Linux en VMware Workstation
  • La mejor distribución de Linux para desarrolladores
  • Archivos de configuración de Linux: los 30 principales más importantes
  • Comandos de Linux: los 20 comandos más importantes que necesitas ..