En los primeros dos artículos de esta serie, exploré la secuencia de inicio de Linux systemd. En el primer artículo, analicé las funciones y la arquitectura de systemd y la controversia en torno a su papel como reemplazo del antiguo programa de inicio SystemV y los scripts de inicio. Y en el segundo artículo, examiné dos importantes herramientas systemd, systemctl y journalctl, y expliqué cómo cambiar de un destino a otro y cambiar el destino predeterminado.
En este tercer artículo, analizaré las unidades systemd con más detalle y cómo usar el comando systemctl para explorar y administrar unidades. También explicaré cómo detener y deshabilitar unidades y cómo crear una nueva unidad de montaje systemd para montar un nuevo sistema de archivos y permitir que se inicie durante el inicio.
Todos los experimentos de este artículo deben realizarse como usuario raíz (a menos que se especifique lo contrario). Algunos de los comandos que simplemente enumeran varias unidades systemd pueden ser ejecutados por usuarios que no sean root, pero los comandos que realizan cambios no pueden. Asegúrese de realizar todos estos experimentos solo en máquinas virtuales (VM) o hosts que no sean de producción.
Uno de estos experimentos requiere el paquete sysstat, así que instálelo antes de continuar. Para Fedora y otras distribuciones basadas en Red Hat, puede instalar sysstat con:
El sysstat RPM instala varias herramientas estadísticas que se pueden utilizar para la determinación de problemas. Uno es el Informe de actividad del sistema (SAR), que registra muchos puntos de datos de rendimiento del sistema a intervalos regulares (cada 10 minutos de forma predeterminada). En lugar de ejecutarse como un demonio en segundo plano, el paquete sysstat instala dos temporizadores systemd. Un temporizador se ejecuta cada 10 minutos para recopilar datos y el otro se ejecuta una vez al día para agregar los datos diarios. En este artículo, analizaré brevemente estos temporizadores, pero esperaré a explicar cómo crear un temporizador en un artículo futuro.
El hecho es que systemd es más que un programa. Es un gran conjunto de programas, todos diseñados para trabajar juntos para administrar casi todos los aspectos de un sistema Linux en ejecución. Una exposición completa de systemd tomaría un libro por sí solo. La mayoría de nosotros no necesitamos comprender todos los detalles sobre cómo encajan todos los componentes de systemd, por lo que me centraré en los programas y componentes que le permiten administrar varios servicios de Linux y manejar archivos de registro y diarios.
La estructura de systemd, fuera de sus archivos ejecutables, está contenida en sus muchos archivos de configuración. Aunque estos archivos tienen diferentes nombres y extensiones de identificador, todos se denominan archivos de "unidad". Las unidades son la base de todo systemd.
Los archivos unitarios son archivos de texto sin formato ASCII a los que puede acceder un administrador de sistemas y que puede crearlos o modificarlos. Hay varios tipos de archivos unitarios y cada uno tiene su propia página de manual. La Figura 1 enumera algunos de estos tipos de archivos de unidad por sus extensiones de nombre de archivo y una breve descripción de cada uno.
| unidad systemd | Descripción |
|---|
| .montaje automático | El .automount Las unidades se utilizan para implementar bajo demanda (es decir, plug and play) y el montaje de unidades del sistema de archivos en paralelo durante el inicio. |
|---|
| .dispositivo | El .dispositivo Los archivos unitarios definen el hardware y los dispositivos virtuales que están expuestos al administrador del sistema en el directorio /dev/. . No todos los dispositivos tienen archivos de unidad; por lo general, los dispositivos de bloque como discos duros, dispositivos de red y algunos otros tienen archivos unitarios. |
|---|
| .montar | El .montaje unidad define un punto de montaje en la estructura de directorios del sistema de archivos de Linux. |
|---|
| .alcance | El .ámbito unidad define y gestiona un conjunto de procesos del sistema. Esta unidad no está configurada usando archivos de unidad, sino que se crea mediante programación. Según el systemd.scope man page, "El objetivo principal de las unidades de alcance es agrupar los procesos de trabajo de un servicio del sistema para la organización y la gestión de recursos". |
|---|
| .servicio | El .servicio Los archivos unitarios definen procesos que son administrados por systemd. Estos incluyen servicios como crond cups (Common Unix Printing System), iptables, servicios de administración de volúmenes lógicos múltiples (LVM), NetworkManager y más. |
|---|
| .rebanada | El .slice unidad define una "rebanada", que es una división conceptual de los recursos del sistema que están relacionados con un grupo de procesos. Puede pensar en todos los recursos del sistema como un pastel y este subconjunto de recursos como una "rebanada" de ese pastel. |
|---|
| .socket | El .socket las unidades definen sockets de comunicación entre procesos, como sockets de red. |
|---|
| .intercambiar | El .intercambio las unidades definen dispositivos o archivos de intercambio. |
|---|
| .objetivo | El .objetivo las unidades definen grupos de archivos de unidad que definen puntos de sincronización de inicio, niveles de ejecución y servicios. Las unidades de destino definen los servicios y otras unidades que deben estar activas para poder iniciar correctamente. |
|---|
| .temporizador | El .temporizador la unidad define temporizadores que pueden iniciar la ejecución del programa en momentos específicos. |
|---|
ctlsistema
Examiné las funciones de inicio de systemd en el segundo artículo, y aquí exploraré un poco más sus funciones de administración de servicios. systemd proporciona el systemctl comando que se usa para iniciar y detener servicios, configurarlos para que se inicien (o no) al iniciar el sistema y monitorear el estado actual de los servicios en ejecución.
En una sesión de terminal como usuario raíz, asegúrese de que el directorio de inicio de la raíz ( ~ ) es la PCD. Para comenzar a ver las unidades de varias maneras, enumere todas las unidades systemd cargadas y activas. systemctl canaliza automáticamente su flujo de datos de salida estándar a través de menos localizador, para que no tengas que:
[root@testvm1 ~]# systemctl
UNIT LOAD ACTIVE SUB DESCRIPTION
proc-sys-fs-binfmt_misc.automount loaded active running Arbitrary Executable File>
sys-devices-pci0000:00-0000:00:01.1-ata7-host6-target6:0:0-6:0:0:0-block-sr0.device loaded a>
sys-devices-pci0000:00-0000:00:03.0-net-enp0s3.device loaded active plugged 82540EM Gigabi>
sys-devices-pci0000:00-0000:00:05.0-sound-card0.device loaded active plugged 82801AA AC'97>
sys-devices-pci0000:00-0000:00:08.0-net-enp0s8.device loaded active plugged 82540EM Gigabi>
sys-devices-pci0000:00-0000:00:0d.0-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda1.device loa>
sys-devices-pci0000:00-0000:00:0d.0-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda2.device loa>
<snip – removed lots of lines of data from here>
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
206 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
A medida que se desplaza por los datos en su sesión de terminal, busque algunas cosas específicas. La primera sección enumera dispositivos como discos duros, tarjetas de sonido, tarjetas de interfaz de red y dispositivos TTY. Otra sección muestra los puntos de montaje del sistema de archivos. Otras secciones incluyen varios servicios y una lista de todos los objetivos cargados y activos.
Los temporizadores de sysstat en la parte inferior de la salida se utilizan para recopilar y generar resúmenes diarios de actividad del sistema para SAR. SAR es una herramienta muy útil para resolver problemas. (Puede obtener más información al respecto en el Capítulo 13 de mi libro Using and Administration Linux:Volume 1, Zero to SysAdmin:Getting Started .)
Cerca de la parte inferior, tres líneas describen los significados de los estados (cargado, activo y sub). Presiona q para salir del localizador.
Utilice el siguiente comando (como se sugiere en la última línea del resultado anterior) para ver todas las unidades que están instaladas, ya sea que estén cargadas o no. No reproduciré el resultado aquí, porque puede desplazarse por él por su cuenta. El programa systemctl tiene una excelente función para completar tabuladores que facilita el ingreso de comandos complejos sin necesidad de memorizar todas las opciones:
[root@testvm1 ~]# systemctl list-unit-files
Puede ver que algunas unidades están deshabilitadas. La Tabla 1 en la página del manual para systemctl enumera y proporciona breves descripciones de las entradas que puede ver en esta lista. Usa la -t (tipo) opción para ver solo las unidades del temporizador:
[root@testvm1 ~]# systemctl list-unit-files -t timer
UNIT FILE STATE
[email protected] disabled
dnf-makecache.timer enabled
fstrim.timer disabled
logrotate.timer disabled
logwatch.timer disabled
[email protected] static
mlocate-updatedb.timer enabled
sysstat-collect.timer enabled
sysstat-summary.timer enabled
systemd-tmpfiles-clean.timer static
unbound-anchor.timer enabled
Podría hacer lo mismo con esta alternativa, que proporciona muchos más detalles:
[root@testvm1 ~]# systemctl list-timers
Thu 2020-04-16 09:06:20 EDT 3min 59s left n/a n/a systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Thu 2020-04-16 10:02:01 EDT 59min left Thu 2020-04-16 09:01:32 EDT 49s ago dnf-makecache.timer dnf-makecache.service
Thu 2020-04-16 13:00:00 EDT 3h 57min left n/a n/a sysstat-collect.timer sysstat-collect.service
Fri 2020-04-17 00:00:00 EDT 14h left Thu 2020-04-16 12:51:37 EDT 3h 49min left mlocate-updatedb.timer mlocate-updatedb.service
Fri 2020-04-17 00:00:00 EDT 14h left Thu 2020-04-16 12:51:37 EDT 3h 49min left unbound-anchor.timer unbound-anchor.service
Fri 2020-04-17 00:07:00 EDT 15h left n/a n/a sysstat-summary.timer sysstat-summary.service
6 timers listed.
Pass --all to see loaded but inactive timers, too.
[root@testvm1 ~]#
Aunque no hay ninguna opción para realizar montajes de lista de systemctl, puede enumerar los archivos de unidad de punto de montaje:
[root@testvm1 ~]# systemctl list-unit-files -t mount
UNIT FILE STATE
-.mount generated
boot.mount generated
dev-hugepages.mount static
dev-mqueue.mount static
home.mount generated
proc-fs-nfsd.mount static
proc-sys-fs-binfmt_misc.mount disabled
run-vmblock\x2dfuse.mount disabled
sys-fs-fuse-connections.mount static
sys-kernel-config.mount static
sys-kernel-debug.mount static
tmp.mount generated
usr.mount generated
var-lib-nfs-rpc_pipefs.mount static
var.mount generated
15 unit files listed.
[root@testvm1 ~]#
La columna ESTADO en este flujo de datos es interesante y requiere un poco de explicación. Los estados "generados" indican que la unidad de montaje se generó sobre la marcha durante el inicio utilizando la información en /etc/fstab . El programa que genera estas unidades de montaje es /lib/systemd/system-generators/systemd-fstab-generator, junto con otras herramientas que generan una serie de otros tipos de unidades. Las unidades de montaje "estáticas" son para sistemas de archivos como /proc y /sys , y los archivos para estos se encuentran en el /usr/lib/systemd/system directorio.
Ahora, mira las unidades de servicio. Este comando mostrará todos los servicios instalados en el host, estén o no activos:
[root@testvm1 ~]# systemctl --all -t service
La parte inferior de esta lista de unidades de servicio muestra 166 como el número total de unidades cargadas en mi host. Su número probablemente será diferente.
Los archivos unitarios no tienen una extensión de nombre de archivo (como .unit ) para ayudar a identificarlos, por lo que puede generalizar que la mayoría de los archivos de configuración que pertenecen a systemd son archivos unitarios de un tipo u otro. Los pocos archivos restantes son en su mayoría .conf archivos ubicados en /etc/systemd .
Los archivos de unidad se almacenan en /usr/lib/systemd directorio y sus subdirectorios, mientras que el /etc/systemd/ El directorio y sus subdirectorios contienen enlaces simbólicos a los archivos de la unidad necesarios para la configuración local de este host.
Para explorar esto, haga /etc/systemd la PWD y enumere su contenido. Luego haga /etc/systemd/system el PWD y enumere su contenido, y enumere el contenido de al menos un par de subdirectorios del PWD actual.
Eche un vistazo a default.target que determina en qué destino de nivel de ejecución se iniciará el sistema. En el segundo artículo de esta serie, expliqué cómo cambiar el destino predeterminado desde la GUI (graphical.target ) solo a la línea de comandos (multi-user.target ) objetivo. El objetivo.predeterminado archivo en mi VM de prueba es simplemente un enlace simbólico a /usr/lib/systemd/system/graphical.target .
Tómese unos minutos para examinar el contenido de /etc/systemd/system/default.target archivo:
[root@testvm1 system]# cat default.target
# SPDX-License-Identifier: LGPL-2.1+
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
Wants=display-manager.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target display-manager.service
AllowIsolate=yes
Tenga en cuenta que esto requiere el multi-user.target; el objetivo.gráfico no puede comenzar si multi-user.target aún no está en funcionamiento. También dice que "quiere" el display-manager.service unidad. No es necesario cumplir un "deseo" para que la unidad se inicie correctamente. Si el "deseo" no se puede cumplir, systemd lo ignorará y el resto del objetivo se iniciará de todos modos.
Los subdirectorios en /etc/systemd/system son listas de deseos para varios objetivos. Tómese unos minutos para explorar los archivos y su contenido en /etc/systemd/system/graphical.target.wants directorio.
La unidad systemd. La página de manual contiene mucha información útil sobre los archivos unitarios, su estructura, las secciones en las que se pueden dividir y las opciones que se pueden usar. También enumera muchos de los tipos de unidades, todos los cuales tienen sus propias páginas man. Si desea interpretar un archivo de unidad, este sería un buen lugar para comenzar.
Unidades de servicio
Una instalación de Fedora generalmente instala y habilita servicios que hosts particulares no necesitan para su funcionamiento normal. Por el contrario, a veces no incluye servicios que deben instalarse, habilitarse e iniciarse. Los servicios que no son necesarios para que el host de Linux funcione como se desea, pero que están instalados y posiblemente en ejecución, representan un riesgo de seguridad y, como mínimo, deben detenerse e inhabilitarse y, en el mejor de los casos, deben desinstalarse.
El comando systemctl se usa para administrar unidades systemd, incluidos servicios, objetivos, montajes y más. Eche un vistazo más de cerca a la lista de servicios para identificar los servicios que nunca se utilizarán:
[root@testvm1 ~]# systemctl --all -t service
UNIT LOAD ACTIVE SUB DESCRIPTION
<snip>
chronyd.service loaded active running NTP client/server
crond.service loaded active running Command Scheduler
cups.service loaded active running CUPS Scheduler
dbus-daemon.service loaded active running D-Bus System Message Bus
<snip>
● ip6tables.service not-found inactive dead ip6tables.service
● ipset.service not-found inactive dead ipset.service
● iptables.service not-found inactive dead iptables.service
<snip>
firewalld.service loaded active running firewalld - dynamic firewall daemon
<snip>
● ntpd.service not-found inactive dead ntpd.service
● ntpdate.service not-found inactive dead ntpdate.service
pcscd.service loaded active running PC/SC Smart Card Daemon
He eliminado la mayor parte de la salida del comando para ahorrar espacio. Los servicios que muestran "cargado activo en ejecución" son obvios. Los servicios "no encontrados" son los que systemd conoce pero no están instalados en el host de Linux. Si desea ejecutar esos servicios, debe instalar los paquetes que los contienen.
Tenga en cuenta el pcscd.service unidad. Este es el daemon de tarjeta inteligente PC/SC. Su función es comunicarse con lectores de tarjetas inteligentes. Muchos hosts de Linux, incluidas las máquinas virtuales, no necesitan este lector ni el servicio que se carga y consume recursos de memoria y CPU. Puede detener este servicio y deshabilitarlo, para que no se reinicie en el próximo arranque. Primero, verifique su estado:
[root@testvm1 ~]# systemctl status pcscd.service
● pcscd.service - PC/SC Smart Card Daemon
Loaded: loaded (/usr/lib/systemd/system/pcscd.service; indirect; vendor preset: disabled)
Active: active (running) since Fri 2019-05-10 11:28:42 EDT; 3 days ago
Docs: man:pcscd(8)
Main PID: 24706 (pcscd)
Tasks: 6 (limit: 4694)
Memory: 1.6M
CGroup: /system.slice/pcscd.service
└─24706 /usr/sbin/pcscd --foreground --auto-exit
May 10 11:28:42 testvm1 systemd[1]: Started PC/SC Smart Card Daemon.
Estos datos ilustran la información adicional que proporciona systemd frente a SystemV, que solo informa si el servicio se está ejecutando o no. Tenga en cuenta que especificar el .servicio el tipo de unidad es opcional. Ahora detenga y deshabilite el servicio, luego vuelva a verificar su estado:
[root@testvm1 ~]# systemctl stop pcscd ; systemctl disable pcscd
Warning: Stopping pcscd.service, but it can still be activated by:
pcscd.socket
Removed /etc/systemd/system/sockets.target.wants/pcscd.socket.
[root@testvm1 ~]# systemctl status pcscd
● pcscd.service - PC/SC Smart Card Daemon
Loaded: loaded (/usr/lib/systemd/system/pcscd.service; indirect; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2019-05-13 15:23:15 EDT; 48s ago
Docs: man:pcscd(8)
Main PID: 24706 (code=exited, status=1/FAILURE)
May 10 11:28:42 testvm1 systemd[1]: Started PC/SC Smart Card Daemon.
May 13 15:23:15 testvm1 systemd[1]: Stopping PC/SC Smart Card Daemon...
May 13 15:23:15 testvm1 systemd[1]: pcscd.service: Main process exited, code=exited, status=1/FAIL>
May 13 15:23:15 testvm1 systemd[1]: pcscd.service: Failed with result 'exit-code'.
May 13 15:23:15 testvm1 systemd[1]: Stopped PC/SC Smart Card Daemon.
La breve pantalla de entrada de registro para la mayoría de los servicios evita tener que buscar en varios archivos de registro para localizar este tipo de información. Compruebe el estado de los objetivos de nivel de ejecución del sistema; es necesario especificar el tipo de unidad "objetivo":
[root@testvm1 ~]# systemctl status multi-user.target
● multi-user.target - Multi-User System
Loaded: loaded (/usr/lib/systemd/system/multi-user.target; static; vendor preset: disabled)
Active: active since Thu 2019-05-09 13:27:22 EDT; 4 days ago
Docs: man:systemd.special(7)
May 09 13:27:22 testvm1 systemd[1]: Reached target Multi-User System.
[root@testvm1 ~]# systemctl status graphical.target
● graphical.target - Graphical Interface
Loaded: loaded (/usr/lib/systemd/system/graphical.target; indirect; vendor preset: disabled)
Active: active since Thu 2019-05-09 13:27:22 EDT; 4 days ago
Docs: man:systemd.special(7)
May 09 13:27:22 testvm1 systemd[1]: Reached target Graphical Interface.
[root@testvm1 ~]# systemctl status default.target
● graphical.target - Graphical Interface
Loaded: loaded (/usr/lib/systemd/system/graphical.target; indirect; vendor preset: disabled)
Active: active since Thu 2019-05-09 13:27:22 EDT; 4 days ago
Docs: man:systemd.special(7)
May 09 13:27:22 testvm1 systemd[1]: Reached target Graphical Interface.
El destino predeterminado es el destino gráfico. El estado de cualquier unidad se puede comprobar de esta manera.
Monta a la antigua
Una unidad de montaje define todos los parámetros necesarios para montar un sistema de archivos en un punto de montaje designado. systemd puede administrar unidades de montaje con más flexibilidad que las que usan /etc/fstab archivo de configuración del sistema de archivos. A pesar de esto, systemd aún usa /etc/fstab para fines de configuración y montaje del sistema de archivos. systemd usa el systemd-fstab-generator herramienta para crear unidades de montaje transitorias a partir de los datos en el fstab archivo.
Crearé un nuevo sistema de archivos y una unidad de montaje systemd para montarlo. Si tiene espacio disponible en disco en su sistema de prueba, puede hacerlo conmigo.
Tenga en cuenta que los nombres del grupo de volúmenes y del volumen lógico pueden ser diferentes en su sistema de prueba. Asegúrese de utilizar los nombres que sean pertinentes para su sistema.
Deberá crear una partición o un volumen lógico y luego crear un sistema de archivos EXT4 en él. Agregue una etiqueta al sistema de archivos, TestFS y cree un directorio para un punto de montaje /TestFS .
Para probar esto por su cuenta, primero verifique que tenga espacio libre en el grupo de volúmenes. Así es como se ve en mi VM donde tengo algo de espacio disponible en el grupo de volúmenes para crear un nuevo volumen lógico:
[root@testvm1 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 120G 0 disk
├─sda1 8:1 0 4G 0 part /boot
└─sda2 8:2 0 116G 0 part
├─VG01-root 253:0 0 5G 0 lvm /
├─VG01-swap 253:1 0 8G 0 lvm [SWAP]
├─VG01-usr 253:2 0 30G 0 lvm /usr
├─VG01-home 253:3 0 20G 0 lvm /home
├─VG01-var 253:4 0 20G 0 lvm /var
└─VG01-tmp 253:5 0 10G 0 lvm /tmp
sr0 11:0 1 1024M 0 rom
[root@testvm1 ~]# vgs
VG #PV #LV #SN Attr VSize VFree
VG01 1 6 0 wz--n- <116.00g <23.00g
Luego crea un nuevo volumen en VG01 llamado TestFS . No es necesario que sea grande; 1GB está bien. Luego cree un sistema de archivos, agregue la etiqueta del sistema de archivos y cree el punto de montaje:
[root@testvm1 ~]# lvcreate -L 1G -n TestFS VG01
Logical volume "TestFS" created.
[root@testvm1 ~]# mkfs -t ext4 /dev/mapper/VG01-TestFS
mke2fs 1.45.3 (14-Jul-2019)
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: 8718fba9-419f-4915-ab2d-8edf811b5d23
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
[root@testvm1 ~]# e2label /dev/mapper/VG01-TestFS TestFS
[root@testvm1 ~]# mkdir /TestFS
Ahora, monte el nuevo sistema de archivos:
[root@testvm1 ~]# mount /TestFS/
mount: /TestFS/: can't find in /etc/fstab.
Esto no funcionará porque no tiene una entrada en /etc/fstab . Puede montar el nuevo sistema de archivos incluso sin la entrada en /etc/fstab usando tanto el nombre del dispositivo (como aparece en /dev ) y el punto de montaje. Montar de esta manera es más simple de lo que solía ser:solía requerir el tipo de sistema de archivos como argumento. El comando de montaje ahora es lo suficientemente inteligente como para detectar el tipo de sistema de archivos y montarlo en consecuencia.
Inténtalo de nuevo:
[root@testvm1 ~]# mount /dev/mapper/VG01-TestFS /TestFS/
[root@testvm1 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 120G 0 disk
├─sda1 8:1 0 4G 0 part /boot
└─sda2 8:2 0 116G 0 part
├─VG01-root 253:0 0 5G 0 lvm /
├─VG01-swap 253:1 0 8G 0 lvm [SWAP]
├─VG01-usr 253:2 0 30G 0 lvm /usr
├─VG01-home 253:3 0 20G 0 lvm /home
├─VG01-var 253:4 0 20G 0 lvm /var
├─VG01-tmp 253:5 0 10G 0 lvm /tmp
└─VG01-TestFS 253:6 0 1G 0 lvm /TestFS
sr0 11:0 1 1024M 0 rom
[root@testvm1 ~]#
Ahora el nuevo sistema de archivos está montado en la ubicación adecuada. Enumere los archivos de la unidad de montaje:
[root@testvm1 ~]# systemctl list-unit-files -t mount
Este comando no muestra un archivo para /TestFS sistema de archivos porque no existe ningún archivo para él. El comando systemctl status TestFS.mount tampoco muestra ninguna información sobre el nuevo sistema de archivos. Puede probarlo usando comodines con el estado systemctl comando:
[root@testvm1 ~]# systemctl status *mount
● usr.mount - /usr
Loaded: loaded (/etc/fstab; generated)
Active: active (mounted)
Where: /usr
What: /dev/mapper/VG01-usr
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
<SNIP>
● TestFS.mount - /TestFS
Loaded: loaded (/proc/self/mountinfo)
Active: active (mounted) since Fri 2020-04-17 16:02:26 EDT; 1min 18s ago
Where: /TestFS
What: /dev/mapper/VG01-TestFS
● run-user-0.mount - /run/user/0
Loaded: loaded (/proc/self/mountinfo)
Active: active (mounted) since Thu 2020-04-16 08:52:29 EDT; 1 day 5h ago
Where: /run/user/0
What: tmpfs
● var.mount - /var
Loaded: loaded (/etc/fstab; generated)
Active: active (mounted) since Thu 2020-04-16 12:51:34 EDT; 1 day 1h ago
Where: /var
What: /dev/mapper/VG01-var
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Tasks: 0 (limit: 19166)
Memory: 212.0K
CPU: 5ms
CGroup: /system.slice/var.mount
Este comando proporciona información muy interesante sobre los montajes de su sistema y aparece su nuevo sistema de archivos. El /var y /usr los sistemas de archivos se identifican como generados desde /etc/fstab , mientras que su nuevo sistema de archivos simplemente muestra que está cargado y proporciona la ubicación del archivo de información en /proc/self/mountinfo archivo.
A continuación, automatice este montaje. Primero, hazlo a la antigua, agregando una entrada en /etc/fstab . Más adelante, te mostraré cómo hacerlo de la nueva manera, lo que te enseñará a crear unidades e integrarlas en la secuencia de inicio.
Desmontar /TestFS y agregue la siguiente línea a /etc/fstab archivo:
/dev/mapper/VG01-TestFS /TestFS ext4 defaults 1 2
Ahora, monte el sistema de archivos con el montaje más simple comando y enumere las unidades de montaje nuevamente:
[root@testvm1 ~]# mount /TestFS
[root@testvm1 ~]# systemctl status *mount
<SNIP>
● TestFS.mount - /TestFS
Loaded: loaded (/proc/self/mountinfo)
Active: active (mounted) since Fri 2020-04-17 16:26:44 EDT; 1min 14s ago
Where: /TestFS
What: /dev/mapper/VG01-TestFS
<SNIP>
Esto no cambió la información de este montaje porque el sistema de archivos se montó manualmente. Reinicie y ejecute el comando nuevamente, y esta vez especifique TestFS.mount en lugar de utilizar el comodín. Los resultados de este montaje ahora son consistentes con su montaje al inicio:
[root@testvm1 ~]# systemctl status TestFS.mount
● TestFS.mount - /TestFS
Loaded: loaded (/etc/fstab; generated)
Active: active (mounted) since Fri 2020-04-17 16:30:21 EDT; 1min 38s ago
Where: /TestFS
What: /dev/mapper/VG01-TestFS
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Tasks: 0 (limit: 19166)
Memory: 72.0K
CPU: 6ms
CGroup: /system.slice/TestFS.mount
Apr 17 16:30:21 testvm1 systemd[1]: Mounting /TestFS...
Apr 17 16:30:21 testvm1 systemd[1]: Mounted /TestFS.
Creación de una unidad de montaje
Las unidades de montaje se pueden configurar con el tradicional /etc/fstab archivo o con unidades systemd. Fedora usa el fstab archivo tal como se crea durante la instalación. However, systemd uses the systemd-fstab-generator program to translate the fstab file into systemd units for each entry in the fstab expediente. Now that you know you can use systemd .mount unit files for filesystem mounting, try it out by creating a mount unit for this filesystem.
First, unmount /TestFS . Edit the /etc/fstab file and delete or comment out the TestFS línea. Now, create a new file with the name TestFS.mount in the /etc/systemd/system directorio. Edit it to contain the configuration data below. The unit file name and the name of the mount point must be identical, or the mount will fail:
# This mount unit is for the TestFS filesystem
# By David Both
# Licensed under GPL V2
# This file should be located in the /etc/systemd/system directory
[Unit]
Description=TestFS Mount
[Mount]
What=/dev/mapper/VG01-TestFS
Where=/TestFS
Type=ext4
Options=defaults
[Install]
WantedBy=multi-user.target
The Description line in the [Unit] section is for us humans, and it provides the name that's shown when you list mount units with systemctl -t mount . The data in the [Mount] section of this file contains essentially the same data that would be found in the fstab archivo.
Now enable the mount unit:
[root@testvm1 etc]# systemctl enable TestFS.mount
Created symlink /etc/systemd/system/multi-user.target.wants/TestFS.mount → /etc/systemd/system/TestFS.mount.
This creates the symlink in the /etc/systemd/system directory, which will cause this mount unit to be mounted on all subsequent boots. The filesystem has not yet been mounted, so you must "start" it:
[root@testvm1 ~]# systemctl start TestFS.mount
Verify that the filesystem has been mounted:
[root@testvm1 ~]# systemctl status TestFS.mount
● TestFS.mount - TestFS Mount
Loaded: loaded (/etc/systemd/system/TestFS.mount; enabled; vendor preset: disabled)
Active: active (mounted) since Sat 2020-04-18 09:59:53 EDT; 14s ago
Where: /TestFS
What: /dev/mapper/VG01-TestFS
Tasks: 0 (limit: 19166)
Memory: 76.0K
CPU: 3ms
CGroup: /system.slice/TestFS.mount
Apr 18 09:59:53 testvm1 systemd[1]: Mounting TestFS Mount...
Apr 18 09:59:53 testvm1 systemd[1]: Mounted TestFS Mount.
This experiment has been specifically about creating a unit file for a mount, but it can be applied to other types of unit files as well. The details will be different, but the concepts are the same. Yes, I know it is still easier to add a line to the /etc/fstab file than it is to create a mount unit. But this is a good example of how to create a unit file because systemd does not have generators for every type of unit.
In summary
This article looked at systemd units in more detail and how to use the systemctl command to explore and manage units. It also showed how to stop and disable units and create a new systemd mount unit to mount a new filesystem and enable it to initiate during startup.
In the next article in this series, I will take you through a recent problem I had during startup and show you how I circumvented it using systemd.
Recursos
Hay una gran cantidad de información sobre systemd disponible en Internet, pero mucha es concisa, obtusa o incluso engañosa. Además de los recursos mencionados en este artículo, las siguientes páginas web ofrecen información más detallada y confiable sobre el inicio de systemd.
- El Proyecto Fedora tiene una buena guía práctica para systemd. Tiene prácticamente todo lo que necesita saber para configurar, administrar y mantener una computadora Fedora usando systemd.
- El Proyecto Fedora también tiene una buena hoja de trucos que hace una referencia cruzada de los comandos antiguos de SystemV con los de systemd comparables.
- Para obtener información técnica detallada sobre systemd y las razones para crearlo, consulte la descripción de systemd de Freedesktop.org.
- "More systemd fun" de Linux.com ofrece información y consejos más avanzados sobre systemd.
También hay una serie de artículos profundamente técnicos para administradores de sistemas Linux escritos por Lennart Poettering, el diseñador y desarrollador principal de systemd. Estos artículos fueron escritos entre abril de 2010 y septiembre de 2011, pero son tan relevantes ahora como lo fueron entonces. Gran parte de todo lo bueno que se ha escrito sobre systemd y su ecosistema se basa en estos documentos.
- Repensar el PID 1
- systemd para administradores, Parte I
- systemd para administradores, Parte II
- systemd para administradores, Parte III
- systemd para administradores, Parte IV
- systemd para administradores, Parte V
- systemd para administradores, Parte VI
- systemd para administradores, Parte VII
- systemd para administradores, Parte VIII
- systemd para administradores, Parte IX
- systemd para administradores, Parte X
- systemd para administradores, Parte XI