Sistema de inicio Linux y administrador del sistema - Aprendizaje Systemd

1. Descripción general del sistema

1.1 Introducción al programa init y su historial de desarrollo.

Linux initEl programa es el primer proceso que se inicia cuando se inicia el sistema y es responsable de inicializar los recursos del sistema, cargar los módulos centrales del sistema operativo e iniciar los servicios del sistema y los procesos del usuario. El programa init es una parte importante del inicio del sistema y proporciona un entorno básico para las operaciones posteriores del sistema. El programa init generalmente lo inicia el kernel del sistema operativo y es un proceso en modo de usuario. La ruta del programa init es /sbin/init(un enlace suave, vinculado al proceso init real). Su PID es 1. Es el "ancestro" de todos los procesos en el sistema., Todos los procesos en Linux son creados y ejecutados directa o indirectamente por el proceso init. El proceso init existe como un proceso demonio y es responsable de organizar y ejecutar el trabajo de inicialización relacionado del sistema y permitir que el sistema ingrese un modo de funcionamiento definido. En Linux, hay muchas formas de implementar el programa init, como SysV init, Upstart y Systemd.

El desarrollo del programa init se puede dividir aproximadamente en tres etapas: sysvinit->upstart->systemdSegún las características de desarrollo del proceso init, se puede entender simplemente de la siguiente manera:

inicio SysV

La primera distribución de Linux utilizaba SysV init (System V init), que utiliza scripts para administrar los servicios del sistema. Durante el proceso de inicio, SysV init iniciará los servicios del sistema en un orden específico y ejecutará el script de inicio correspondiente. La desventaja de SysV init es que se inicia lentamente porque necesita iniciar los servicios uno por uno en orden.

Advenedizo

Ubuntu ha adoptado Upstart como programa de inicio desde la versión 8.04. Upstart es un programa de inicio controlado por eventos que puede iniciar múltiples servicios en paralelo para mejorar la velocidad de inicio del sistema. Upstart utiliza archivos de configuración para administrar los servicios del sistema. Puede monitorear automáticamente el estado de los servicios y reiniciarlos automáticamente cuando fallan o dejan de ejecutarse.

sistemad

Systemd es actualmente el programa de inicio más popular y la mayoría de las distribuciones de Linux utilizan Systemd como programa de inicio predeterminado. A través del mecanismo de activación del socket, todos los programas con o sin dependencias se inician en paralelo, y solo se inician los servicios correspondientes según las necesidades del inicio del sistema, maximizando la velocidad de inicio. Systemd utiliza un único archivo de configuración para administrar todos los servicios y proporciona ricas herramientas de línea de comandos para administrar los servicios. Systemd también admite la carga y descarga dinámica de servicios, que se pueden agregar o eliminar mientras el sistema está en ejecución.

1.2 Arquitectura del sistema

Insertar descripción de la imagen aquí

La arquitectura del sistema es la siguiente:

Capa inferior: dependencias a nivel systemdde kernelcgroup、autofs、kdbus
La segunda capa: systemd librarieses la biblioteca dependiente de systemd.
La tercera capa: systemd Corees la biblioteca propia de systemd.
La cuarta capa: systemd daemonsy los objetivos son algunas unidades y objetivos básicos que vienen con ella, similares a los scripts que vienen con sysvinit.
La capa superior son algunas herramientas que interactúan con systemd, como systemctl;

Insertar descripción de la imagen aquí

1.3 Proceso del demonio Systemd

El proceso demonio de systemd se divide principalmente en estado del sistema (sistema) y estado de usuario (usuario)

ps -aux | grep systemd
root          1  0.1  0.0  50144  5864 ?        Ss    2022 361:29 /usr/lib/systemd/systemd --system --deserialize 17
root        618  0.0  0.0  44680  3632 ?        Ss    2022   0:00 /usr/lib/systemd/systemd-udevd
dbus        827  0.1  0.0  58228  4228 ?        Ss    2022 315:04 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
root        884  0.0  0.0  27208  3696 ?        Ss    2022 133:08 /usr/lib/systemd/systemd-logind
root      26750  0.0  0.0 112828  2320 pts/2    S+   16:29   0:00 grep --color=auto systemd
root      34868  0.1  0.0 100940 56832 ?        Ss   Mar18 111:11 /usr/lib/systemd/systemd-journald

La relación del proceso es la siguiente:

