LFCS: Gestión del proceso y los servicios de inicio del sistema (SysVinit, Systemd y Upstart) - Parte 7

Hace un par de meses, la Fundación Linux anunció la certificación LFCS (Linux Foundation Certified Sysadmin), un nuevo e interesante programa cuyo objetivo es permitir a personas de todos los confines del mundo Obtenga la certificación para realizar tareas de administración de sistemas básicas a intermedias en sistemas Linux. Esto incluye soporte para sistemas y servicios que ya están en ejecución, junto con la búsqueda y análisis de problemas de primera mano, además de la capacidad de decidir cuándo plantear problemas a los equipos de ingeniería.

El siguiente video describe una breve introducción al Programa de Certificación de The Linux Foundation.

Esta publicación es la Parte 7 de una serie de 10 tutoriales. Aquí, en esta parte, explicaremos cómo administrar el proceso y los servicios de inicio del sistema Linux, que se requieren para el examen de certificación LFCS.

Administrar el proceso de inicio de Linux

El proceso de arranque de un sistema Linux consta de varias fases, cada una representada por un componente diferente. El siguiente diagrama resume brevemente el proceso de arranque y muestra todos los componentes principales involucrados.

Cuando presiona el botón Encendido de su máquina, el firmware almacenado en un chip EEPROM en la placa base inicializa el POST ( Autoprueba de encendido) para verificar el estado de los recursos de hardware del sistema. Cuando finaliza la POST, el firmware busca y carga el cargador de arranque de la primera etapa, ubicado en el MBR o en el EFI. partición del primer disco disponible y le da control.

Método MBR

El MBR está ubicado en el primer sector del disco marcado como de arranque en la configuración del BIOS y tiene un tamaño de 512 bytes.

1. Primeros 446 bytes: el gestor de arranque contiene código ejecutable y texto de mensaje de error.
2. Siguientes 64 bytes: la tabla de particiones contiene un registro para cada una de las cuatro particiones (primaria o extendida). Entre otras cosas, cada registro indica el estado (activo/no activo), tamaño y sectores de inicio/fin de cada partición.
3. Últimos 2 bytes: el número mágico sirve como verificación de validación del MBR.

El siguiente comando realiza una copia de seguridad del MBR (en este ejemplo, /dev/sda es el primer disco duro). El archivo resultante, mbr.bkp, puede resultar útil en caso de que la tabla de particiones se corrompa, por ejemplo, haciendo que el sistema no pueda arrancar.

Eso sí, para poder utilizarlo más adelante si surge la necesidad, necesitaremos guardarlo y almacenarlo en otro lugar (como una unidad USB, por ejemplo). Ese archivo nos ayudará a restaurar el MBR y nos permitirá continuar una vez más si y sólo si no cambiamos el diseño del disco duro mientras tanto.

MBR de respaldo

dd if=/dev/sda of=mbr.bkp bs=512 count=1

Restaurando MBR

dd if=mbr.bkp of=/dev/sda bs=512 count=1

Método EFI/UEFI

Para los sistemas que utilizan el método EFI/UEFI, el firmware UEFI lee su configuración para determinar qué aplicación UEFI se iniciará y desde dónde (es decir, en qué disco y partición se instalará). se encuentra la partición EFI).

A continuación, se carga y ejecuta el cargador de arranque de la segunda etapa (también conocido como administrador de arranque). GRUB [GRand Unified Boot] es el administrador de arranque más utilizado en Linux. En la mayoría de los sistemas utilizados hoy en día se puede encontrar una de dos versiones distintas.

1. Archivo de configuración heredado de GRUB: /boot/grub/menu.lst (distribuciones más antiguas, no compatibles con firmwares EFI/UEFI).
2. Archivo de configuración de GRUB2: muy probablemente, /etc/default/grub.

Aunque los objetivos del examen LFCS no solicitan explícitamente conocimientos sobre los aspectos internos de GRUB, si eres valiente y puedes permitirte el lujo de estropear tu sistema (quizás quieras probarlo). primero en una máquina virtual, por si acaso), debe ejecutarlo.

update-grub

Como root después de modificar la configuración de GRUB para poder aplicar los cambios.

Básicamente, GRUB carga el kernel predeterminado y la imagen initrd o initramfs. En pocas palabras, initrd o initramfs ayudan a realizar la detección de hardware, la carga del módulo del kernel y el descubrimiento de dispositivos necesarios para montar el sistema de archivos raíz real.

Una vez que el sistema de archivos raíz real está activo, el kernel ejecuta el administrador de sistemas y servicios (init o systemd, cuya identificación de proceso o PID es siempre 1) para comenzar el proceso de usuario normal. proceso de arranque espacial para presentar una interfaz de usuario.

