Comenzaremos este artículo con una revisión general y breve de lo que sucede desde el momento en que presionas el botón de Encendido para encender tu servidor RHEL 7 hasta que se te presente la pantalla de inicio de sesión en una interfaz de línea de comandos.
Ten en cuenta que:
1. los mismos principios básicos se aplican, con quizás modificaciones menores, a otras distribuciones de Linux también, y
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. El POST (Prueba de Autoinicio) inicializa y realiza comprobaciones de hardware.
2. Cuando el POST termina, el control del sistema se pasa al cargador de arranque de primera etapa, que se almacena en el sector de arranque de uno de los discos duros (para sistemas más antiguos que utilizan BIOS y MBR), o una partición dedicada (U)EFI.
3. El cargador de arranque de primera etapa luego carga el cargador de arranque de segunda etapa, más comúnmente GRUB (Cargador de Arranque Unificado y General), que reside dentro de /boot, que a su vez carga el kernel y el sistema de archivos basado en RAM inicial (también conocido como initramfs, que contiene programas y archivos binarios que realizan las acciones necesarias para montar finalmente el sistema de archivos raíz real).
4. Se nos presenta una pantalla de inicio que nos permite elegir un sistema operativo y un kernel para arrancar:
5. El kernel configura el hardware conectado 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 aviso de inicio de sesión.
Nota: Si deseamos hacerlo más tarde, podemos examinar los detalles de este proceso utilizando el comando dmesg y filtrando su salida con las herramientas que hemos explicado en artículos anteriores de esta serie.
En el ejemplo anterior, utilizamos 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 sistema y servicios al que la mayoría de las distribuciones de Linux modernas han migrado) durante el inicio del sistema:
# ps -o ppid,pid,uname,comm --ppid=1
Recuerda que la bandera -o (abreviatura de –format) te permite presentar la salida de ps en un formato personalizado para satisfacer tus necesidades utilizando las palabras clave especificadas en la sección STANDARD FORMAT SPECIFIERS en man ps.
Otro caso en el que querrás definir la salida de ps en lugar de utilizar la configuración predeterminada es cuando necesitas 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 nombran como sus principales ventajas los siguientes hechos:
Leer también: La historia detrás de ‘init’ y ‘systemd’
1. Systemd permite que se realice más procesamiento en paralelo durante el arranque del sistema (a diferencia del antiguo SysVinit, que tiende a ser más lento porque inicia procesos uno por uno, verifica si uno depende de otro, y luego espera a que los demonios se inicien para que puedan comenzar más servicios), y
2. Funciona como un gestor dinámico 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 ser lanzados sin una razón válida durante el arranque.
3. Compatibilidad con scripts de SysVinit.
Systemd es controlado por la utilidad systemctl. Si vienes de un entorno SysVinit, es probable que estés familiarizado con:
- la herramienta service, que -en esos sistemas más antiguos- se utilizaba para gestionar scripts de SysVinit, y
- la utilidad chkconfig, que servía para actualizar y consultar información de niveles de ejecución para los servicios del sistema.
- apagar, que seguramente has utilizado varias veces para reiniciar o detener un sistema en ejecución.
La siguiente tabla muestra las similitudes entre el uso de estas herramientas heredadas y systemctl:
| Legacy tool | Systemctl equivalent | Description |
| service name start | systemctl start name | Start name (where name is a service) |
| service name stop | systemctl stop name | Stop name |
| service name condrestart | systemctl try-restart name | Restarts name (if it’s already running) |
| service name restart | systemctl restart name | Restarts name |
| service name reload | systemctl reload name | Reloads the configuration for name |
| service name status | systemctl status name | Displays the current status of name |
| service –status-all | systemctl | Displays the status of all current services |
| chkconfig name on | systemctl enable name | Enable name to run on startup as specified in the unit file (the file to which the symlink points). The process of enabling or disabling a service to start automatically on boot consists in adding or removing symbolic links inside the /etc/systemd/system directory. |
| chkconfig name off | systemctl disable name | Disables name to run on startup as specified in the unit file (the file to which the symlink points) |
| chkconfig –list name | systemctl is-enabled name | Verify whether name (a specific service) is currently enabled |
| chkconfig –list | systemctl –type=service | Displays all services and tells whether they are enabled or disabled |
| shutdown -h now | systemctl poweroff | Power-off the machine (halt) |
| shutdown -r now | systemctl reboot | Reboot the system |
Systemd también introdujo los conceptos de unidades (que pueden ser un servicio, un punto de montaje, un dispositivo o un socket de red) y objetivos (que es cómo systemd logra iniciar varios procesos relacionados al mismo tiempo, y puede considerarse, aunque no sea igual, como el equivalente de los niveles de ejecución en sistemas basados en SysVinit.
Resumiendo
Otras tareas relacionadas con la gestión de procesos incluyen, pero no se limitan a, la capacidad de:
1. Ajustar la prioridad de ejecución en lo que respecta al uso de recursos del sistema de un proceso:
Esto se logra a través de 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 => 2.6) asignar recursos del sistema según la prioridad de ejecución asignada (también conocida como “niceness”, en un rango de -20 a través de 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 puede interpretarse como identificadores de proceso IDs (que es la configuración predeterminada), identificadores de grupo de procesos, identificadores de usuario o nombres de usuario. Un usuario normal (que no sea root) solo puede modificar la prioridad de planificación de un proceso que él o ella posee, y solo puede aumentar el nivel de amabilidad (lo que significa ocupar menos recursos del sistema).
2. Matar (o interrumpir la ejecución normal) de un proceso según sea necesario:
En términos más precisos, matar un proceso implica enviarle una señal para que termine su ejecución de manera elegante (SIGTERM=15) o inmediatamente (SIGKILL=9) a través de los comandos kill o pkill.
La diferencia entre estas dos herramientas es que la primera se utiliza para terminar un proceso específico o un grupo de procesos por completo, mientras que la segunda te permite hacer lo mismo en función del nombre y otras características.
Además, pkill viene incluido con pgrep, que te muestra los PID que se verán afectados si se utiliza pkill. Por ejemplo, antes de ejecutar:
# pkill -u gacanepa
Puede ser útil ver de un vistazo cuáles son los PIDs pertenecientes a gacanepa:
# pgrep -l -u gacanepa
Por defecto, tanto kill como pkill envían la señal SIGTERM al proceso. Como mencionamos anteriormente, esta señal puede ser ignorada (mientras el proceso finaliza su ejecución o de forma permanente), por lo que cuando realmente necesites detener un proceso en ejecución con una razón válida, deberás especificar la señal SIGKILL en la línea de comandos:
# 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 hemos explicado los conceptos básicos del proceso de arranque en un sistema RHEL 7, y analizado algunas de las herramientas disponibles para ayudarte a gestionar procesos utilizando utilidades comunes y comandos específicos de systemd.
Ten en cuenta que esta lista no pretende cubrir todos los detalles de este tema, así que siéntete libre de añadir tus propias herramientas y comandos preferidos a este artículo utilizando el formulario de comentarios a continuación. También son bienvenidas las preguntas y otros comentarios.
Source:
https://www.tecmint.com/rhcsa-exam-boot-process-and-process-management/