pstree -p | grep systemd
systemd(1)-+-xxx(17036)-+-{
    
    xxx}(17037)
           |                   |-containerd-shim(88298)-+-systemd(88315)
           |-systemd-journal(34868)
           |-systemd-logind(884)
           `-systemd-udevd(618)

El proceso con PID 1 /sbin/inites systemd en el estado del sistema. Es un enlace suave que apunta a la ruta real del sistema. Generalmente se coloca en /usr/lib/systemd/el directorio del sistema operativo:

ll /usr/sbin/init
lrwxrwxrwx. 1 root root 22 Mar  4  2022 /usr/sbin/init -> ../lib/systemd/systemd

ll /usr/lib/systemd/systemd
-rwxr-xr-x. 1 root root 1632800 Mar  4  2022 /usr/lib/systemd/systemd

systemd es el nombre general de una colección de servicios de procesos. Contiene muchos procesos y es responsable de controlar y administrar los recursos del sistema, incluida la systemd-logincreación, modificación y eliminación de información relacionada con el inicio de sesión del usuario; controlar systemd-sleepla hibernación del sistema y el cambio del estado de suspensión, etc. En el sistema operativo Ubuntu Kylin, se concentran principalmente en /usr/lib/systemd/directorios de archivos:

ls /usr/lib/systemd/
catalog                 rhel-loadmodules   systemd-cgroups-agent     systemd-localed            systemd-remount-fs      systemd-timedated       system-sleep
import-pubring.gpg      rhel-readonly      systemd-coredump          systemd-logind             systemd-reply-password  systemd-udevd           user
ntp-units.d             system             systemd-cryptsetup        systemd-machined           systemd-rfkill          systemd-update-done     user-generators
rhel-autorelabel        systemd            systemd-fsck              systemd-machine-id-commit  systemd-shutdown        systemd-update-utmp     user-preset
rhel-configure          systemd-ac-power   systemd-hibernate-resume  systemd-modules-load       systemd-shutdownd       systemd-user-sessions
rhel-dmesg              systemd-activate   systemd-hostnamed         systemd-pull               systemd-sleep           systemd-vconsole-setup
rhel-dmraid-activation  systemd-backlight  systemd-importd           systemd-quotacheck         systemd-socket-proxyd   system-generators
rhel-domainname         systemd-binfmt     systemd-initctl           systemd-random-seed        systemd-sysctl          system-preset
rhel-import-state       systemd-bootchart  systemd-journald          systemd-readahead          systemd-sysv-install    system-shutdown

2. Funciones del sistema

Systemd es un sistema de inicio y un administrador de sistemas para sistemas Linux. Es uno de los sistemas de inicio más populares y el sistema de inicio predeterminado para muchas distribuciones de Linux convencionales (como Fedora, Red Hat Enterprise Linux, Debian, etc.). Systemd proporciona muchas mejoras y optimizaciones en el inicio del sistema Linux, la gestión de servicios, el registro, etc.

2.1 Compatibilidad

systemd proporciona funciones compatibles con SysV init. Por ejemplo, el script de inicio SysV se puede admitir a través del modo de compatibilidad SysV, y el script de inicio SysV se puede convertir en una unidad de servicio Systemd a través de la herramienta systemd-sysv-generator, para admitir el proceso SysV. No es necesario modificar los servicios y procesos que ya existen en el sistema. Esto reduce el costo de la migración del sistema a systemd y hace posible reemplazar el sistema de inicialización existente con systemd.

2.2 Velocidad de inicio

Systemd es un sistema de inicio de inicio paralelo que, en comparación con el inicio SysV tradicional, puede iniciar múltiples servicios en paralelo, mejorando así la velocidad de inicio del sistema.
La velocidad de inicio de Systemd depende de la cantidad de servicios iniciados en el sistema y del orden en que se inician.

Durante el proceso de inicio, Systemd iniciará los servicios en paralelo de acuerdo con las dependencias entre servicios , para minimizar el tiempo de espera entre servicios y mejorar la velocidad de inicio. Al mismo tiempo, Systemd también priorizará los servicios e iniciará primero los servicios con alta prioridad para acelerar el tiempo de inicio del sistema.

Además del inicio paralelo, Systemd también proporciona algunas optimizaciones para mejorar la velocidad de inicio. Por ejemplo, utiliza un formato de registro binario para registrar los registros del sistema, que se pueden analizar y buscar más rápido que el formato de registro de texto tradicional. Además, Systemd también admite la carga y descarga dinámica de servicios , lo que puede agregar o eliminar servicios mientras el sistema se está ejecutando sin reiniciarlo, lo que reduce el tiempo de inactividad del sistema.

En general, Systemd se inicia relativamente rápido y puede lograr un inicio rápido en la mayoría de los sistemas, y también proporciona algunas medidas de optimización para mejorar aún más la velocidad de inicio.

2.3 systemd proporciona capacidades de inicio bajo demanda

Cuando se inicializa el sistema sysvinit, iniciará y ejecutará todos los procesos de servicio en segundo plano que puedan usarse. Y el sistema debe esperar a que se inicien todos los servicios antes de permitir que los usuarios inicien sesión. Este enfoque tiene dos desventajas: en primer lugar, el tiempo de inicio es demasiado largo y, en segundo lugar, es un desperdicio de recursos del sistema.

Es posible que algunos servicios no hayan sido utilizados durante mucho tiempo, o incluso durante toda la vida útil del servidor. Por ejemplo, CUPS, el servicio de impresión, rara vez se utiliza en la mayoría de los servidores. Es posible que no haya pensado que rara vez se accede a SSHD en muchos servidores. El tiempo dedicado a iniciar estos servicios es innecesario; del mismo modo, los recursos del sistema gastados en estos servicios son un desperdicio.

systemd puede brindar la capacidad de iniciarse bajo demanda, iniciando un servicio solo cuando realmente se solicita. Cuando finaliza el servicio, systemd puede cerrarlo e iniciarlo nuevamente la próxima vez que sea necesario.
Esto es algo similar a inetd en el sistema anterior, y hay muchos artículos sobre cómo migrar servicios administrados por inetd en el pasado a systemd.

Systemd ofrece la posibilidad de iniciar servicios bajo demanda. Esta característica a menudo se denomina "carga diferida al inicio". El inicio bajo demanda significa que todos los servicios o unidades de servicio no se inician inmediatamente cuando se inicia el sistema, sino que se inician cuando es necesario. Este método puede reducir el tiempo de inicio del sistema y el uso de recursos, y evitar el inicio innecesario del servicio.

La función de inicio bajo demanda de Systemd se implementa mediante el mecanismo de "carga diferida al inicio". Según este mecanismo, Systemd sólo iniciará un servicio específico cuando sea necesario. Por ejemplo, Systemd inicia automáticamente un servicio cuando un usuario intenta acceder a él por primera vez. Este método permite iniciar solo los servicios o unidades de servicio que se utilizan en el sistema, lo que reduce el tiempo de inicio del sistema y el uso de recursos.

Cabe señalar que la función de iniciar servicios bajo demanda requiere el apoyo de la unidad de servicio. Si una unidad de servicio no admite el inicio bajo demanda, la unidad de servicio se iniciará inmediatamente cada vez que se inicie el sistema. Por lo tanto, al configurar el servicio Systemd, se debe prestar especial atención a la configuración del mecanismo de inicio bajo demanda.

2.4 Utilice cgroups de Linux para rastrear y gestionar el ciclo de vida del proceso.

systemd utiliza la función del kernel de Linux, concretamente cgroups, para completar la tarea de seguimiento. cgroups es un mecanismo proporcionado por el kernel de Linux para el aislamiento de recursos y la restricción de procesos. A través de cgroups, puede limitar el uso de CPU, memoria, disco, red y otros recursos del proceso, y administrar y monitorear el proceso. Al detener un servicio, al consultar cgroups, systemd puede garantizar que se encuentren todos los procesos relevantes, deteniendo así el servicio limpiamente.
Los cgroups existen desde hace mucho tiempo y se utilizan principalmente para implementar la gestión de cuotas de recursos del sistema. cgroups proporciona una interfaz similar a un sistema de archivos que es fácil de usar. Cuando un proceso crea un proceso hijo, el proceso hijo hereda los grupos c del proceso padre. Por lo tanto, no importa cómo el servicio inicie un nuevo proceso hijo, todos estos procesos relacionados pertenecerán a los mismos cgroups, y systemd solo necesita atravesar los cgroups especificados para encontrar correctamente todos los procesos relacionados y detenerlos uno por uno.

Systemd utiliza cgroups para administrar y rastrear procesos. Al crear cgroups, los procesos se agrupan, aíslan y restringen. En Systemd, cada unidad de servicio se asigna a un cgroup, que contiene todos los procesos de la unidad de servicio, para lograr el aislamiento y la limitación de recursos de todos los procesos.

Al utilizar cgroups, Systemd puede rastrear y gestionar el ciclo de vida de los procesos. Por ejemplo, puede establecer el tiempo de uso de la CPU, el límite de memoria, el límite de IO, etc. del proceso en cgroups, para lograr el límite de recursos del proceso. Además, Systemd también puede utilizar cgroups para el seguimiento y registro de procesos, proporcionando así mejores funciones de gestión del sistema.

2.5. Iniciar la gestión de puntos de montaje y montaje automático.

En los sistemas Linux tradicionales, los usuarios pueden usar /etc/fstabarchivos para mantener puntos de montaje fijos del sistema de archivos. Estos puntos de montaje se montan automáticamente durante el inicio del sistema y se garantiza que existirán una vez que se complete el proceso de inicio. Estos puntos de montaje son sistemas de archivos que son críticos para el funcionamiento del sistema, como el directorio HOME. Al igual que sysvinit, Systemd administra estos puntos de montaje para que puedan montarse automáticamente al iniciar el sistema. systemd también es compatible con el archivo /etc/fstab, que puede seguir usando para administrar los puntos de montaje.

Systemd utiliza "unidades de montaje" para administrar los puntos de montaje, y cada unidad de montaje corresponde a un punto de montaje. La unidad de montaje es una unidad de servicio en Systemd, que contiene la información de configuración del punto de montaje, incluido el tipo de sistema de archivos, las opciones de montaje, el dispositivo donde se encuentra el punto de montaje, la ruta del punto de montaje, etc.

En Systemd, puede usar systemd-mountcomandos para administrar unidades de montaje, incluidas operaciones como crear, modificar y eliminar unidades de montaje. Systemd también admite el montaje al inicio y el montaje automático, que se puede lograr de las siguientes maneras:

“Wants”Montar al inicio: establezca “Requires”dependencias en la unidad de montaje para que los dispositivos o puntos de montaje relacionados se monten automáticamente cuando se inicie el sistema.
Montaje automático: configúrelo en la unidad de montaje “AutoMount”para “yes”que cuando se acceda al dispositivo o punto de montaje relevante, Systemd monte automáticamente el dispositivo o punto de montaje.

Si hay una dependencia circular, systemd no podrá iniciar ningún servicio. En este momento, systemd intentará resolver este problema, porque hay dos tipos de dependencias entre colmenas: requerida es una dependencia fuerte, deseada es una dependencia débil. Systemd eliminará la dependencia especificada por la palabra clave want para ver si se puede romper. el ciclo. Si no se puede reparar, systemd informará un error. systemd puede detectar y corregir automáticamente dichos errores de configuración, lo que reduce en gran medida la carga de resolución de problemas del administrador.

Cabe señalar que cuando utiliza Systemd para la gestión de puntos de montaje, debe prestar especial atención a las dependencias y el orden de montaje de los puntos de montaje. Por ejemplo, si el punto de montaje A depende del punto de montaje B, deberá montar B antes de poder montar A. Por lo tanto, al configurar la unidad de montaje, se debe prestar especial atención a las dependencias y al orden de montaje de los puntos de montaje para garantizar que el sistema de archivos se monte y utilice correctamente.

A veces los usuarios también necesitan puntos de montaje dinámicos. Por ejemplo, cuando planean acceder a contenido compartido de DVD o NFS, el montaje se realiza temporalmente para acceder al contenido. Cuando no se accede al disco, el punto de montaje se cancela (desmonta) para ahorrar recursos. . . Tradicionalmente, la gente ha confiado en el servicio autofs para lograr esta funcionalidad.
Systemd tiene un servicio de montaje automático incorporado. No es necesario instalar un servicio autofs adicional. Puede utilizar directamente las capacidades de gestión de montaje automático proporcionadas por systemd para implementar las funciones de autofs.

2.6 Realizar la gestión de dependencia transaccional

El proceso de inicio del sistema se compone de muchas tareas independientes y puede haber dependencias entre estas tareas. Por ejemplo, montar un sistema de archivos NFS debe depender de la red para funcionar correctamente. Aunque systemd puede ejecutar muchas tareas dependientes al mismo tiempo al máximo, tareas como "montar NFS" e "iniciar la red" todavía tienen dependencias inherentes y no se pueden ejecutar al mismo tiempo. Para estas tareas, systemd mantiene un concepto de "consistencia de transacciones" para garantizar que todos los servicios relacionados puedan iniciarse normalmente sin interdependencia ni bloqueo.

En Systemd, cada unidad de servicio puede especificar un conjunto de dependencias, que pueden ser otras unidades de servicio, sockets, puntos de montaje, etc. Systemd utiliza la gestión de dependencias transaccionales para garantizar que las dependencias se inicien en el orden correcto y para pausar o finalizar unidades de servicio cuando las dependencias no se satisfacen.

La idea central de la gestión de dependencias transaccionales es la transacción (transacción), que consiste en combinar todas las dependencias en una transacción en el orden correcto e iniciar, detener o reiniciar la unidad de servicio en la transacción. Cuando las dependencias de una unidad de servicio no se satisfacen, Systemd pausará o finalizará la unidad de servicio y esperará a que se cumplan las dependencias antes de reiniciar.

En Systemd, la implementación de la gestión de dependencia transaccional incluye principalmente los siguientes aspectos:

Análisis del gráfico de dependencia: Systemd utiliza un gráfico de dependencia para describir las dependencias entre unidades de servicio y determina la secuencia de inicio correcta analizando el gráfico de dependencia.
Administrador de transacciones: Systemd utiliza un administrador de transacciones para administrar el inicio, detención o reinicio de las dependencias, y para suspender o eliminar unidades de servicio cuando no se cumplen las dependencias.
Seguimiento del estado de dependencia: Systemd rastrea el estado de cada dependencia y recalcula las dependencias cuando cambia el estado de la dependencia.

A través de la gestión de dependencias transaccionales, Systemd puede garantizar que las unidades de servicio se inicien en el orden correcto y pausar o finalizar las unidades de servicio cuando no se cumplan las dependencias, mejorando así la estabilidad y confiabilidad del sistema.

2.7 Servicio de registro

systemd tiene su propio servicio de registro, journald, que es responsable de recopilar, almacenar y administrar los registros del sistema. Puede registrar toda la información de registro al inicio del sistema, incluidos los registros del kernel, los registros de aplicaciones y los registros de servicios. En Journald, cada registro se denomina "entrada de registro", que contiene el texto del registro, la marca de tiempo, la prioridad, la fuente y otra información. El servicio de registro está diseñado para superar las deficiencias del servicio syslog existente. Por ejemplo:

syslog no es seguro y no se puede verificar el contenido del mensaje. Cada proceso local puede afirmar que es Apache PID 4711, y syslog lo creerá y lo guardará en el disco.
Los datos no tienen un formato estricto y son muy arbitrarios. Los analizadores de registros automatizados necesitan analizar cadenas de lenguaje humano para identificar mensajes. Por un lado, este tipo de análisis es difícil e ineficiente; por otro lado, los cambios en el formato del registro harán que sea necesario actualizar o incluso reescribir el código de análisis.
systemd journal guarda toda la información de registro en formato binario y los usuarios usan el comando journalctl para ver la información de registro. No es necesario que usted mismo escriba controladores de análisis de cadenas complejos y frágiles.

Las ventajas de systemd journal son las siguientes:

简单性：代码少，依赖少，抽象开销最小。
零维护：日志是除错和监控系统的核心功能，因此它自己不能再产生问题。举例说，自动管理磁盘空间，避免由于日志的不断产生而将磁盘空间耗尽。
移植性：日志文件应该在所有类型的 Linux 系统上可用，无论它使用的何种 CPU 或者字节序。
性能：添加和浏览日志非常快。
最小资源占用：日志数据文件需要较小。
统一化：各种不同的日志存储技术应该统一起来，将所有的可记录事件保存在同一个数据存储中。所以日志内容的全局上下文都会被保存并且可供日后查询。例如一条固件记录后通常会跟随一条内核记录，最终还会有一条用户态记录。重要的是当保存到硬盘上时这三者之间的关系不会丢失。syslog 将不同的信息保存到不同的文件中，分析的时候很难确定哪些条目是相关的。
扩展性：日志的适用范围很广，从嵌入式设备到超级计算机集群都可以满足需求。
安全性：日志文件是可以验证的，让无法检测的修改不再可能。

Las principales funciones del servicio de registro Systemd incluyen:

Rotación automática: journald puede rotar automáticamente los archivos de registro para evitar que se vuelvan demasiado grandes y puede limitar el tamaño y la cantidad de archivos de registro.
Filtrado de mensajes: journald puede filtrar registros según prioridad, fuente, ID de proceso y otras condiciones, lo que facilita la visualización de la información de registro de interés.
Reenvío de registros: journald puede reenviar registros a servidores remotos u otros sistemas de recopilación de registros para facilitar la administración y el monitoreo centralizados.
Garantía de confiabilidad: Journald puede garantizar la seguridad y confiabilidad de los registros mediante cifrado, verificación de integridad, etc.

Al utilizar el servicio de registro Systemd, puede utilizar la herramienta journalctl para ver y administrar los registros del sistema. La herramienta Journalctl proporciona una gran cantidad de opciones de consulta, que pueden consultar información de registro según el tiempo, palabras clave, prioridades y otras condiciones, lo que facilita la resolución de problemas y el diagnóstico de fallas.

En general, el servicio de registro Systemd proporciona poderosas funciones de administración de registros del sistema: recopila, almacena y administra registros del sistema a través del demonio journald, lo que hace que sea conveniente para los desarrolladores y administradores del sistema ver y analizar los registros del sistema y mejorar la confiabilidad del sistema. y manejabilidad.

3. Unidad sistematizada

La unidad Systemd es la unidad básica para administrar y controlar los recursos, servicios o tareas del sistema en Systemd. Cada unidad tiene un nombre, tipo y archivo de configuración únicos, y la secuencia de inicio y parada de la unidad se controla a través de dependencias, logrando así el control. Gestión y control de los recursos y servicios del sistema.

3.1 Unidades comunes

La unidad se divide en 12 tipos.

Service unit(.service): Se utiliza para encapsular un proceso de servicio en segundo plano.
Target unit(.target): Esta colmena es una agrupación lógica de otras colmenas. En realidad, no hacen nada por sí mismas, solo hacen referencia a otras colmenas. Esto permite un control unificado de la unidad de configuración. Esto permite implementar el concepto familiar de niveles de ejecución. Por ejemplo, si desea que el sistema ingrese al modo gráfico, necesita ejecutar muchos servicios y comandos de configuración. Estas operaciones están representadas por unidades de configuración una por una. Combinar todas estas unidades de configuración en un objetivo significa que necesita ejecutar todas de estas unidades de configuración Una vez para ingresar al estado de ejecución del sistema representado por el objetivo. (Por ejemplo: multi-user.target es equivalente al nivel de ejecución 5 en sistemas que utilizan SysV tradicional)
Device Unit(.device): esta colmena encapsula un dispositivo que existe en el árbol de dispositivos de Linux. Cada dispositivo etiquetado con una regla udev aparecerá en systemd como una colmena de dispositivos. Para dispositivos en el directorio /dev
Mount Unit(.mount): esta colmena encapsula un punto de montaje en la jerarquía del sistema de archivos. Systemd monitoreará y administrará este punto de montaje. Por ejemplo, se puede montar automáticamente al inicio; se puede desinstalar automáticamente bajo ciertas condiciones. Systemd convertirá todas las entradas en /etc/fstab en puntos de montaje y las procesará en el arranque.
Automount Unit(.automount): este tipo de colmena encapsula un punto de automontaje en la jerarquía de la estructura del sistema. Cada subárbol de montaje automático corresponde a un subárbol de montaje, y cuando se accede al punto de montaje automático, systemd ejecuta el comportamiento de montaje definido en el punto de montaje.
Path Unit(.path): un archivo o directorio en el sistema de archivos. Se utiliza para monitorear cambios en directorios o archivos específicos y activar la ejecución de otras Unidades
Scope Unit(): Se utiliza para cgroups y representa procesos creados desde fuera de systemd. Este tipo de archivo de unidad no lo crea el usuario, sino que se genera cuando se ejecuta Systemd y describe la información de agrupación de algunos servicios del sistema.
Slice Unit(*.slice): El grupo de procesos, utilizado en cgroups, representa un grupo de unidades organizadas jerárquicamente. El segmento no contiene procesos, pero forma una jerarquía y coloca ámbitos y servicios en él.
Snapshot Unit(.snapshot): Se utiliza para indicar una instantánea del estado de ejecución de las unidades Systemd creadas por el comando systemctl snapshot.Similar a la unidad de configuración de destino, la instantánea es un grupo de unidades de configuración. Guarda el estado de ejecución actual del sistema.
Socket Unit(.socket): Esta colmena encapsula un socket en el sistema e Internet. Actualmente, systemd admite sockets AF_INET, AF_INET6 y AF_UNIX de streaming, datagramas y paquetes continuos. Cada subárbol de socket tiene un subárbol de servicio correspondiente. El servicio correspondiente se iniciará cuando la primera "conexión" ingrese al socket (por ejemplo: nscd.socket inicia nscd.service después de una nueva conexión)
Swap Unit(.swap): Similar a la colmena de montaje, la colmena de intercambio se utiliza para administrar la partición de intercambio. Los usuarios pueden usar la unidad de configuración de intercambio para definir las particiones de intercambio en el sistema, que se pueden activar al inicio.
Timer Unit(.timer): La unidad de configuración del temporizador se utiliza para activar periódicamente operaciones definidas por el usuario. Este tipo de unidad de configuración reemplaza los servicios de sincronización tradicionales como atd y crontab.

# 列出正在运行的 Unit
$ systemctl list-units
systemctl list-units
  UNIT                                                                  LOAD      ACTIVE SUB       DESCRIPTION
  proc-sys-fs-binfmt_misc.automount                                     loaded    active running   Arbitrary Executable File Formats File System Automount Point
  sys-devices-pci0000:00-0000:00:03.0-virtio0-virtio\x2dports-vport0p1.device loaded    active plugged   /sys/devices/pci0000:00/0000:00:03.0/virtio0/virtio-ports/vpo
  sys-devices-pci0000:00-0000:00:04.0-virtio1-block-vda-vda1.device     loaded    active plugged   /sys/devices/pci0000:00/0000:00:04.0/virtio1/block/vda/vda1
  sys-devices-platform-serial8250-tty-ttyS1.device                      loaded    active plugged   /
......

# 列出所有Unit，包括没有找到配置文件的或者启动失败的
$ systemctl list-units --all

# 列出所有没有运行的 Unit
$ systemctl list-units --all --state=inactive
 UNIT                                                  LOAD      ACTIVE   SUB  DESCRIPTION
  sys-fs-fuse-connections.mount                         loaded    inactive dead FUSE Control File System
  tmp.mount                                             loaded    inactive dead Temporary Directory
  systemd-ask-password-console.path                     loaded    inactive dead Dispatch Password Requests to Console Directory Watch
● display-manager.service                               not-found inactive dead display-manager.service
  ....
# 列出所有加载失败的 Unit
$ systemctl list-units --failed
  UNIT                         LOAD      ACTIVE SUB    DESCRIPTION
● disable_printk_relax.service loaded    failed failed (null)
● httpd.service                loaded    failed failed The Apache HTTP Server
● mariadb.service              loaded    failed failed MariaDB database server
● postfix.service              loaded    failed failed Postfix Mail Transport Agent
● rc-local.service             loaded    failed failed /etc/rc.d/rc.local Compatibility
● walle.service                not-found failed failed walle.service

# 列出所有正在运行的、类型为 service 的 Unit
$ systemctl list-units --type=service

3.2 Directorio systemd

/etc/systemd/system/: este directorio contiene los archivos de configuración de todos los archivos de la unidad de servicio del sistema local, incluidos los servicios del sistema y los servicios de usuario que se ejecutan al inicio.

ls /etc/systemd/system
aegis.service       cpupower.service  default.target.wants  graphical.target.wants  multi-user.target.wants  sysinit.target.wants
basic.target.wants  default.target    getty.target.wants    local-fs.target.wants   sockets.target.wants     system-update.target.wants

/usr/lib/systemd/system/: este directorio contiene los archivos de la unidad de servicio de todo el software instalado, incluidos los servicios del sistema y los servicios de software de terceros.

ls /usr/lib/systemd/system
arp-ethers.service                      halt.target.wants                  poweroff.target.wants                          systemd-ask-password-console.path
atd.service                             hibernate.target                   printer.target                                 systemd-ask-password-console.service
auditd.service                          htcacheclean.service               proc-sys-fs-binfmt_misc.

...

/run/systemd/system/: Este directorio contiene todos los archivos de unidades de servicio en ejecución, que se generan en función de los archivos en los directorios /etc/systemd/system/ y /usr/lib/systemd/system/.

ls /run/systemd/system
session-215677.scope    session-401915.scope.d  session-402358.scope    session-c4042067.scope.d  session-c6917125.scope    user-0.slice.d
session-215677.scope.d  session-401918.scope    session-402358.scope.d  session-c5481555.scope    session-c6917125.scope.d  user-1367771.slice
session-285125.scope    session-401918.scope.d  session-c16.scope       session-c5481555.scope.d  session-c92156.scope      user-1367771.slice.d
session-285125.scope.d  session-401919.scope    session-c16.scope.d     session-c56.scope         session-c92156.scope.d
session-401915.scope    session-401919.scope.d  session-c4042067.scope  session-c56.scope.d       user-0.slice

/etc/systemd/system.conf: Este archivo contiene la configuración global de Systemd.
/etc/systemd/user/: Este directorio contiene archivos de unidades de servicio definidos por el usuario, que se iniciarán automáticamente cuando el usuario inicie sesión.
/etc/systemd/logind.conf: Este archivo contiene la configuración del administrador de inicio de sesión, que se utiliza para administrar la sesión cuando el usuario inicia sesión.
/etc/systemd/systemd-journald.conf`: este archivo contiene la configuración del registro de diario, que se utiliza para administrar el registro del sistema.
/etc/systemd/timesyncd.conf: Este archivo contiene la configuración del servicio de sincronización horaria timesyncd.
/usr/lib/systemd/systemd-sleep: este directorio contiene scripts de servicio relacionados con el modo de suspensión.