Tanto init como systemd son demonios (procesos en segundo plano) que administran otros demonios, como el primer servicio que se inicia (durante el arranque) y el último servicio que finaliza (durante el apagado).

Servicios de inicio (SysVinit)

El concepto de niveles de ejecución en Linux especifica diferentes formas de utilizar un sistema controlando qué servicios se están ejecutando. En otras palabras, un nivel de ejecución controla qué tareas se pueden realizar en el estado de ejecución actual=nivel de ejecución (y cuáles no).

Tradicionalmente, este proceso de inicio se realizaba según convenciones que se originaron con System V UNIX, donde el sistema ejecutaba colecciones de scripts que iniciaban y detenían servicios a medida que la máquina entraba en un nivel de ejecución específico (que, en otras palabras, , es un modo diferente de ejecutar el sistema).

Dentro de cada nivel de ejecución, se pueden configurar servicios individuales para que se ejecuten o se apaguen si se están ejecutando. Las últimas versiones de algunas distribuciones importantes se están alejando del estándar System V en favor de un administrador de sistemas y servicios bastante nuevo llamado systemd (que significa demonio del sistema), pero generalmente admite comandos sysv por motivos de compatibilidad. Esto significa que puede ejecutar la mayoría de las herramientas init sysv más conocidas en una distribución basada en systemd.

Leer también: Por qué 'systemd' reemplaza a 'init' en Linux

Además de iniciar el proceso del sistema, init busca en el archivo /etc/inittab para decidir qué nivel de ejecución se debe ingresar.

Runlevel

Descripción

0

Detener el sistema. El nivel de ejecución 0 es un estado de transición especial que se utiliza para apagar el sistema rápidamente.

1

También conocido como s o S, este nivel de ejecución a veces se denomina modo de mantenimiento. Los servicios, si los hay, que se inician en este nivel de ejecución varían según la distribución. Normalmente se utiliza para el mantenimiento del sistema de bajo nivel que puede verse afectado por el funcionamiento normal del sistema.

2

Multi usuario. En los sistemas Debian y derivados, este es el nivel de ejecución predeterminado e incluye, si está disponible, un inicio de sesión gráfico. En los sistemas basados en Red-Hat, este es el modo multiusuario sin conexión en red.

3

En los sistemas basados en Red-Hat, este es el modo multiusuario predeterminado, que ejecuta todo excepto el entorno gráfico. Este nivel de ejecución y los niveles 4 y 5 normalmente no se utilizan en sistemas basados en Debian.

4

Normalmente no se utiliza de forma predeterminada y, por lo tanto, está disponible para personalización.

5

En sistemas basados en Red-Hat, modo multiusuario completo con inicio de sesión GUI. Este nivel de ejecución es como el nivel 3, pero con un inicio de sesión GUI disponible.

6

Reinicie el sistema.

Para cambiar entre niveles de ejecución, simplemente podemos emitir un cambio de nivel de ejecución usando el comando init: init N (donde N es uno de los niveles de ejecución enumerados anteriormente). Tenga en cuenta que esta no es la forma recomendada de llevar un sistema en ejecución a un nivel de ejecución diferente porque no avisa a los usuarios que ya han iniciado sesión (lo que provoca que pierdan trabajo y que los procesos finalicen de forma anormal).

En su lugar, se debe utilizar el comando shutdown para reiniciar el sistema (que primero envía un mensaje de advertencia a todos los usuarios que han iniciado sesión y bloquea cualquier inicio de sesión adicional; luego indica a init que cambie los niveles de ejecución); sin embargo, el nivel de ejecución predeterminado (el que arrancará el sistema) debe editarse primero en el archivo /etc/inittab.

Por ese motivo, siga estos pasos para cambiar correctamente entre niveles de ejecución. Como root, busque la siguiente línea en /etc/inittab.

id:2:initdefault:

y cambie el número 2 para el nivel de ejecución deseado con su editor de texto preferido, como vim (descrito en Cómo usar el editor vi/vim en Linux – Parte 2 de esta serie).

A continuación, ejecútelo como root.

shutdown -r now

Ese último comando reiniciará el sistema, lo que hará que se inicie en el nivel de ejecución especificado durante el próximo arranque, y ejecutará los scripts ubicados en /etc/rc[runlevel].d directorio para decidir qué servicios deben iniciarse y cuáles no. Por ejemplo, para el nivel de ejecución 2 en el siguiente sistema.

Administrar servicios usando chkconfig

