Tema 101: Arquitectura del Sistema
Objetivos del tema 101
101.1 Determinar y configurar los ajustes de hardware
Importancia
2
Descripción
Los candidatos deberán ser capaces de determinar y configurar el hardware fundamental del sistema.
Áreas de conocimiento clave:
Activar y desactivar los periféricos integrados
Diferenciar entre los distintos tipos de dispositivos de almacenamiento masivo.
Determinar los recursos de hardware para los dispositivos.
Herramientas y utilidades para listar información de hardware (por ejemplo, lsusb, lspci, etc.).
Herramientas y utilidades para manipular dispositivos USB.Conocimientos conceptuales de sysfs, udev y dbus.
Contenidos
101.2 Arranque del sistema
Importancia
3
Descripción
Los candidatos deberán ser capaces de guiar el sistema a lo largo del proceso de arranque.
Áreas de conocimiento clave:
Proporcionar comandos comunes al gestor de arranque y opciones al kernel en el momento del arranque.
Demostrar conocimiento de la secuencia de arranque desde BIOS/UEFI hasta la finalización del arranque.
Comprensión de SysVinit y systemd.
Conocimiento de Upstart.
Comprobar los eventos de arranque en los archivos de registro.
Contenidos
Para controlar la máquina, el componente principal del sistema operativo, el núcleo, debe cargarse mediante un programa llamado bootloader, que a su vez lo carga un firmware preinstalado como BIOS o UEFI, la ubicación de almacenamiento es independiente de los otros dispositivos de almacenamiento que pueda tener el sistema.
El gestor de arranque se puede personalizar para pasar parámetros al núcleo, como qué partición contiene el sistema de archivos raíz o en qué modo debe ejecutarse el sistema operativo.
Una vez cargado, el núcleo continúa el proceso de arranque identificando y configurando el hardware. Por último, el núcleo del sistema operativo llama a la utilidad responsable de iniciar y administrar los servicios del sistema
BIOS
Abreviatura de Basic Input/Output System, es un programa almacenado en un chip de memoria no volátil conectado a la placa base, que se ejecuta cada vez que se enciende la computadora.
En términos generales, los pasos previos a la operación para iniciar un sistema equipado con BIOS son:
El proceso POST (power-on self-test) se ejecuta para identificar fallas de dispositivos simples tan pronto como se enciende la máquina.
El BIOS activa los componentes básicos para cargar el sistema, como salida de video, teclado y medios de almacenamiento.
El BIOS carga la primera etapa del gestor de arranque desde el MBR (los primeros 440 bytes del primer dispositivo).
La primera etapa del gestor de arranque llama a la segunda etapa del gestor de arranque, responsable de presentar las opciones de arranque y cargar el núcleo del sistema operativo.
UEFI
Abreviatura de Unified Extensible Firmware Interface, lo que la diferencia de la BIOS es lo siguiente:
Como BIOS, el UEFI también es un firmware, pero puede identificar particiones y leer muchos sistemas de archivos que se encuentran en ellas. Los sistemas de archivos compatibles estándar son FAT12, FAT16 y FAT32 para dispositivos de bloque e ISO-9660 para medios ópticos.
El UEFI no se basa en MBR.
UEFI puede hacer uso de los llamados EFI applications, que se ejecutarán automáticamente o se llamarán desde un menú de arranque, estos pueden ser gestores de arranque, selectores de sistema operativo, herramientas para el diagnóstico y reparación del sistema, etc.
La partición que contiene las aplicaciones EFI se llama EFI System Partition o simplemente ESP. Esta partición no debe compartirse con otros sistemas de archivos del sistema, como el sistema de archivos raíz o los sistemas de archivos de datos del usuario. El directorio EFI en la partición ESP contiene las aplicaciones señaladas por las entradas guardadas en la NVRAM.
Bootloader
El gestor de arranque más popular para Linux en la arquitectura x86 es GRUB (Grand Unified Bootloader). Tan pronto como lo llame el BIOS o el UEFI, GRUB muestra una lista de los sistemas operativos disponibles para arrancar. A veces, la lista no aparece automáticamente, pero se puede invocar presionando Shift mientras el BIOS está llamando a GRUB. En los sistemas UEFI, la tecla Esc debería usarse en su lugar.
Configurar los parámetros del bootloader
Desde el menú GRUB es posible elegir cuál de los núcleos instalados debe cargarse y pasarle los parámetros. La mayoría de los parámetros del núcleo siguen el patrón option=value. Algunos de los parámetros del núcleo de Linux más útiles son:
acpiHabilita/deshabilita el soporte ACPI.acpi=offdeshabilitará la compatibilidad con ACPI.init Establece un iniciador de sistema alternativo. Por ejemplo, init=/bin/bash establecerá shell Bash como iniciador. Esto significa que se iniciará una sesión de shell justo después del proceso de arranque del kernel.
systemd.unitEstablece a systemd para que se active. Por ejemplo,systemd.unit=graphical.target.Systemdtambién acepta los niveles de ejecución numéricos definidos para SysV. Para activar el nivel de ejecución 1, por ejemplo, solo es necesario incluir el número 1 o la letra S (abreviatura de “single”) como parámetro del núcleo.memEstablece la cantidad de RAM disponible para el sistema. Este parámetro es útil cuando se utilizan máquinas virtuales, limitando la cantidad de RAM disponible para cada una de ellas. El uso demem=512Mlimitará a 512 megabytes la cantidad de RAM disponible para un sistema virtual en particular.maxcpusLimita el número de procesadores (o núcleos de procesador) visibles para el sistema en máquinas simétricas multiprocesador. También es útil para máquinas virtuales. Un valor de 0 desactiva el soporte para máquinas multiprocesador y tiene el mismo efecto que el parámetro del núcleonosmp. El parámetromaxcpus=2limitará el número de procesadores disponibles para el sistema operativo a dos.quietOculta la mayoría de los mensajes de arranque.vgaSelecciona un modo de video. El parámetrovga=askmostrará una lista de los modos disponibles para elegir.rootEstablece la partición raíz, distinta de la preconfigurada en el gestor de arranque. Por ejemplo,root =/dev/sda3.rootflagsOpciones de montaje para el sistema de archivos raíz.roHace que el montaje inicial del sistema de archivos raíz sea de solo lecturarwPermite escribir en el sistema de archivos raíz durante el montaje inicial.
Para cambiar los parámetros del núcleo del sistema operativo deben agregarse separados por espacios al archivo /etc/default/grub en la línea GRUB_CMDLINE_LINUX para que sean persistentes durante los reinicios.
A continuación, se debe generar un nuevo archivo de configuración para el gestor de arranque cada vez que /etc/default/grub cambie, lo cual se logra mediante el comando:
grub-mkconfig -o /boot/grub/grub.cfgUna vez que el sistema operativo se está ejecutando, los parámetros del núcleo utilizados para cargar la sesión actual están disponibles en el archivo /proc/cmdline.
Inicio del sistema
Además del núcleo, el sistema operativo depende de otros componentes que proporcionan las características esperadas. Muchos de estos componentes se cargan durante el proceso de inicialización del sistema, que varía desde simples scripts de consola hasta programas de servicio (los llamados daemons) más complejos:
La inicialización del SO comienza cuando el gestor de arranque carga el núcleo en la RAM.
A continuación, el núcleo se hará cargo de la CPU y comenzará a detectar y configurar los aspectos fundamentales del sistema operativo, como la configuración básica de los dispositivos y el direccionamiento de la memoria.
El núcleo del sistema operativo abrirá el archivo
initramfs(initial RAM filesystem), este es un archivo que contiene un sistema de archivos utilizado como un sistema de archivos raíz temporal durante el proceso de arranque. El objetivo principal de un archivo initramfs es proporcionar los módulos necesarios para que el núcleo pueda acceder al sistema de archivos raíz "real" del sistema operativo.Tan pronto como el sistema de archivos raíz esté disponible, el núcleo montará todos los sistemas de archivos configurados en
/etc/fstaby luego ejecutará el primer programa, una utilidad llamadainit.El programa init es responsable de ejecutar todos los scripts de inicialización y daemons del sistema. Una vez que se carga el programa init, initramfs se elimina de la RAM.
Existen implementaciones distintas de iniciadores de sistemas aparte del init tradicional, como SysV, systemd y Upstart:
SysV standard
Un administrador de servicios basado en el estándar SysVinit controla qué daemons y recursos estarán disponibles empleando el concepto de runlevels.
Los niveles de ejecución están numerados del 0 al 6 y están diseñados por los encargados de la distribución para cumplir con propósitos específicos.
Las únicas definiciones de nivel de ejecución compartidas entre todas las distribuciones son los niveles de ejecución 0, 1 y 6.
Upstart
Al igual que systemd, Upstart es un sustituto de init.
El objetivo de Upstart es acelerar el proceso de arranque paralelizando el proceso de carga de los servicios del sistema.
Upstart fue utilizado por distribuciones basadas en Ubuntu en versiones anteriores, pero hoy dio paso a systemd.
systemd
systemd es un administrador moderno de sistemas y servicios con una capa de compatibilidad para los comandos y niveles de ejecución de SysV.
systemd tiene una estructura concurrente, emplea sockets y D-Bus para la activación del servicio, ejecución de demonios a demanda, monitoreo de procesos con cgroups, snapshot support, recuperación de sesión del sistema, control de punto de montaje y un control de servicio basado en la dependencia.
Inspección de inicialización
Pueden ocurrir errores durante el proceso de arranque, pero pueden no ser tan críticos para detener completamente el sistema operativo, no obstante, estos errores pueden comprometer el comportamiento esperado del sistema.
El espacio de memoria donde el kernel almacena sus mensajes, incluidos los mensajes de arranque, se llama kernel ring buffer. Estos se guardan en el búfer incluso cuando no se muestran, sin embargo, este pierde todos los mensajes cuando el sistema está apagado o al ejecutar el comando dmesg --clear.
Para ver lo almacenado en el buffer, usa el comando dmesg :
En sistemas basados en systemd, el comando journalctl mostrará los mensajes de inicialización con las opciones -b, --boot,-k o --dmesg.
El comando journalctl --list-boots muestra una lista de números de arranque relativos al arranque actual, su hash de identificación y las marcas de tiempo del primer y último mensaje correspondientes.
En sistemas basados en systemd, los registros de inicialización anteriores también se mantienen, por lo que los mensajes de sesiones anteriores del sistema operativo aún se pueden inspeccionar. Para ello es tan sencillo como modificar el numero:
Si se proporcionan las opciones
-b 0o--boot=0, se mostrarán los mensajes para el arranque actual.Las opciones
-b -1o--boot=-1mostrarán mensajes de la inicialización anterior.Las opciones
-b -2o--boot=-2mostrarán los mensajes de la inicialización antes de eso y así sucesivamente.
Esto puede resultar útil para revisar fallos de inicio de sistema anteriores. La inicialización y otros mensajes emitidos por el sistema operativo se almacenan en archivos dentro del directorio /var/log/.
Sobre etc/fstab
El archivo /etc/fstab es un componente vital en Linux, ya que almacena información esencial sobre los sistemas de archivos, sus puntos de montaje y opciones de montaje. Este archivo permite que el sistema sepa qué sistemas de archivos montar y cómo manejar cada uno al iniciarse. A continuación, desglosar´r la estructura de /etc/fstab y explicaré cada campo y su función, para que se pueda configurar con confianza la información estática del sistema de archivos.
El propósito de /etc/fstab
/etc/fstabComo ya hemos visto, el archivo /etc/fstab sirve como referencia para los programas, indicándoles cómo manejar los sistemas de archivos del sistema. Programas como mount , umount y fsck utilizan este archivo para determinar puntos de montaje, opciones y configuraciones específicas para cada sistema de archivos.
Por ejemplo, cuando el sistema arranca, mount lee /etc/fstab y monta los sistemas de archivos según lo especificado. Si ejecuta mount -a manualmente, vuelve a leer /etc/fstab e intenta montar cualquier sistema de archivos que se encuentre en la lista. De manera similar, fsck (la herramienta de verificación del sistema de archivos) hace referencia a /etc/fstab para identificar los sistemas de archivos que necesitan verificación durante el arranque, lo que ayuda a mantener la integridad del sistema de archivos.
Cada línea de /etc/fstab describe un sistema de archivos y especifica detalles sobre su punto de montaje, opciones de montaje y otras configuraciones. Por ejemplo, una entrada como:
/dev/sda1 /data ext4 defaults 0 2Le dice a mount que monte /dev/sda1 en /data como un sistema de archivos ext4 con opciones predeterminadas (como acceso de lectura/escritura) cada vez que se inicia el sistema.
Así es como se ve el archivo /etc/fstab:
Desglosando los campos de /etc/fstab
/etc/fstabCada entrada en /etc/fstab tiene seis campos, cada uno con un propósito específico. Repasemos cada campo y entendamos qué hace.
- Campo 1: Sistema de archivos
El primer campo especifica el dispositivo de bloque que se montará, al que normalmente se hace referencia mediante su ruta en /dev . Por ejemplo, para especificar la primera partición en un dispositivo sda , se utilizaría /dev/sda1 .
También puede hacer referencia a un dispositivo de bloque por su LABEL o UUID (Identificador único universal). Se prefiere el uso de UUID porque identifica de forma única un sistema de archivos independientemente de los cambios de hardware. En sistemas con discos particionados con GPT, puede incluso utilizar PARTUUID o PARTLABEL para mayor especificidad.
Para recopilar información sobre un dispositivo, utilice el comando lsblk . Por ejemplo:
lsblk -d -fs /dev/sda1Este comando muestra detalles como el tipo de sistema de archivos, la etiqueta, el UUID y el punto de montaje. A continuación, se muestra un ejemplo de salida:
Con esta información, podemos usar el UUID para referenciar el sistema de archivos en /etc/fstab :
UUID=41ba589d-05ff-491a-a139-6236eee6e5158También puede mostrar información recopilada sobre un dispositivo específico utilizando el comando blkid :
- Campo 2: Punto de montaje
El segundo campo especifica el directorio donde se montará el sistema de archivos, lo que permitirá acceder a su contenido. Este campo debe contener una ruta de punto de montaje válida, a menos que el dispositivo se utilice como intercambio, en cuyo caso el campo debe contener none .
Por ejemplo, si queremos montar nuestro sistema de archivos en /mnt/data , nuestra entrada /etc/fstab comenzaría de la siguiente manera:
UUID=41ba589d-05ff-491a-a139-6236eee6e5158 /mnt/data- Campo 3: Tipo de sistema de archivos
El tercer campo identifica el tipo de sistema de archivos, como ext4, or swap o xfs . Garantiza que el sistema sepa cómo interactuar con el dispositivo especificado. Para sistemas de archivos remotos, se utilizaría cifs (para recursos compartidos Samba) o nfs (para recursos compartidos NFS). En nuestro ejemplo, sda1 tiene el formato ext4 , por lo que nuestra entrada se ve así:
UUID=41ba589d-05ff-491a-a139-6236eee6e5158 /mnt/data ext4- Campo 4: Opciones de montaje
El cuarto campo define las opciones de montaje, que determinan cómo se comporta el sistema de archivos. Para utilizar las opciones predeterminadas, simplemente introduzca defaults . Esto es lo que incluye “default”:
rw: Permite leer y escribir.suid: habilita los bits setuid y setgid.dev: interpreta dispositivos de caracteres y bloques.exec: permite ejecutar binarios.auto: se monta automáticamente cuando se ejecutamount -a.nouser: restringe el montaje por parte de usuarios que no sean root.async: habilita operaciones de E/S asincrónicas.
Además de las opciones predeterminadas, puede configurar opciones adicionales para personalizar el comportamiento del sistema de archivos:
usrquota : habilita cuotas de disco de usuario, lo que permite establecer límites en el espacio de disco o en la cantidad de archivos para usuarios individuales.
grpquota : habilita cuotas de disco grupales, estableciendo límites para grupos en lugar de usuarios individuales.
relatime : actualiza los tiempos de acceso a los archivos solo cuando se modifican, lo que reduce las escrituras en disco en comparación con
atime.sync : fuerza operaciones de E/S sincrónicas, lo que significa que los cambios se escriben inmediatamente en el disco en lugar de almacenarse en caché. Esto puede mejorar la integridad de los datos, pero puede afectar el rendimiento.
Esta lista incluye opciones comunes, pero no es exhaustiva. Para obtener una lista completa y más detalles, consulte la página del manual mount(8) ejecutando:
man 8 mountCon estas opciones nuestra entrada ahora se lee:
UUID=41ba589d-05ff-491a-a139-6236eee6e5158 /mnt/data ext4 defaults- Campo 5: Habilitación de volcado
El quinto campo, 0 o 1 , indica si el sistema de archivos debe incluirse en las copias de seguridad realizadas por la utilidad dump . Si no se utiliza dump , este campo suele configurarse en 0 :
UUID=41ba589d-05ff-491a-a139-6236eee6e5158 /mnt/data ext4 defaults 0- Campo 6: Orden de verificación del sistema de archivos (fsck)
El sexto campo controla el orden en el que fsck (comprobación del sistema de archivos) comprueba los sistemas de archivos durante el arranque. El sistema de archivos raíz debe tener un valor de 1 , mientras que todos los demás suelen utilizar 2 Si no es necesario comprobar un sistema de archivos, este campo se establece en 0 :
UUID=41ba589d-05ff-491a-a139-6236eee6e5158 /mnt/data ext4 defaults 0 2101.3 Cambiar los niveles de ejecución / objetivos de arranque y apagar o reiniciar el sistema
Importancia
3
Descripción
Los candidatos deberán ser capaces de gestionar el nivel de ejecución de SysVinit o el objetivo de arranque systemd del sistema. Este objetivo incluye cambiar al modo de usuario único, apagar o reiniciar el sistema. Los candidatos deberán ser capaces de alertar a los usuarios antes de cambiar de nivel de ejecución / objetivo de arranque y terminar adecuadamente los procesos. Este objetivo también incluye establecer el nivel de ejecución predeterminado de SysVinit o el objetivo de arranque systemd. También incluye el conocimiento de Upstart como una alternativa a SysVinit o systemd.
Áreas de conocimiento clave:
Establecer el nivel de ejecución o el objetivo de arranque predeterminado.
Cambiar entre niveles de ejecución / objetivos de arranque, incluido el modo monousuario.
Apagar y reiniciar desde la línea de comandos.
Alertar a los usuarios antes de cambiar de nivel de ejecución/objetivo de arranque u otros eventos importantes del sistema.
Terminar procesos de forma adecuada.
Conocimiento de ACPID.
Contenidos
Una característica común entre SO Unix es el empleo de procesos separados para controlar distintas funciones del sistema, estos, llamados daemons (o, más generalmente, services), también son responsables de las características extendidas subyacentes al sistema operativo, como los servicios de aplicaciones de red (servidor HTTP, intercambio de archivos, correo electrónico, etc.), bases de datos, configuración bajo demanda, etc.
Aunque Linux utiliza un núcleo monolítico, muchos aspectos de bajo nivel del sistema operativo se ven afectados por daemons, como el equilibrio de carga y la configuración del firewall. Los demonios (daemons) que deberían estar activos dependen del propósito del sistema. El conjunto de demonios activos también debe poder modificarse en tiempo de ejecución, de modo que los servicios se puedan iniciar y detener sin tener que reiniciar todo el sistema. Para abordar este problema, cada distribución principal de Linux ofrece alguna forma o utilidad de administración de servicios para controlar el sistema.
Hoy en día, los administradores de servicios basados en sistemas se encuentran con mayor frecuencia en la mayoría de las distribuciones de Linux. El administrador de servicios es el primer programa lanzado por el núcleo durante el proceso de arranque, por lo que su PID (número de identificación del proceso) siempre es 1.
Tal y como aparecía en la anterior lección, el primer método lo implementa el estándar SysVinit, el segundo método es implementado por systemd y el tercero, Upstart:
Estándar SysVinit
Un administrador de servicios basado en el estándar SysVinit proporcionará conjuntos predefinidos de estados del sistema, llamados runlevels, y sus correspondientes archivos de script de servicio para ser ejecutados. Los niveles de ejecución están numerados de 0 a 6, y generalmente se asignan a los siguientes propósitos:
Runlevel 0 -> Apagado del sistema, scripts que llevan a apagar el sistema.
Runlevel 1, s o usuario único -> Modo de usuario único, sin red y otras capacidades no esenciales (modo de mantenimiento).
Runlevel 2, 3, 4 o 5 -> Modo multiusuario. Los usuarios pueden iniciar sesión por consola o red. Los niveles de ejecución 2 y 4 no se usan con frecuencia. Esto depende de la distribución, en Ubuntu el runlevel gráfico multiusuario es el 2 y en CentOS es el 4.
Runlevel 6 -> Reinicio del sistema.
El kernel arranca el el sistema con el programa /sbin/init y este identifica el nivel de ejecución necesario desde la linea del kernel (init default) o bien, definido en el parámetro del archivo /etc/inittab a partir de aquí comienzan a cargar los scripts del nivel de ejecución (etc/rcX.d donde X es el nivel de ejecución (0, 1, 2, 3...) y estos archivos son enlaces simbólicos a scripts de init que se encuentran el en directorio /etc/init.d/
La sintaxis del archivo /etc/inittab usa este formato:
id:runlevels:action:processDonde el id es un nombre genérico de hasta cuatro caracteres de longitud utilizado para identificar la entrada, runlevels es una lista de números de niveles para los que se debe ejecutar una acción específica y, por último, el término action define cómo init ejecutará el proceso indicado por el término process.
En distribuciones modernas ya no se usan los estandares SysV por lo que no indagaré más allá por ahora.
Más info: LPI-Learning-Material-101-500-es.pdf
Estandar systemd
Actualmente, systemd es el conjunto de herramientas más utilizado para administrar los recursos y servicios del sistema, denominadas unidades (units). Una unidad consta de nombre, tipo y un archivo de configuración correspondiente.
Por ejemplo, la unidad para un proceso de servidor httpd (como el servidor web Apache) será httpd.service en distribuciones basadas en Red Hat, su archivo de configuración también se llamará httpd.service (en distribuciones basadas en Debian esta unidad es llamada apache2.service).
Hay varios tipos distintos de unidades systemd:
service-> El tipo de unidad más común, para recursos activos del sistema que se pueden iniciar, interrumpir y recargar. Por ejemplo, apache, networking, etc.socket-> El tipo de unidad de socket puede ser un socket de sistema de ficheros o un socket de red. Todas las unidades de socket deben tener una unidadservicecorrespondiente, cargada cuando el socket recibe una solicitud.device-> Una unidad de dispositivo está asociada con un dispositivo de hardware identificado por el núcleo ya que systemd puede gestionar también recursos de hardware no solo servicios. Se puede usar una unidad de dispositivo para resolver dependencias de configuración cuando se detecta cierto hardware, dado que las propiedades de la regla udev se pueden usar como parámetros para la unidad de dispositivo. Por ejemplo puede ser una partición, un disco, etc.mount-> Una unidad de montaje es una definición de punto de montaje en el sistema de archivos, similar a una entrada en/etc/fstab.automount-> Una unidad de montaje automático también es una definición de punto de montaje en el sistema de archivos, pero se monta automáticamente. Cada unidad de montaje automático tiene una unidadmountcorrespondiente, que se inicia cuando se accede al punto de montaje automático.target-> Una unidad target es una agrupación de otras unidades, administradas como una sola unidad.snapshot-> Una unidad snapshot es un estado guardado del administrador del sistema (no disponible en todas las distribuciones de Linux).path-> permite monitorizar directorios o ficheros para lanzar otras units.scope-> las crea el servicio systemd con información recibida a través del bus de datos.slice-> unit asociada a los cgroups que tenga configurado un servicio.swap-> describe el espacio de swap.timer-> tareas programadas gestionadas por systemd.
Todas estas units se almacenan en 3 directorios diferentes del sistema, en función de la generación del fichero:
/usr/lib/systemd/system: unidades distribuidas con los paquetes de la distribución instalados./run/systemd/system: unidades creadas en tiempo de ejecución. Tienen preferencia sobre las del directorio anterior./etc/systemd/system: unidades creadas y gestionadas por el administrador del sistema. Prevalecen sobre los 2 directorios anteriores.
El comando principal para controlar las unidades systemd es systemctl, este comando se usa para ejecutar todas las tareas relacionadas con la activación, desactivación, ejecución, interrupción, monitoreo de la unidad, etc.
Para una unidad ficticia llamada unit.service, por ejemplo, las acciones más comunes de systemctl serán:
#Eejcución
systemctl start unit.service #Inicia una unidad (unit).
systemctl stop unit.service #Detiene una unidad (unit).
systemctl restart unit.service #Reinicia una unidad (unit).
#Estado
systemctl status unit.service #Muestra el estado de la unidad (unit), incluyendo si está en ejecución o no.
systemctl is-active unit.service #Muestra active Si la unidad (unit) está en ejecución o inactiva.
#Inicialización del sistema
systemctl enable unit.service #La unidad (unit) se cargará durante la inicialización del sistema.
systemctl disable unit.service #La unidad (unit) no se cargará durante la inicialización del sistema.
systemctl is-enabled unit.service #Verifica si la unidad (unit) comienza con el sistema. La respuesta se almacena en la variable $?. El valor 0 indica que unit comienza con el sistema y el valor 1 indica que unit no comienza con el sistema.Aquí tienes un ejemplo de un service con fallo para que te vayas acostumbrando:
Hay objetivos correspondientes a los niveles de ejecución de SysV, comenzando con runlevelO.target hasta runlevel6.target. Sin embargo, systemd no utiliza el archivo /etc/inittab. Para cambiar el objetivo predeterminado del sistema, la opción systemd.unit se puede agregar a la lista de parámetros del núcleo del SO.
Por ejemplo, para usar multi-user.target como objetivo estándar (Este combina todas las unidades requeridas por el entorno del sistema multiusuario), el parámetro del núcleo del sistema operativo debe ser systemd.unit=multi-user.target. Todos los parámetros del kernel pueden hacerse persistentes cambiando la configuración del gestor de arranque
Otra forma de cambiar el objetivo predeterminado es modificar el enlace simbólico /etc/systemd/system/default.target para que apunte al objetivo deseado. La redefinición del enlace se puede hacer con el comando systemctl por sí mismo:
systemctl set-default multi-user.targetDel mismo modo, podemos llegar a saber cuál es el objetivo de arranque predeterminado actual del sistema con el siguiente comando:
systemctl get-default # Esto, por defecto, devolverá "graphical.target"Obviamente, y siendo similar a los sistemas que adoptan SysV, el objetivo predeterminado nunca debe apuntar a shutdown.target, ya que corresponde al nivel de ejecución 0 (apagado) y causaria que al arrancar el sistema ejecutará los scripts de apagado llegando a no arrancar.
Los archivos de configuración asociados con cada unidad se pueden encontrar en el directorio /lib/systemd/system/. El comando systemctl list-unit-files enumera todas las unidades disponibles y muestra si están habilitadas para iniciarse cuando se inicia el sistema, dentro de esta podemos hacer variaciones o añadir parámetros por ejemplo:
systemctl list-unit-files --type=service #Muestra los archivos asociados a service
systemctl list-unit-files --type=target #Muestra los archivos asociados a target
systemctl list-units #Muestra las unidades activas o unidades que han estado activas durante la sesión actual del sistema
systemctl list-units --type=service #Mostrará solo unidades de tipo service
systemctl list-units --type=target #Mostrará solo unidades de tipo target.
systemd también es responsable de desencadenar y responder a eventos relacionados con la energía del sistema:
systemctl suspend #Pondrá el sistema en modo de bajo consumo, manteniendo los datos actuales en la memoria.
systemctl hibernate #Copiará todos los datos de la memoria al disco, por lo que el estado actual del sistema se puede recuperar después de apagarlo.Estas acciones se definen en el archivo /etc/systemd/logind.conf o en archivos separados dentro del directorio /etc/systemd/logind.conf.d/.
Como veremos más adelante, esta función systemd solo se puede usar cuando no hay otro administrador de energía ejecutándose en el sistema, como el daemonacpidya que es el principal administrador de energía para Linux y permite ajustes más precisos a las acciones posteriores a eventos relacionados con la energía, como cerrar la tapa del portátil, batería baja o niveles de carga de la batería.
Caso práctico: Creando un servicio systemd para mostrar mensajes animados
Objetivo: Configurar y gestionar un servicio con systemd que muestra un mensaje animado en la terminal cada minuto.
1. Instalación de herramientas necesarias
Ejecuta el siguiente comando para instalar figlet y cowsay, herramientas que permitirán generar mensajes en la terminal:
sudo apt install figlet cowsay -y2. Creación del script del servicio
Crea un script en /usr/local/bin/mensaje.sh con el siguiente contenido:
#!/bin/bash
echo "Systemd en accion!" | figletDale permisos de ejecución:
sudo chmod +x /usr/local/bin/mensaje.sh3. Creación de la unidad systemd
Ahora, crea el archivo del servicio en /etc/systemd/system/mensaje.service:
[Unit]
Description=Servicio de mensaje animado con figlet
After=network.target
[Service]
ExecStart=/usr/local/bin/mensaje.sh
Restart=always
RestartSec=60
[Install]
WantedBy=multi-user.target4. Habilitar y probar el servicio
Recarga systemd para que detecte el nuevo servicio:
sudo systemctl daemon-reloadInicia el servicio:
sudo systemctl start mensaje.serviceVerifica su estado:
sudo systemctl status mensaje.serviceSi todo está bien, habilítalo para que inicie automáticamente con el sistema:
sudo systemctl enable mensaje.service5. Comprobación y ajustes
Para ver los mensajes generados, revisa los logs con:
journalctl -u mensaje.service -fEn los logs verás si ha funcionado, recuerda que, por defecto, systemd no muestra la salida de los servicios en la terminal actual porque los servicios se ejecutan en segundo plano (como daemons).
Si deseas detenerlo:
sudo systemctl stop mensaje.serviceSi quieres deshabilitarlo del inicio:
sudo systemctl disable mensaje.serviceEstandar Upstart
...
Apagado y encendido del sistema
Un comando muy tradicional utilizado para apagar o reiniciar el sistema es shutdown, este agrega funciones adicionales al proceso de apagado como por ejemplo, notificar automáticamente a todos los usuarios conectados con un mensaje de advertencia en sus sesiones de shell para evitar nuevos inicios de sesión.
El comando shutdown actúa como intermediario para los procedimientos tanto de SysV como de systemd, es decir, ejecuta la acción solicitada llamando a la acción correspondiente en el administrador de servicios adoptado por el sistema.
Después de ejecutar shutdown, todos los procesos reciben la señal SIGTERM, seguida de la señal SIGKILL, luego el sistema se apaga o cambia su nivel de ejecución. Por defecto, cuando no se utilizan las opciones -h o -r, el sistema alterna al nivel de ejecución 1, es decir, el modo de usuario único.
Para cambiar las opciones predeterminadas para shutdown, el comando debe ejecutarse con la siguiente sintaxis: $
shutdown [option] time [message]
#Por ejemplo:
shutdown time 09:00 #Formato hh:mm especifica el tiempo de ejecución como hora y minutos
shutdown time +5 #Este formato especifica cuántos minutos esperar antes de la ejecución
shutdown now o shutdown +0 #Este formato determina la ejecución inmediata
#Más opciones:
shutdown -r #Reinicia el sistema
El parámetro message es el texto de advertencia enviado a todas las sesiones de terminal de los usuarios conectados o el comando wall puede enviar un mensaje a las sesiones de terminal de todos los usuarios conectados, tienen un propósito similar, pero su ámbito de aplicación y forma de uso son diferentes:
sudo shutdown time +5 "El sistema se apagará en 5 minutos. Por favor, guarde su trabajo."
# ó bien:
sudo wall "El sistema será reiniciado para mantenimiento en 5 minutos." && shutdown time +5El comando systemctl con privilegios de root también se puede usar para apagar o reiniciar la máquina en sistemas que emplean systemd:
sudo systemctl reboot #Reiniciar el sistema
sudo systemctl poweroff #Apagar el sistemaLast updated