3.3 Unidad y objetivo

Unidad: La unidad es el componente básico de Systemd y se utiliza para definir los servicios del sistema y otros recursos, incluida la secuencia de inicio del servicio, las dependencias, el estado de implementación, etc. Cada Unidad tiene un nombre y tipo únicos, como servicio, enchufe, montaje, etc.

En el archivo de la Unidad se puede definir la siguiente información:

Unit 的类型、名称和描述
Unit 之间的依赖关系和启动顺序
Unit 的执行程序、启动参数和环境变量
Unit 的状态和执行结果
Unit 的启动、停止、重启和状态查询等操作

Objetivo: El objetivo es una colección de Unidades relacionadas, que se utiliza para definir el estado objetivo de la operación del sistema. Cada Objetivo tiene un nombre único y un conjunto de Unidades dependientes. Cuando se inicia el sistema, Systemd intentará iniciar el Objetivo especificado para cumplir con los requisitos del sistema.

En el archivo de destino, puede definir la siguiente información:

Target 的名称和描述
Target 所包含的 Unit 和依赖关系
Target 的启动、停止、重启和状态查询等操作

El tipo de Objetivo es similar al tipo de Unidad, como multiusuario, gráfico, red, etc. Entre ellos, multi-user.target se usa para iniciar la interfaz de línea de comandos multiusuario, graphical.target se usa para iniciar la interfaz gráfica, network.target se usa para iniciar el servicio de red, etc.