Para habilitar o deshabilitar los servicios del sistema en el arranque, usaremos el comando chkconfig en CentOS/openSUSE y sysv-rc-conf en Debian y derivados. Esta herramienta también puede mostrarnos cuál es el estado preconfigurado de un servicio para un nivel de ejecución particular.

Lea también: Cómo detener y deshabilitar servicios no deseados en Linux

Listado de la configuración del nivel de ejecución de un servicio.

chkconfig --list [service name]
chkconfig --list postfix
chkconfig --list mysqld

En la imagen de arriba podemos ver que postfix está configurado para iniciarse cuando el sistema ingresa a los niveles de ejecución 2 al 5, mientras que mysqld se ejecutará de forma predeterminada para los niveles de ejecución 2 al 4. Ahora supongamos que este no es el comportamiento esperado.

Por ejemplo, también necesitamos activar mysqld para el nivel de ejecución 5 y desactivar postfix para los niveles de ejecución 4 y 5. Esto es lo que haríamos en cada caso (ejecutar el siguientes comandos como root).

Habilitar un servicio para un nivel de ejecución particular

chkconfig --level [level(s)] service on
chkconfig --level 5 mysqld on

Deshabilitar un servicio para niveles de ejecución particulares

chkconfig --level [level(s)] service off
chkconfig --level 45 postfix off

Ahora realizaremos tareas similares en un sistema basado en Debian usando sysv-rc-conf.

Administrar servicios usando sysv-rc-conf

Configurar un servicio para que se inicie automáticamente en un nivel de ejecución específico y evitar que se inicie en todos los demás.

1. Usemos el siguiente comando para ver cuáles son los niveles de ejecución donde mdadm está configurado para comenzar.

ls -l /etc/rc[0-6].d | grep -E 'rc[0-6]|mdadm'

2. Usaremos sysv-rc-conf para evitar que mdadm se inicie en todos los niveles de ejecución excepto 2. Simplemente marque o desmarque (con la barra espaciadora) según lo desee (puede moverse hacia arriba, abajo, izquierda y derecha con las teclas de flecha).

sysv-rc-conf

Luego presione q para salir.

3. Reiniciaremos el sistema y ejecutaremos nuevamente el comando del PASO 1.

ls -l /etc/rc[0-6].d | grep -E 'rc[0-6]|mdadm'

En la imagen de arriba podemos ver que mdadm está configurado para iniciarse solo en el nivel de ejecución 2.

¿Qué pasa con systemd?

systemd es otro administrador de sistemas y servicios que están adoptando varias distribuciones importantes de Linux. Su objetivo es permitir que se realice más procesamiento en paralelo durante el inicio del sistema (a diferencia de sysvinit, que siempre tiende a ser más lento porque inicia los procesos uno a la vez, verifica si uno depende del otro y espera a que se ejecuten). demonios para iniciarse para que puedan iniciarse más servicios) y para servir como una gestión dinámica de recursos para un sistema en ejecución.

Por lo tanto, los servicios se inician cuando es necesario (para evitar consumir recursos del sistema) en lugar de iniciarse sin una razón sólida durante el arranque.

Para ver el estado de todos los procesos que se ejecutan en su sistema, tanto los servicios systemd nativos como los SysV, ejecute el siguiente comando.

systemctl

La columna LOAD muestra si la definición de la unidad (consulte la columna UNIT, que muestra el servicio o cualquier cosa mantenida por systemd) se cargó correctamente, mientras que ACTIVE< Las columnas y SUB muestran el estado actual de dicha unidad.

Mostrar información sobre el estado actual de un servicio

Cuando la columna ACTIVE indica que el estado de una unidad no es activo, podemos verificar qué sucedió usando.

systemctl status [unit]

Por ejemplo, en la imagen de arriba, media-samba.mount está en estado fallido. Corramos.

systemctl status media-samba.mount

Podemos ver que media-samba.mount falló porque el proceso de montaje en el host dev1 no pudo encontrar el recurso compartido de red en //192.168.0.10/gacanepa.

Iniciar o detener servicios

Una vez que el recurso compartido de red //192.168.0.10/gacanepa esté disponible, intentemos iniciar, luego detener y finalmente reiniciar la unidad media-samba.mount. Después de realizar cada acción, ejecutemos systemctl status media-samba.mount para verificar su estado.

systemctl start media-samba.mount
systemctl status media-samba.mount
systemctl stop media-samba.mount
systemctl restart media-samba.mount
systemctl status media-samba.mount

Habilitar o deshabilitar un servicio para que se inicie durante el arranque

En systemd puede habilitar o deshabilitar un servicio cuando se inicia.

