LFCS: Gestión de procesos y 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 y emocionante programa cuyo objetivo es permitir que personas de todos los rincones del mundo obtengan la certificación para realizar tareas de administración de sistemas básicas a intermedias en sistemas Linux. Esto incluye la compatibilidad con los sistemas y servicios que ya están en ejecución, junto con la búsqueda y el 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 son necesarios para el examen de certificación LFCS.

Gestión del 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 en su máquina, el firmware que está almacenado en un chip EEPROM en la placa base inicializa el POST ( Autoprueba de encendido ) para comprobar el estado de los recursos de hardware del sistema. Una vez finalizada la POST , el firmware busca y carga el cargador de arranque de la 1ª etapa , que se encuentra en el MBR o en el EFI. partición del primer disco disponible y le da el control.

El MBR se encuentra 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. First 446 bytes: The bootloader contains both executable code and error message text.
  2. Next 64 bytes: The Partition table contains a record for each of four partitions (primary or extended). Among other things, each record indicates the status (active / not active), size, and start / end sectors of each partition.
  3. Last 2 bytes: The magic number serves as a validation check of the 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 si la tabla de particiones se corrompe, por ejemplo, haciendo que el sistema no pueda arrancar.

Por supuesto, para poder usarlo más tarde si surge la necesidad, tendremos que guardarlo y almacenarlo en otro lugar (como una unidad USB , por ejemplo). Ese archivo nos ayudará a restaurar el MBR y nos pondrá en marcha una vez más si, y solo si, no cambiamos el diseño del disco duro mientras tanto.

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

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 encuentra la partición EFI).

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

  1. GRUB legacy configuration file: /boot/grub/menu.lst (older distributions, not supported by EFI/UEFI firmwares).
  2. GRUB2 configuration file: most likely, /etc/default/grub.

Aunque los objetivos del examen LFCS no solicitan explícitamente conocimientos sobre los aspectos internos de GRUB , si es valiente y puede permitirse estropear su sistema (es posible que desee probarlo primero en una máquina virtual, por si acaso), debe ejecutar.

# update-grub

Como root después de modificar la configuración de GRUB para 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 del sistema y servicio ( init o systemd , cuya identificación de proceso o PID es siempre 1) para comenzar el usuario normal- el 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 en iniciar (durante el inicio) y el último servicio en terminar (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 u003d nivel de ejecución (y cuáles no).

Tradicionalmente, este proceso de inicio se realizaba en base a convenciones que se originaron con System V UNIX , con el sistema pasando ejecutando colecciones de scripts que inician y detienen servicios cuando la máquina ingresa a 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, los servicios individuales se pueden configurar para que se ejecuten o para que se apaguen si se ejecutan. Las últimas versiones de algunas de las principales distribuciones se están alejando del estándar System V en favor de un administrador de sistema y servicio 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 conocidas herramientas de inicio sysv en una distribución basada en systemd.

Lea 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.

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 listados arriba). 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 advierte a los usuarios que ya han iniciado sesión (lo que hace que pierdan trabajo y que los procesos finalicen de forma anormal).

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

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

id:2:initdefault:

y cambie el número 2 por 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, ejecute 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 inicio, 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.

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 en particular.

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

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

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

En la imagen de arriba podemos ver que postfix está configurado para comenzar cuando el sistema ingresa a los niveles de ejecución 2 a 5 , mientras que mysqld se ejecutará de forma predeterminada para los niveles de ejecución 2 a 4 . Ahora suponga 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 siguiendo los comandos como root).

# chkconfig --level [level(s)] service on
# chkconfig --level 5 mysqld on
# 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 .

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) como 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á siendo adoptado por varias distribuciones importantes de Linux. Su objetivo es permitir que se realicen más procesamientos en paralelo durante el inicio del sistema (a diferencia de sysvinit , que siempre tiende a ser más lento porque inicia los procesos uno por uno, verifica si uno depende de otro y espera daemons para que se inicien para que se puedan iniciar más servicios) y para que sirva como una gestión dinámica de recursos para un sistema en ejecución.

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

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

# systemctl

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

Cuando la columna ACTIVO 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, 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

En systemd puede habilitar o deshabilitar un servicio cuando arranca.

# 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 están ejecutando) y manejando eventos a medida que ocurren, superando así el sistema clásico sysvinit basado en dependencias.

Se desarrolló originalmente para la distribución de 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 las futuras versiones de Ubuntu usarían systemd como el demonio de inicio predeterminado.

Debido a que la secuencia de comandos de inicio SysV para el sistema ha sido tan común durante tanto tiempo, una gran cantidad de paquetes de software incluyen secuencias de comandos de inicio SysV. Para acomodar dichos paquetes, Upstart proporciona un modo de compatibilidad: ejecuta scripts de inicio de 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 debería iniciarse de la forma habitual.

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

Los scripts Upstart también admiten el inicio o la detención de servicios basados u200bu200ben una variedad más amplia de acciones que los scripts de inicio SysV; por ejemplo, Upstart puede lanzar un servicio siempre que se conecte 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 por .conf scripts en el directorio /etc/init .

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

    1. Description of the process.
    2. Runlevels where the process should run or events that should trigger it.
    3. Runlevels where process should be stopped or events that should stop it.
    4. Options.
    5. Command to launch the process.

    Por ejemplo,

    # My test service - Upstart script demo description "Here goes the description of 'My test service'" author "Dave Null <[email protected]>"
    # 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 los cambios, deberá decirle a advenedizo que vuelva a cargar 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ú "Recetario".

    Resumen

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

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

Todos los derechos reservados © Linux-Console.net • 2019-2021