En resumen, Unidad y Objetivo son los conceptos centrales de Systemd. Al definir Unidad y Objetivo, los servicios y el estado del sistema se pueden administrar y controlar.

# 查看target类型的unit
$ systemctl list-unit-files --type=target

# 查看指定target下面有哪些unit
$ systemctl list-dependencies multi-user.target

# 查看系统默认的target
$ systemctl get-default
multi-user.target

sudo systemctl set-default multi-user.target
# 切换 Target 时，默认不关闭前一个 Target 启动的进程，systemctl isolate 命令改变这种行为，关闭前一个 Target 里面所有不属于后一个 Target 的进程
sudo systemctl isolate multi-user.target
# 查看配置文件
systemctl cat multi-user.target

# 修改配置文件以后，需要重新加载配置文件，然后重新启动相关服务
# 重新加载配置文件
sudo systemctl daemon-reload
# 重启相关服务
sudo systemctl restart foobar

cat /usr/lib/systemd/system/sshd.service//Comprueba a qué objetivo pertenece un servicio, solo necesitas mirar [install]la parte para ver a qué objetivo pertenece.

$ cat /usr/lib/systemd/system/sshd.service
[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.service
Wants=sshd-keygen.service

[Service]
Type=notify
EnvironmentFile=/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

Las principales diferencias entre los procesos Target y SysV-init:

El RunLevel predeterminado (establecido en el archivo /etc/inittab) ahora se reemplaza por el Target predeterminado, generalmente un /etc/systemd/system/default.targetenlace simbólico a graphical.target (interfaz gráfica) o multi-user.target (línea de comando multiusuario).
La ubicación del script de inicio, que solía ser /etc/init.del directorio, enlaza simbólicamente a diferentes directorios RunLevel (como /etc/rc3.d, /etc/rc5.d, etc.), ahora se almacena en /lib/systemd/system 和 /etc/systemd/systemel directorio .
La ubicación del archivo de configuración, el archivo de configuración anterior del proceso de inicio /etc/inittaby los archivos de configuración de varios servicios se almacenan en /etc/sysconfigel directorio. Los archivos de configuración actuales se almacenan principalmente en /lib/systemdel directorio y /etc/systemdlas modificaciones en el directorio pueden sobrescribir la configuración original.

3.4 Estado de la unidad

En Systemd, el estado de Unidad tiene los siguientes tipos:

active (running): La unidad está funcionando.
active (exited): La unidad ha terminado de funcionar y ha salido.
inactive (dead): La unidad ha dejado de funcionar.
activating (start): La unidad está iniciando.
activating (auto-restart): La unidad se reinicia automáticamente.
deactivating (stop): La unidad se está deteniendo.
deactivating (restart): La unidad se está reiniciando.
failed: La unidad no pudo arrancar o se detuvo repentinamente durante el funcionamiento.

Comandos comunes

# 显示系统状态
$ systemctl status

# 显示单个 Unit 的状态
$ sysystemctl status bluetooth.service

# 显示远程主机的某个 Unit 的状态
$ systemctl -H [email protected] status httpd.service

# 显示某个 Unit 是否正在运行
$ systemctl is-active application.service

# 显示某个 Unit 是否处于启动失败状态
$ systemctl is-failed application.service

# 显示某个 Unit 服务是否建立了启动链接
$ systemctl is-enabled application.service

3.5 Comandos comunes de gestión de unidades

# 立即启动一个服务
$ sudo systemctl start apache.service

# 立即停止一个服务
$ sudo systemctl stop apache.service

# 重启一个服务
$ sudo systemctl restart apache.service

# 杀死一个服务的所有子进程
$ sudo systemctl kill apache.service

# 重新加载一个服务的配置文件
$ sudo systemctl reload apache.service

# 重载所有修改过的配置文件
$ sudo systemctl daemon-reload

# 显示某个 Unit 的所有底层参数
$ systemctl show httpd.service

# 显示某个 Unit 的指定属性的值
$ systemctl show -p CPUShares httpd.service

# 设置某个 Unit 的指定属性
$ sudo systemctl set-property httpd.service CPUShares=500

3.6 Dependencias de unidades

En Systemd, se pueden establecer dependencias entre Unidades para garantizar que comiencen y finalicen en el orden correcto. Los siguientes son varios tipos de dependencias entre Unidades:

Requires: Indica que la Unidad A depende de la Unidad B. Si la Unidad B no puede iniciar, la Unidad A tampoco puede iniciar.
Wants: Indica que la Unidad A quiere depender de la Unidad B, pero si la Unidad B no puede iniciar, la Unidad A aún puede comenzar.
RequiresOverridable: Similar a Requiere, pero permite anular las Unidades dependientes al inicio, como cuando se ejecuta en un contenedor.
BindsTo: Indica que la Unidad A depende de la Unidad B. Si la Unidad B deja de funcionar, la Unidad A también se detendrá.
PartOf: Indica que la Unidad A es parte de la Unidad B. Si la Unidad B deja de funcionar, la Unidad A también se detendrá.
Conflicts: Indica que la Unidad A entra en conflicto con la Unidad B. Si la Unidad B está funcionando, la Unidad A no puede iniciarse.

En un archivo Unit, las dependencias se pueden definir usando la siguiente sintaxis:

[Unit]
Requires=unit1.service
Wants=unit2.service
BindsTo=unit3.socket
PartOf=unit4.target
Conflicts=unit5.service

Entre ellos, unit1.service, unit2.service, etc. son todos nombres de Unidad. Al establecer dependencias correctas, puede garantizar que los servicios del sistema se inicien y se detengan en el orden correcto, evitando así problemas causados por dependencias incorrectas.
Comandos de uso común:

# 列出一个 Unit 的所有依赖
$ systemctl list-dependencies nginx.Service

# 上述命令默认不会显示target 类型依赖，需要展示，使用如下命令
$ systemctl list-dependencies --all nginx.service

3.7 archivo unitario

Tomemos /usr/lib/systemd/system/docker.servicecomo ejemplo, aprendamos a escribir archivos unitarios:

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
BindsTo=containerd.service
After=network-online.target firewalld.service containerd.service
Wants=network-online.target
Requires=docker.socket

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutSec=0
RestartSec=2
Restart=always

# Note that StartLimit* options were moved from "Service" to "Unit" in systemd 229.
# Both the old, and new location are accepted by systemd 229 and up, so using the old location
# to make them work for either version of systemd.
StartLimitBurst=3

# Note that StartLimitInterval was renamed to StartLimitIntervalSec in systemd 230.
# Both the old, and new name are accepted by systemd 230 and up, so using the old name to make
# this option work for either version of systemd.
StartLimitInterval=60s

# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity

# Comment TasksMax if your systemd version does not supports it.
# Only systemd 226 and above support this option.
TasksMax=infinity

# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes

# kill only the docker process, not all processes in the cgroup
KillMode=process

[Install]
WantedBy=multi-user.target

Sección de Unidad: Esta sección es común a todos los archivos de Unidad y se utiliza para definir los metadatos, la configuración y la relación de la Unidad con otras Unidades. La Descripción describe la información del archivo de la Unidad, la Documentación representa el documento del servicio especificado y la Condición representa las condiciones para el servicio. inicio Algunas Unidades también incluyen campos de deseos, antes, después y requeridos, estos representan una dependencia del servicio.
Sección de instalación: esta sección es común a todos los archivos de Unit. Por lo general, especifica el destino del objetivo en ejecución para que el servicio se ejecute automáticamente cuando se inicia el sistema. Wantedby y RequiredBy son similares al campo Wants del segmento Unit, que indica dependencias, y el campo Alias indica el alias utilizado al iniciar la ejecución.
Segmento de servicio: un campo exclusivo de los archivos de Unidad del tipo de servicio, utilizado para definir las acciones específicas de gestión y ejecución del servicio. Incluye el campo Tipo, que define el comportamiento del proceso, como comenzar usando fork(), comenzar usando dbus, etc.; ExecStart, ExecStartPre, ExecStartPos, ExecReload y ExecStop representan respectivamente el comando ejecutado antes de iniciar el servicio actual. el comando ejecutado antes de iniciar el servicio actual y los comandos de inicio que se iniciarán después del servicio actual, los comandos que se ejecutarán al reiniciar el servicio actual y los comandos que se ejecutarán al detener el servicio actual.

3.7.1 Parámetros del segmento unitario

Description: Información que describe este archivo de unidad
Documentation: Especifica el documento del servicio, que puede ser la ruta URL de uno o más documentos.
Requires: Una lista de otras Unidades dependientes. Las plantillas de Unidad enumeradas en ella se iniciarán al mismo tiempo que se inicia este servicio. Y si alguno de los servicios no se inicia, el servicio también se cancelará.
Wants: Similar a Requiere, pero solo activa el inicio de cada módulo de Unidad enumerado cuando se inicia la Unidad configurada, independientemente de si el inicio de estas plantillas es exitoso.
After: Similar a Requiere, pero el servicio actual no se iniciará hasta que se hayan iniciado todos los módulos enumerados más adelante.
Before: A diferencia de Después, antes de iniciar una tarea o módulo específico, primero confirmará que el servicio actual se está ejecutando.
Binds To: Similar a Requiere, falla cuando falla y tiene éxito cuando tiene éxito, pero cuando cualquiera de estas plantillas finaliza inesperadamente o se reinicia, el servicio también finalizará o se reiniciará.
Part Of: Un subconjunto de funciones Vincular a, solo finaliza o reinicia el servicio actual cuando los módulos de tareas enumerados fallan o se reinician, y no se iniciará con el inicio de las plantillas enumeradas.
OnFailure: Cuando esta plantilla no se inicia, cada módulo enumerado se iniciará automáticamente.
Conflicts: Un módulo que entra en conflicto con este módulo. Si alguno de los módulos enumerados ya se está ejecutando, el servicio no se puede iniciar y viceversa.

3.7.2 Instalar parámetros de la sección

El módulo de destino configurado en esta parte suele ser un archivo .target para un objetivo en ejecución específico, que se utiliza para hacer que el servicio se ejecute automáticamente cuando se inicia el sistema. Esta sección puede contener tres restricciones de lanzamiento:

WantedBy: Similar a Deseos en la sección Unidad, solo que los módulos que se enumeran a continuación no son los módulos de los que depende el servicio, sino los módulos que dependen del servicio actual. Su valor es uno o más Objetivos. Cuando la Unidad actual esté activada (habilitada), el enlace simbólico se colocará en un subdirectorio compuesto /etc/systemd/systempor un sufijo bajo el directorio <Target 名> + .wants, como por ejemplo/etc/systemd/system/multi-user.target.wants/
RequiredBy: Similar a Deseos en la sección Unidad, solo que los módulos que se enumeran a continuación no son los módulos de los que depende el servicio, sino los módulos que dependen del servicio actual. Su valor es uno o más Objetivos. Cuando se activa la Unidad actual, el enlace simbólico se colocará en un /etc/systemd/systemsubdirectorio <Target 名> + .requiredcompuesto por un sufijo debajo del directorio.
Also: Cuando la Unidad actual está habilitada/deshabilitada, otras Unidades se habilitan/deshabilitan al mismo tiempo.
Alias: Alias que la unidad actual puede usarse para iniciar

3.7.3 Parámetros del segmento de servicio

Se utiliza para la configuración del Servicio, solo las Unidades de tipo Servicio tienen este bloque. Sus principales campos se dividen en dos aspectos: ciclo de vida del servicio y configuración del contexto del servicio.

Relacionado con el control del ciclo de vida del servicio.

Type: Define el comportamiento del proceso al inicio, tiene los siguientes valores:
- Type=simple:Valor predeterminado, ejecute el comando especificado por ExecStart para iniciar el proceso principal
- Type=forking: Cree un proceso hijo a partir del proceso padre en modo bifurcación. El proceso padre saldrá inmediatamente después de la creación.
- Type=oneshot: Proceso único, Systemd esperará a que salga el servicio actual antes de continuar con la ejecución.
- Type=dbus: El servicio actual se inicia a través de D-Bus
- Type=notify: Después de iniciar el servicio actual, se notificará a Systemd antes de continuar.
- Type=idle: El servicio actual solo se ejecutará si se han completado otras tareas.
RemainAfterExit: El valor es verdadero o falso (predeterminado). Cuando se configura en verdadero, Systemd solo será responsable de iniciar el proceso de servicio. Incluso si el proceso de servicio sale, Systemd seguirá pensando que el servicio todavía se está ejecutando. Esta configuración se proporciona principalmente para algunos tipos especiales de servicios que no residen en la memoria, pero salen inmediatamente después de iniciar el registro y luego esperan a que se inicien los mensajes a pedido.
ExecStart: Comando para iniciar el servicio actual
ExecStartPre: El comando ejecutado antes de iniciar el servicio actual.
ExecStartPost: Comando ejecutado después de iniciar el servicio actual
ExecReload: Comando ejecutado al reiniciar el servicio actual
ExecStop: Comando ejecutado al detener el servicio actual
ExecStopPost: Detiene el comando ejecutado después de su servicio
RestartSec: El número de segundos entre el reinicio automático del servicio actual
Restart: Defina cuándo Systemd reiniciará automáticamente el servicio actual, los valores posibles incluyen siempre (siempre reiniciar), en caso de éxito, en caso de error, en caso de anomalía, en caso de aborto, en caso de vigilancia
TimeoutStartSec: El número de segundos que se debe esperar al iniciar el servicio. Esta configuración es particularmente importante para usar contenedores Docker, porque es posible que sea necesario descargar la imagen cuando se ejecuta por primera vez. Los retrasos severos pueden hacer que Systemd la juzgue erróneamente como una falla de inicio. y matarlo. Normalmente, para este tipo de servicio, especifique este valor como 0, desactivando así la detección de tiempo de espera.
TimeoutStopSec: La cantidad de segundos que se deben esperar al detener el servicio. Si aún no se detiene después de este tiempo, Systemd usará la señal SIGKILL para cerrar por la fuerza el proceso de servicio.
KillMode: Define cómo Systemd detiene el servicio sshd.
- control-group(Valor predeterminado): todos los procesos secundarios en el grupo de control actual serán eliminados.
- process: Mata solo el proceso principal
- mixed: El proceso principal recibirá la señal SIGTERM y el proceso secundario recibirá la señal SIGKILL.
- none: No se eliminará ningún proceso, solo se ejecutará el comando de parada del servicio.

Configuración del contexto del servicio relacionado

Environment:Especificar variables de entorno para el servicio.
EnvironmentFile: Especifica cargar un archivo que contiene una lista de variables de entorno requeridas por el servicio. Cada línea del archivo es la definición de una variable de entorno. El par clave-valor clave=valor dentro del archivo puede tener el formato $key, en la configuración actual Obtener del archivo
Nice: La prioridad del proceso del servicio. Cuanto menor sea el valor, mayor será la prioridad. El valor predeterminado es 0. Entre ellos, -20 es la prioridad más alta y 19 es la prioridad más baja.
WorkingDirectory:Especifique el directorio de trabajo del servicio.
RootDirectory: Especifique el directorio raíz del proceso de servicio (directorio/). Si este parámetro está configurado, el servicio no podrá acceder a ningún archivo fuera del directorio especificado.
User:Especifique el usuario que ejecuta el servicio.
Group:Especifique el grupo de usuarios para ejecutar el servicio.
MountFlags: La configuración del espacio de nombres de montaje del servicio afectará la información del punto de montaje en el contexto del proceso, es decir, si el servicio heredará el punto de montaje existente en el host y si el servicio se ejecuta y realiza la operación de montar o desmontar el dispositivo. , si realmente se instalará en el host efectos en el host. Los valores opcionales son compartidos, esclavos o privados.
- shared: El servicio y el host comparten un espacio de nombres de montaje, heredan el punto de montaje del host y el dispositivo montado o desinstalado por el servicio se reflejará verdaderamente en el host.
- slave: El servicio utiliza un espacio de nombres de montaje independiente, que heredará el punto de montaje del host, pero las operaciones del servicio en el punto de montaje solo tienen efecto dentro de su propio espacio de nombres y no se reflejarán en el host.
- private: El servicio utiliza un espacio de nombres de montaje independiente, no tiene ningún punto de montaje cuando se inicia y las operaciones del servicio en los puntos de montaje no se reflejarán en el host.
LimitCPU / LimitSTACK / LimitNOFILE / LimitNPROCEtc.: limite la cantidad de recursos del sistema para un servicio específico, como CPU, pila de programas, cantidad de identificadores de archivos, cantidad de procesos secundarios, etc.
Registre clases relacionadas, aquí se envía al diario; de lo contrario, el valor predeterminado es syslog

StandardError=journal

StandardOutput=journal

StandardInput=null

Nota: Si se utilizan comandos de Linux en ExecStart, ExecStop y otras propiedades, se debe escribir la ruta absoluta completa. Para los comandos auxiliares ExecStartPre y ExecStartPost, si hay un símbolo "-" delante, significa que se ignoran los errores en estos comandos. Porque es posible que algunos comandos "auxiliares" no necesariamente tengan éxito, como intentar borrar un archivo, pero es posible que el archivo no exista.

3.7.4 Marcador de posición del archivo unitario

En el archivo de la Unidad, a veces es necesario utilizar cierta información relacionada con el entorno de ejecución, como el ID del nodo, el usuario que ejecuta el servicio, etc. Esta información se puede representar mediante marcadores de posición, que luego se reemplazan dinámicamente con valores reales durante la ejecución real.

%n: nombre completo del archivo de la unidad, incluido el sufijo .service
%p: La parte antes del símbolo @ en el nombre del archivo de plantilla de Unidad, excluyendo el símbolo @
%i: la parte después del símbolo @ en el nombre del archivo de plantilla de unidad, excluyendo el símbolo @ y el nombre del sufijo .service
%t: El directorio donde se almacenan los archivos en ejecución del sistema, generalmente "ejecutar"
%u: El usuario que ejecuta el servicio. Si no se especifica en el archivo de la Unidad, el valor predeterminado es root.
%U:ID de usuario que ejecuta el servicio
%h: Directorio de inicio del usuario que ejecuta el servicio, es decir, el valor de la variable de entorno %{HOME}
%s: El tipo de Shell predeterminado del usuario que ejecuta el servicio, es decir, el valor de la variable de entorno %{SHELL}
%m: El ID de la máquina del nodo en ejecución real, que es más útil para ejecutar servicios en cada ubicación.
%b: ID de arranque, que es un número aleatorio diferente para cada nodo y que cambiará cada vez que se reinicie el nodo.
%H: El nombre de host del nodo en ejecución real.
%v: Versión del kernel, es decir, el contenido generado por el comando "uname -r"
%%: Representa un signo de porcentaje ordinario en el archivo de plantilla de Unidad

3.7.5 Plantilla de unidad

En Systemd, la plantilla de unidad es un archivo de unidad especial que se utiliza para definir varias unidades similares. El archivo de plantilla en sí no inicia ningún servicio, sino que se utiliza para generar el archivo de unidad real. Este mecanismo permite a los usuarios generar múltiples archivos de Unidad similares a través de plantillas, simplificando así el proceso de configuración.

El nombre de archivo de la plantilla de Unidad comienza con el símbolo @, por ejemplo, [email protected]. En el archivo de plantilla, puede utilizar el marcador de posición %i para representar el nombre de la instancia real. Cuando Systemd inicia una instancia de Unidad específica, %i será reemplazado con el nombre de la instancia.

El siguiente es un ejemplo sencillo de plantilla de unidad:

[Unit]
Description=My Service Template

[Service]
ExecStart=/usr/bin/myservice --name=%i

[Install]
WantedBy=multi-user.target

En este ejemplo, el archivo de plantilla define una plantilla denominada [email protected] que incluye una directiva ExecStart, donde %i se utiliza para representar el nombre de la instancia. Esta plantilla se puede utilizar para generar múltiples archivos de Unidad reales, por ejemplo [email protected] 和 [email protected].

El uso del mecanismo de plantilla de Systemd puede generar fácilmente múltiples archivos de Unidad similares, simplificando así el proceso de configuración y mejorando la eficiencia.

3.8 Ciclo de vida del servicio

Cuando se coloca un nuevo archivo de unidad en el directorio /etc/systemd/system/ o /usr/lib/systemd/system/, no será reconocido por sí mismo.
En Systemd, el ciclo de vida de un servicio incluye las siguientes etapas:

Fase de carga: Systemd carga el archivo Unidad del servicio e inicia o deshabilita el servicio según la configuración.
Fase de preparación: Systemd prepara el entorno de inicio para el servicio, incluida la configuración de variables de entorno, la creación de directorios necesarios, la verificación de dependencias, etc.
Fase de inicio: Systemd inicia el servicio, ejecuta el comando o programa de inicio del servicio y registra el PID del servicio.
Fase de ejecución: durante el funcionamiento normal del servicio, Systemd monitorea el estado del servicio, registra registros, maneja señales y otras operaciones.
Fase de parada: cuando es necesario detener el servicio, Systemd envía una señal de parada al proceso de servicio y espera a que salga.
Fase de procesamiento posterior a la parada: cuando el proceso de servicio sale, Systemd ejecuta el comando o programa de procesamiento posterior a la parada del servicio y registra el estado de salida del servicio.
Fase de desinstalación: cuando el servicio ya no es necesario, Systemd desinstala el archivo de unidad del servicio y limpia los archivos y registros de tiempo de ejecución relacionados.

Además de las etapas anteriores, Systemd también proporciona otras funciones, como reinicio automático, consulta del estado del servicio, gestión de dependencias, etc. A través de la administración de Systemd, puede administrar y monitorear más fácilmente el estado de ejecución de los servicios del sistema.

3.8.1 Activación de servicios

systemctl enable: Establece un enlace simbólico al servicio en /etc/systemd/system/, apuntando a /usr/lib/systemd/system/
systemctl start: Inicie los comandos ExecStartPre, **ExecStart ** y **ExecStartPost ** definidos en el archivo de la Unidad en secuencia

3.8.2 Iniciar y detener servicios

systemctl start: Inicie los comandos ExecStartPre, ExecStart y ExecStartPost definidos en el archivo de la Unidad en secuencia
systemctl stop: Detenga los comandos ExecStopPre, ExecStop y ExecStopPost definidos en el archivo de la Unidad en secuencia
systemctl restart:Reiniciar servicio
systemctl kill: Mata el servicio inmediatamente.

3.8.3 Inicio y cancelación del servicio

systemctl enable: Además de activar el servicio, también puede configurar el servicio para que se inicie al arrancar.
systemctl disable: Cancelar el inicio del servicio

3.8.4 Modificación y eliminación de servicios

systemctl daemon-reload: Systemd escribirá el contenido del archivo de Unidad en el caché, por lo que cuando se actualice el archivo de Unidad, se le debe indicar a Systemd que vuelva a leer todos los archivos de Unidad.
systemctl reset-failed: Elimina los archivos de la Unidad marcados como faltantes. Después de eliminar el archivo de Unidad, debido a la relación del caché, incluso si el caché se actualiza mediante daemon-reload, la Unidad marcada como no encontrada aún se mostrará en la lista de unidades.

3.9 Gestión de registros

En Systemd, todos los servicios del sistema generarán registros, incluido el inicio, la detención, los mensajes de error, etc. Systemd utiliza el sistema de registro Journal para administrar y almacenar estos registros. El sistema de registro de diario ofrece las siguientes ventajas:

Admite múltiples formatos de registro: el sistema de registro de diario admite múltiples formatos de registro, incluido el formato de texto, el formato binario, el formato JSON, etc.
Admite una compresión de registros eficiente: el sistema de registro de diario puede comprimir registros automáticamente y admitir consultas rápidas de registros comprimidos.
Admite un filtrado de registros eficiente: el sistema de registro de Journal admite un filtrado de registros eficiente y los registros se pueden consultar según el nombre del servicio, el tipo de evento, el rango de tiempo y otras condiciones.
Admite una rotación de registros eficiente: el sistema de registro de diario admite una rotación de registros eficiente, que puede eliminar automáticamente los registros caducados y limitar el tamaño de los archivos de registro dentro de un rango determinado.

En Systemd, se pueden utilizar los siguientes comandos para consultar y administrar registros:

journalctl: Este comando puede consultar el registro del sistema, incluido el inicio y la detención del servicio, información de errores, etc. Los registros se pueden consultar según condiciones como el nombre del servicio, el tipo de evento y el rango de tiempo.
journalctl --follow: Este comando puede rastrear los cambios del registro en tiempo real, similar al comando tail -f.
journalctl --vacuum-size=100M: Este comando puede limitar el tamaño del archivo de registro. Cuando el tamaño del archivo excede el valor especificado, los registros caducados se eliminarán automáticamente.
journalctl --vacuum-time=1week: Este comando puede limitar el tiempo de almacenamiento de los archivos de registro. Cuando el tiempo de almacenamiento de los archivos de registro excede el tiempo especificado, los registros caducados se eliminarán automáticamente.

En resumen, a través del sistema de registro Journal de Systemd, puede administrar y consultar fácilmente los registros del sistema y acelerar la resolución de problemas.

Otros comandos comunes:

# 查看所有日志（默认情况下 ，只保存本次启动的日志）
sudo journalctl

# 查看内核日志（不显示应用日志）：--dmesg 或 -k
sudo journalctl -k

# 查看系统本次启动的日志（其中包括了内核日志和各类系统服务的控制台输出）：--system 或 -b
sudo journalctl -b
sudo journalctl -b -0

# 查看上一次启动的日志（需更改设置）
sudo journalctl -b -1

# 查看指定服务的日志：--unit 或 -u
sudo journalctl -u docker.servcie

# 查看指定服务的日志
sudo journalctl /usr/lib/systemd/systemd

# 实时滚动显示最新日志
sudo journalctl -f

# 查看指定时间的日志
sudo journalctl --since="2021-10-30 18:17:16"
sudo journalctl --since "20 min ago"
sudo journalctl --since yesterday
sudo journalctl --since "2022-01-10" --until "2022-01-11 03:00"
sudo journalctl --since 09:00 --until "1 hour ago"

# 显示尾部的最新 10 行日志：--lines 或 -n
sudo journalctl -n

# 显示尾部指定行数的日志
sudo journalctl -n 20

# 将最新的日志显示在前面
sudo journalctl -r -u docker.service

# 改变输出的格式：--output 或 -o
sudo journalctl -r -u docker.service -o json-pretty

# 查看指定进程的日志
sudo journalctl _PID=1

# 查看某个路径的脚本的日志
sudo journalctl /usr/bin/bash

# 查看指定用户的日志
sudo journalctl _UID=33 --since today

# 查看某个 Unit 的日志
sudo journalctl -u nginx.service
sudo journalctl -u nginx.service --since today

# 实时滚动显示某个 Unit 的最新日志
sudo journalctl -u nginx.service -f

# 合并显示多个 Unit 的日志
journalctl -u nginx.service -u php-fpm.service --since today

# 查看指定优先级（及其以上级别）的日志，共有 8 级
# 0: emerg
# 1: alert
# 2: crit
# 3: err
# 4: warning
# 5: notice
# 6: info
# 7: debug
sudo journalctl -p err -b

# 日志默认分页输出，--no-pager 改为正常的标准输出
sudo journalctl --no-pager

# 以 JSON 格式（单行）输出
sudo journalctl -b -u nginx.service -o json

# 以 JSON 格式（多行）输出，可读性更好
sudo journalctl -b -u nginx.service -o json-pretty

# 显示日志占据的硬盘空间
sudo journalctl --disk-usage

# 指定日志文件占据的最大空间
sudo journalctl --vacuum-size=1G

# 指定日志文件保存多久
sudo journalctl --vacuum-time=1years

4. Tareas programadas de systemd.timer

En Systemd, además del servicio (Unidad), el temporizador también se puede utilizar para administrar y controlar tareas de sincronización. En comparación con el crontab tradicional, el uso del temporizador de Systemd puede proporcionar mayor flexibilidad y confiabilidad.

El temporizador es esencialmente una unidad que puede definir el tiempo de ejecución y los comandos de ejecución de las tareas programadas. El temporizador se puede configurar para que comience una vez, todos los días, todas las semanas, todos los meses, etc. en diferentes intervalos.

4.1 Ventajas de systemd.timer

Genere registros automáticamente y coopere con la herramienta de registro de Systemd, que es muy conveniente para la depuración.
Puede configurar la cuota de uso de memoria y CPU, como usar hasta el 50% de la CPU
Las tareas se pueden dividir y depender de otras unidades Systemd para completar tareas muy complejas.

4.2 Explicación detallada de ejemplos.

Cree el archivo test.timer (generalmente recomendado con el mismo nombre) en /usr/lib/systemd/system

[Unit]
Description=My test Timer

[Timer]
OnBootSec=2m
OnUnitActiveSec=10s
OnCalendar=*-*-* 00:00:00
Unit=myjob.service

[Install]
WantedBy=timers.target

定时器单元文件中必须包含一个 [Timer]

通过同时使用 OnBootSec= 与 OnUnitActiveSec= 指令， 就可以实现在系统启动后的某个时间点启动匹配单元， 并且之后每隔一段时间周期性的反复启动匹配单元

时间单位后缀：us(微秒), ms(毫秒), s(秒), m(分), h(时), d(天), w(周)。 如果省略了时间单位，那么表示使用默认单位"秒"

Unit= 该定时器单元的匹配单元， 也就是要被该定时器启动的单元。默认值是与此定时器单元同名的服务单元

Cuando se inicia el temporizador, Systemd calculará el siguiente tiempo de ejecución según el parámetro OnCalendar e iniciará el servicio o comando correspondiente cuando llegue el momento. El registro de ejecución del temporizador se registrará en el registro de diario de Systemd, que se puede ver usando el comando journalctl.

Antes de iniciar el temporizador, debe utilizar el comando systemctl enable para agregar el temporizador a la lista de inicio automático.

systemctl enable mytimer.timer

Comandos de uso común:

# 启动刚刚新建的这个定时器
sudo systemctl start test.timer

# 查看这个定时器的状态
systemctl status test.timer

# 查看所有正在运行的定时器
systemctl list-timers

# 关闭这个定时器
sudo systemctl stop myscript.timer

# 下次开机，自动运行这个定时器
sudo systemctl enable myscript.timer

# 关闭定时器的开机自启动
sudo systemctl disable myscript.timer

# 查看整个日志
sudo journalctl

# 查看 test.timer 的日志
sudo journalctl -u test.timer

# 查看 test.timer 和 test.service 的日志
sudo journalctl -u test

# 从结尾开始查看最新日志
sudo journalctl -f

# 从结尾开始查看 test.timer 的日志
journalctl -f -u test.timer

4.3 Explicación detallada de los parámetros del temporizador

4.3.1, El archivo de la unidad del temporizador se divide en varias partes

[Unit]Metadatos parcialmente definidos.

[Timer]Temporizador parcialmente personalizable. Systemd proporciona algunos de los siguientes campos

OnActiveSec: Una vez que el temporizador entra en vigor, ¿cuánto tiempo lleva comenzar a ejecutar la tarea?
OnBootSec: Después de que se inicia el sistema, ¿cuánto tiempo lleva comenzar a ejecutar la tarea?
OnStartupSec: Una vez iniciado el proceso Systemd, ¿cuánto tiempo lleva comenzar a ejecutar la tarea?
OnUnitActiveSec: Cuánto tiempo se debe esperar para que la unidad se ejecute nuevamente después de la última vez que se ejecutó.
OnUnitInactiveSec: Cuánto tiempo ha transcurrido desde la última vez que se cerró el temporizador antes de que se ejecute nuevamente
OnCalendar: Ejecución basada en tiempo absoluto, no en tiempo relativo
AccuracySec: Si la tarea debe posponerse por diversos motivos, la cantidad máxima de segundos para posponer es de 60 segundos de forma predeterminada.
Unit: La tarea real que se ejecutará, el valor predeterminado es la unidad con el mismo nombre y el sufijo .service.
Persistent: Si se configura este campo, incluso si el temporizador no se inicia cuando expira, la unidad correspondiente se ejecutará automáticamente.
WakeSystem: Si el sistema duerme, si se activa automáticamente el sistema

En el script de ejemplo, OnUnitActiveSec=1hsignifica que la tarea se ejecutará una vez por hora. Otras formas de escribir incluyen OnUnitActiveSec=*-*-* 02:00:00ejecutarlo a las 2 a.m. todos los días y OnUnitActiveSec=Mon *-*-* 02:00:00ejecutarlo a las 2 a.m. todos los lunes. Consulte la documentación oficial para obtener más detalles.

4.3.2, [Instalar] y destino

test.timerEn el archivo, también hay una sección [Instalar], que define los comandos que se ejecutarán cuando la unidad se inicia automáticamente (systemctl enable) y cuando la unidad se apaga (systemctl enable). En el script anterior, solo se escribe un campo en la parte [Instalar], es decir WantedBy=multi-user.target. Lo que significa es que si se ejecuta systemctl enable test.timer(el temporizador entrará en vigor automáticamente siempre que la computadora esté encendida), entonces el temporizador pertenece a multi-user.target.
El llamado Objetivo se refiere a un grupo de procesos relacionados, un poco como el nivel de inicio en el modo de proceso de inicio. Cuando se inicia un Target, se iniciarán todos los procesos que pertenecen a este Target. multi-user.target es el Target más utilizado, lo que significa modo multiusuario. Es decir, cuando el sistema se inicia en modo multiusuario, test.timer se iniciará juntos. La operación detrás de esto es realmente muy simple: systemctl enable test.timercuando se ejecuta el comando, multi-user.target.wantsse creará un enlace simbólico en el directorio que apunta a test.timer

Documentación de referencia:

1. https://blog.51cto.com/weiyigeek/5666902

2. https://blog.csdn.net/lemon_TT/article/details/127090001

3. https://blog.csdn.net/qq_35995514/article/details/125582824

4、https://www.cnblogs.com/aaronLinux/p/6861425.html