Serie RHCSA: Gestión de procesos en RHEL 7: Arranque, apagado y todo lo demás - Parte 5


Comenzaremos este artículo con una revisión general y breve de lo que sucede desde el momento en que presiona el botón de Encendido para encender su servidor RHEL 7 hasta que se le presenta la pantalla de inicio de sesión en una interfaz de línea de comandos.

Tenga en cuenta que:

2. La siguiente descripción no pretende representar una explicación exhaustiva del proceso de arranque, sino solo los fundamentos.

Proceso de arranque de Linux

1. La POST (autoprueba de encendido) se inicializa y realiza comprobaciones de hardware.

2. Cuando finaliza la POST, el control del sistema se pasa al cargador de arranque de la primera etapa, que se almacena en el sector de arranque de uno de los discos duros (para sistemas más antiguos que usan BIOS y MBR) o en un EFI dedicado dividir.

3. El cargador de arranque de la primera etapa carga el cargador de arranque de la segunda etapa, generalmente GRUB (GRand Unified Boot Loader), que reside dentro de/boot, que a su vez carga el kernel y el sistema de archivos inicial basado en RAM (también conocido como initramfs , que contiene programas y archivos binarios que realizan las acciones necesarias para finalmente montar el sistema de archivos raíz real).

4. Se nos presenta una pantalla de bienvenida que nos permite elegir un sistema operativo y kernel para arrancar:

5. El kernel configura el hardware adjunto al sistema y una vez que se ha montado el sistema de archivos raíz, inicia el proceso con PID 1, que a su vez inicializará otros procesos y nos presentará un mensaje de inicio de sesión.

Nota: que si deseamos hacerlo en un momento posterior, podemos examinar los detalles de este proceso usando el comando dmesg y filtrando su salida usando las herramientas que hemos explicado en artículos anteriores de esta serie.

En el ejemplo anterior, usamos el conocido comando ps para mostrar una lista de procesos actuales cuyo proceso padre (o en otras palabras, el proceso que los inició) es systemd (el administrador de sistemas y servicios que la mayoría de las distribuciones modernas de Linux han cambiado a) durante el inicio del sistema:

# ps -o ppid,pid,uname,comm --ppid=1

Recuerde que la bandera -o (abreviatura de –format) le permite presentar la salida de ps en un formato personalizado para satisfacer sus necesidades utilizando las palabras clave especificadas en la sección ESPECIFICADORES DE FORMATO ESTÁNDAR en man ps.

Otro caso en el que querrá definir la salida de ps en lugar de ir con el predeterminado es cuando necesita encontrar procesos que están causando una carga significativa de CPU y/o memoria, y ordenarlos en consecuencia:

# ps aux --sort=+pcpu              # Sort by %CPU (ascending)
# ps aux --sort=-pcpu              # Sort by %CPU (descending)
# ps aux --sort=+pmem              # Sort by %MEM (ascending)
# ps aux --sort=-pmem              # Sort by %MEM (descending)
# ps aux --sort=+pcpu,-pmem        # Combine sort by %CPU (ascending) and %MEM (descending)

Una introducción a SystemD

Pocas decisiones en el mundo de Linux han causado más controversias que la adopción de systemd por las principales distribuciones de Linux. Los defensores de Systemd mencionan como sus principales ventajas los siguientes hechos:

Lea también: La historia detrás de "init" y "systemd"

1. Systemd permite que se realicen más procesamientos en paralelo durante el inicio del sistema (a diferencia del antiguo SysVinit, que siempre tiende a ser más lento porque inicia los procesos uno por uno, verifica si uno depende de otro y luego espera a que se inicien los demonios). más servicios pueden comenzar), y

2. Funciona como una gestión dinámica de recursos en un sistema en ejecución. Por lo tanto, los servicios se inician cuando se necesitan (para evitar consumir recursos del sistema si no se están utilizando) en lugar de iniciarse sin una razón válida durante el arranque.

3. Compatibilidad con versiones anteriores de los scripts SysVinit.

Systemd está controlado por la utilidad systemctl. Si tiene experiencia en SysVinit, es probable que esté familiarizado con:

  1. the service tool, which -in those older systems- was used to manage SysVinit scripts, and
  2. the chkconfig utility, which served the purpose of updating and querying runlevel information for system services.
  3. shutdown, which you must have used several times to either restart or halt a running system.

La siguiente tabla muestra las similitudes entre el uso de estas herramientas heredadas y systemctl:

Systemd también introdujo los conceptos de unidades (que pueden ser un servicio, un punto de montaje, un dispositivo o un enchufe de red) y objetivos (que es la forma en que systemd logra iniciar varios procesos relacionados al mismo tiempo, y se puede considerar: aunque no igual, como el equivalente de los niveles de ejecución en los sistemas basados u200bu200ben SysVinit.

Resumiendo

Otras tareas relacionadas con la gestión de procesos incluyen, pero no se limitan a, la capacidad de:

Esto se logra mediante la utilidad renice, que altera la prioridad de programación de uno o más procesos en ejecución. En términos simples, la prioridad de programación es una característica que permite al kernel (presente en versiones u003d> 2.6) asignar recursos del sistema según la prioridad de ejecución asignada (también conocida como amabilidad, en un rango de -20 a 19) de un proceso dado.

La sintaxis básica de renice es la siguiente:

# renice [-n] priority [-gpu] identifier

En el comando genérico anterior, el primer argumento es el valor de prioridad que se utilizará, mientras que el otro argumento se puede interpretar como ID de proceso (que es la configuración predeterminada), ID de grupo de proceso, ID de usuario o nombres de usuario. Un usuario normal (que no sea root) solo puede modificar la prioridad de programación de un proceso de su propiedad y solo aumentar el nivel de bondad (lo que significa consumir menos recursos del sistema).

En términos más precisos, matar un proceso da derecho a enviarle una señal para finalizar su ejecución con gracia (SIGTERM u003d 15) o inmediatamente (SIGKILL u003d 9) a través de los comandos kill o pkill.

La diferencia entre estas dos herramientas es que la primera se usa para terminar un proceso específico o un grupo de procesos por completo, mientras que la segunda le permite hacer lo mismo en función del nombre y otros atributos.

Además, pkill viene con pgrep, que le muestra los PID que se verán afectados si se usa pkill. Por ejemplo, antes de ejecutar:

# pkill -u gacanepa

Puede resultar útil ver de un vistazo cuáles son los PID propiedad de gacanepa:

# pgrep -l -u gacanepa

De forma predeterminada, tanto kill como pkill envían la señal SIGTERM al proceso. Como mencionamos anteriormente, esta señal se puede ignorar (mientras el proceso finaliza su ejecución o para siempre), por lo que cuando realmente necesite detener un proceso en ejecución con una razón válida, deberá especificar la señal SIGKILL en la línea de comando:

# kill -9 identifier               # Kill a process or a process group
# kill -s SIGNAL identifier        # Idem
# pkill -s SIGNAL identifier       # Kill a process by name or other attributes 

Conclusión

En este artículo, explicamos los conceptos básicos del proceso de arranque en un sistema RHEL 7 y analizamos algunas de las herramientas que están disponibles para ayudarlo a administrar los procesos mediante utilidades comunes y comandos específicos de systemd.

Tenga en cuenta que esta lista no pretende cubrir todos los detalles de este tema, así que siéntase libre de agregar sus propias herramientas y comandos preferidos a este artículo utilizando el formulario de comentarios a continuación. Las preguntas y otros comentarios también son bienvenidos.