5 razones por las que los administradores de sistemas aman systemd

Como saben los administradores de sistemas, suceden muchas cosas en las computadoras modernas. Las aplicaciones se ejecutan en segundo plano, los eventos automatizados esperan que se activen en un momento determinado, se escriben archivos de registro y se entregan informes de estado. Tradicionalmente, estos procesos dispares han sido administrados y monitoreados con una colección de herramientas de Unix con gran efecto y eficiencia. Sin embargo, las computadoras modernas son diversas, con servicios locales que se ejecutan junto con aplicaciones en contenedores, fácil acceso a las nubes y los clústeres en los que se ejecutan, procesos en tiempo real y más datos para procesar que nunca.

Tener un método unificado para administrarlos es una expectativa para los usuarios y un lujo útil para los administradores de sistemas ocupados. Para esta tarea no trivial, el daemon del sistema, o systemd , fue desarrollado y adoptado rápidamente por las principales distribuciones de Linux.

Más sobre administradores de sistemas

• Habilitar el blog de administrador del sistema
• La empresa automatizada:una guía para administrar TI con automatización
• Libro electrónico:Automatización de Ansible para administradores de sistemas
• Historias del campo:una guía del administrador de sistemas para la automatización de TI
• eBook:Una guía de Kubernetes para SRE y administradores de sistemas
• Últimos artículos de administrador de sistemas

Por supuesto, systemd no es la única forma de administrar un sistema Linux. Hay muchos sistemas de inicio alternativos, incluidos sysvinit, OpenRC, runit, s6 e incluso BusyBox, pero systemd trata a Linux como un conjunto de datos unificado, destinado a ser manipulado y consultado de manera consistente con herramientas sólidas. Para un administrador de sistemas ocupado y muchos usuarios, la velocidad y facilidad de systemd es una característica importante. Aquí hay cinco razones por las cuales.

Gestión de arranque

Arrancar una computadora Linux puede ser un evento sorprendentemente raro, si así lo desea. Ciertamente, en el mundo de los servidores, los tiempos de actividad a menudo se cuentan en años. en lugar de meses o semanas. Las computadoras portátiles y de escritorio tienden a apagarse y reiniciarse con bastante frecuencia, aunque incluso estas tienen la misma probabilidad de suspenderse o hibernar que de apagarse. De cualquier manera, el tiempo transcurrido desde el evento de arranque más reciente puede servir como una especie de administrador de sesión para una verificación del estado de la computadora. Es una forma útil de limitar los datos que mira cuando supervisa su sistema o diagnostica problemas.

En el caso probable de que no pueda recordar la última vez que inició su computadora, puede enumerar las sesiones de inicio con la herramienta de registro de systemd, journalctl :

$ journalctl --list-boots

-42 7fe7c3... Fri 2020-12-04 05:13:59 - Wed 2020-12-16 16:01:23 

-41 332e99... Wed 2020-12-16 20:07:39 - Fri 2020-12-18 22:08:13 

[...]

-1 e0fe5f... Mon 2021-03-29 20:47:46 - Mon 2021-03-29 21:59:29

 0 37fbe4... Tue 2021-03-30 04:46:13 - Tue 2021-03-30 10:42:08

Las últimas sesiones de arranque aparecen en la parte inferior de la lista, por lo que puede canalizar la salida a tail solo por las últimas botas.

Los números de la izquierda (42, 41, 1 y 0 en este ejemplo) son números de índice para cada sesión de arranque. En otras palabras, para ver los registros solo de una sesión de arranque específica, puede usar su número de índice como referencia.

Registrar revisiones

Mirar los registros es un método importante para extrapolar información sobre su sistema. Los registros proporcionan un historial de gran parte de la actividad que realiza su computadora sin su supervisión directa. Puede ver cuándo se iniciaron los servicios, cuándo se ejecutaron los trabajos programados, qué servicios se están ejecutando en segundo plano, qué actividades fallaron y más. Uno de los pasos iniciales más comunes para solucionar problemas es revisar los registros, lo cual es fácil de hacer con journalctl :

$ journalctl --pager-end

El --pager-end (o -e para abreviar) la opción inicia su vista de los registros al final del journalctl salida, por lo que debe desplazarse hacia arriba para ver los eventos que ocurrieron antes.

Systemd mantiene un "catálogo" de errores y mensajes con registros de errores, posibles soluciones, punteros a foros de soporte y documentación para desarrolladores. Esto puede proporcionar un contexto importante para un evento de registro, que de lo contrario puede ser un punto confuso en un mar de mensajes o, lo que es peor, podría pasar totalmente desapercibido. Para integrar mensajes de error con texto explicativo, puede usar el --catalog (o -x para abreviar) opción:

$ journalctl --pager-end --catalog

Para limitar aún más la salida del registro que necesita recorrer, puede especificar para qué sesión de arranque desea ver los registros. Debido a que cada sesión de arranque está indexada, puede especificar ciertas sesiones con --boot opción y ver solo los registros que se aplican a ella:

$ journalctl --pager-end --catalog --boot 42

También puede ver los registros de una unidad systemd específica. Por ejemplo, para solucionar un problema con su servicio de shell seguro (SSH), puede especificar --unit sshd para ver solo los registros que se aplican al sshd demonio:

$ journalctl --pager-end \

--catalog --boot 42 \

--unit sshd

Gestión de servicios

La primera tarea de systemd es iniciar su computadora, y generalmente lo hace de manera rápida, eficiente y efectiva. Pero la tarea que nunca termina es la gestión del servicio. Por diseño, systemd garantiza que los servicios que desea ejecutar se inicien y continúen ejecutándose durante su sesión. Esto es bastante sólido, porque en teoría, incluso un servicio bloqueado puede reiniciarse sin su intervención.

Su interfaz para ayudar a systemd a administrar los servicios es systemctl dominio. Con él, puede ver los archivos de unidad que definen un servicio:

$ systemctl cat sshd

# /usr/lib/systemd/system/sshd.service

[Unit]

Description=OpenSSH server daemon

Documentation=man:sshd(8) man:sshd_config(5)

After=network.target sshd-keygen.target

Wants=sshd-keygen.target



[Service]

Type=notify

EnvironmentFile=-/etc/crypto-policies/back-ends/opensshserver.config

EnvironmentFile=-/etc/sysconfig/sshd

ExecStart=/usr/sbin/sshd -D $OPTIONS $CRYPTO_POLICY

ExecReload=/bin/kill -HUP $MAINPID

KillMode=process

Restart=on-failure

RestartSec=42s



[Install]

WantedBy=multi-user.target

La mayoría de los archivos de unidad existen en /usr/lib/systemd/system/ pero, como sucede con muchas configuraciones importantes, se recomienda modificarlas con cambios locales. También hay una interfaz para eso:

$ systemctl edit sshd

Puede ver si un servicio está actualmente activo:

$ systemctl is-active sshd

active

$ systemctl is-active foo

inactive

Del mismo modo, puede ver si un servicio ha fallado con is-failed .

Iniciar y detener servicios es muy intuitivo:

$ systemctl stop sshd

$ systemctl start sshd

Y permitir que un servicio se inicie en el momento del arranque es simple:

$ systemctl enable sshd

Agrega el --now opción para permitir que un servicio se inicie en el momento del arranque o para iniciarlo en su sesión actual.

Temporizadores

Hace mucho tiempo, cuando querías automatizar una tarea en Linux, la herramienta canónica para el trabajo era cron . Todavía hay un lugar para el comando cron, pero también hay algunas alternativas convincentes. Por ejemplo, el anacron command es un sistema versátil similar a un cron capaz de ejecutar tareas que de otro modo se habrían perdido durante el tiempo de inactividad.

Los eventos programados son poco más que servicios activados en un momento específico, por lo que systemd administra una función similar a cron llamada temporizadores. Puede enumerar los temporizadores activos:

$ systemctl list-timers

NEXT                          LEFT       

Tue 2021-03-30 12:37:54 NZDT  16min left [...]

Wed 2021-03-31 00:00:00 NZDT  11h left [...]

Wed 2021-03-31 06:42:02 NZDT  18h left [...]



3 timers listed.

Pass --all to see loaded but inactive timers, too.

Puede habilitar un temporizador de la misma manera que habilita un servicio:

$ systemctl enable myMonitor.timer

Objetivos

Los objetivos son el componente principal final de la matriz systemd. Un objetivo se define mediante un archivo de unidad, al igual que los servicios y los temporizadores. Los objetivos también se pueden iniciar y habilitar de la misma manera. Lo que hace que los objetivos sean únicos es que agrupan otros archivos de unidades de forma arbitrariamente significativa. Por ejemplo, es posible que desee iniciar desde una consola de texto en lugar de un escritorio gráfico, por lo que el multi-user el objetivo existe. Sin embargo, el multi-user el objetivo es solo el graphical destino sin los archivos de la unidad de escritorio como dependencias.

En resumen, los objetivos son una manera fácil de recopilar servicios, temporizadores e incluso otros objetivos para representar un estado previsto para su máquina.

De hecho, dentro de systemd, una acción de reinicio, apagado o apagado es solo otro objetivo.

Puede enumerar todos los objetivos disponibles utilizando list-unit-files opción, restringiéndola con el --type opción establecida en target :

$ systemctl list-unit-files --type target

Tomar el control con systemd

Linux moderno usa systemd para la gestión de servicios y la introspección de registros. Proporciona todo, desde sistemas Linux personales hasta servidores empresariales, con un mecanismo moderno para monitorear y mantener fácilmente. Cuanto más lo use, más systemd se volverá cómodamente predecible e intuitivo, y más descubrirá cómo se interconectan las partes dispares de su sistema.

Para familiarizarse mejor con systemd, debe usarlo. Y para sentirse cómodo con su uso, descargue nuestra hoja de trucos y consúltela con frecuencia.