systemctl enable [service] 		# enable a service 
systemctl disable [service] 		# prevent a service from starting at boot

El proceso de habilitar o deshabilitar un servicio para que se inicie automáticamente al arrancar consiste en agregar o eliminar enlaces simbólicos en el directorio /etc/systemd/system/multi-user.target.wants.

Alternativamente, puede averiguar el estado actual de un servicio (habilitado o deshabilitado) con el comando.

systemctl is-enabled [service]

Por ejemplo,

systemctl is-enabled postfix.service

Además, puede reiniciar o apagar el sistema con.

systemctl reboot
systemctl shutdown

Advenedizo

Upstart es un reemplazo basado en eventos para el demonio /sbin/init y nació de la necesidad de iniciar servicios solo cuando son necesarios (también supervisándolos mientras se ejecutan). se están ejecutando) y manejando eventos a medida que ocurren, superando así el clásico sistema sysvinit basado en dependencias.

Fue desarrollado originalmente para la distribución Ubuntu, pero se usa en Red Hat Enterprise Linux 6.0. Aunque estaba destinado a ser adecuado para su implementación en todas las distribuciones de Linux como reemplazo de sysvinit, con el tiempo fue eclipsado por systemd. El 14 de febrero de 2014, Mark Shuttleworth (fundador de Canonical Ltd.) anunció que futuras versiones de Ubuntu utilizarían systemd como demonio de inicio predeterminado.

Debido a que el script de inicio SysV para el sistema ha sido tan común durante tanto tiempo, una gran cantidad de paquetes de software incluyen scripts de inicio SysV. Para acomodar dichos paquetes, Upstart proporciona un modo de compatibilidad: ejecuta scripts de inicio SysV en las ubicaciones habituales (/etc/rc.d/rc?.d, /etc/init.d/ rc?.d, /etc/rc?.d, o una ubicación similar). Por lo tanto, si instalamos un paquete que aún no incluye un script de configuración Upstart, aún así debería iniciarse de la forma habitual.

Además, si tenemos utilidades instaladas como chkconfig, debería poder usarlas para administrar sus servicios basados en SysV tal como lo haríamos en sistemas basados en sysvinit.

Los scripts Upstart también admiten iniciar o detener servicios basándose en una variedad más amplia de acciones que los scripts de inicio SysV; por ejemplo, Upstart puede iniciar un servicio cada vez que se conecta un dispositivo de hardware en particular.

Un sistema que utiliza Upstart y sus scripts nativos reemplaza exclusivamente el archivo /etc/inittab y los directorios de scripts de inicio SysV específicos del nivel de ejecución con .conf. scripts en el directorio /etc/init.

Estos scripts *.conf (también conocidos como definiciones de trabajo) generalmente constan de lo siguiente:

1. Descripción del proceso.
2. Niveles de ejecución donde debería ejecutarse el proceso o eventos que deberían desencadenarlo.
3. Niveles de ejecución donde se debe detener el proceso o eventos que deberían detenerlo.
4. Opciones.
5. Comando para iniciar el proceso.

Por ejemplo,

My test service - Upstart script demo description "Here goes the description of 'My test service'" author "Dave Null <[email >"
Stanzas

#
Stanzas define when and how a process is started and stopped
See a list of stanzas here: http://upstart.ubuntu.com/wiki/Stanzas#respawn
When to start the service
start on runlevel [2345]
When to stop the service
stop on runlevel [016]
Automatically restart process in case of crash
respawn
Specify working directory
chdir /home/dave/myfiles
Specify the process/command (add arguments if needed) to run
exec bash backup.sh arg1 arg2

Para aplicar cambios, deberá indicarle a advenedizo que recargue su configuración.

initctl reload-configuration

Luego comience su trabajo escribiendo el siguiente comando.

sudo start yourjobname

Donde yourjobname es el nombre del trabajo que se agregó anteriormente con el script yourjobname.conf.

Una guía de referencia más completa y detallada para Upstart está disponible en el sitio web del proyecto en el menú "Libro de cocina".

Resumen

Es necesario conocer el proceso de arranque de Linux para ayudarle con las tareas de resolución de problemas, así como para adaptar el rendimiento de la computadora y ejecutar los servicios a sus necesidades.

En este artículo hemos analizado qué sucede desde el momento en que presionas el interruptor Encendido para encender la máquina hasta que obtienes una interfaz de usuario completamente operativa. Espero que hayas aprendido leyéndolo tanto como yo mientras lo armaba. No dude en dejar sus comentarios o preguntas a continuación. ¡Siempre esperamos tener noticias de nuestros lectores!