SystemD es una herramienta de administración del sistema que se utiliza para agilizar las tareas de administración del sistema y mejorar la eficiencia. Su beneficio principal radica en su capacidad para mejorar el rendimiento y la capacidad de respuesta del sistema, así como también mejorar la seguridad al buscar vulnerabilidades automáticamente y parchearlas.
Además, SystemD puede ayudar a organizar los recursos del sistema de manera más efectiva, lo que permite que los programas se ejecuten más rápido y sin problemas. En general, si está buscando una herramienta de administración de sistemas efectiva que lo ayude a aprovechar al máximo su sistema, entonces SystemD es la solución ideal. En este artículo, aprenderá todo lo que necesita saber sobre SystemD.
¿Para que se usa SystemD?
SystemD es una herramienta de gestión de sistemas que se puede utilizar para una variedad de tareas, desde la gestión de recursos y procesos del sistema hasta la optimización del rendimiento del sistema en sistemas Linux. Es ampliamente utilizado en muchas industrias diferentes, desde la atención médica hasta la fabricación, debido a sus potentes capacidades y características avanzadas.
Ya sea que esté ejecutando servidores grandes o estaciones de trabajo más pequeñas, SystemD ofrece una variedad de beneficios que pueden ayudarlo a mejorar la eficiencia y la productividad del sistema. Algunas de las características clave incluyen la priorización de procesos, el registro de eventos del sistema y los controles de asignación de recursos del sistema. Entonces, si su organización está buscando una herramienta de administración de sistemas confiable que pueda ayudar a aumentar la eficiencia y el rendimiento en todos los sistemas, definitivamente vale la pena considerar SystemD.
¿Por qué a la gente no le gusta SystemD?
Si bien muchos usuarios encuentran que SystemD es una herramienta de administración de sistemas invaluable, hay algunos a quienes no les gusta por una variedad de razones. Algunos críticos argumentan que es demasiado complejo y difícil de usar, especialmente para quienes no están familiarizados con las tareas de administración del sistema. Otros afirman que puede tener un impacto negativo en el rendimiento del sistema, lo que genera tiempos de inicio más lentos y un mayor uso de recursos.
Sin embargo, a pesar de estas preocupaciones, SystemD sigue siendo una de las herramientas de gestión de sistemas más utilizadas en el mercado hoy en día y probablemente seguirá siéndolo en el futuro. Si está buscando una herramienta de administración de sistemas eficiente que pueda ayudar a mejorar la productividad en todos los sistemas de su organización, definitivamente vale la pena considerar SystemD.
¿Por qué es polémico SystemD?
SystemD es una herramienta de gestión de sistemas muy controvertida, en gran parte debido al debate en curso sobre su eficacia y facilidad de uso. Algunos usuarios afirman que puede tener un impacto negativo en el rendimiento del sistema, mientras que otros argumentan que ofrece una serie de beneficios importantes, como una mayor seguridad del sistema y una asignación de recursos del sistema más eficiente.
También existen preocupaciones sobre la complejidad y la facilidad de uso de SystemD, y muchos usuarios citan su curva de aprendizaje empinada y su interfaz confusa como los principales puntos de crítica. Sin embargo, a pesar de estas preocupaciones, SystemD sigue siendo una de las herramientas de administración de sistemas más utilizadas en el mercado actual y es probable que continúe siéndolo en el futuro. Si está buscando una poderosa herramienta de administración de sistemas que pueda ayudar a mejorar el rendimiento y la eficiencia del sistema en todos los sistemas, entonces SystemD puede ser la solución ideal para usted.
¿Qué es SystemD frente a init?
SystemD e init son herramientas de administración de sistemas que a menudo se comparan debido a sus funciones similares y características superpuestas. Si bien ambas herramientas de administración del sistema se pueden usar para una variedad de tareas de administración del sistema, como la priorización de procesos, el registro de eventos del sistema y los controles de asignación de recursos del sistema, existen algunas diferencias clave entre ellas.
Si bien init se centra en los procesos de inicio y apagado del sistema, por ejemplo, SystemD ofrece una gama más amplia de capacidades de administración del sistema. Además, muchos usuarios consideran que SystemD es más fácil de usar e intuitivo que init, lo que lo convierte en una opción popular entre los administradores de sistemas y los profesionales de TI. En general, si está buscando una solución de administración de sistemas efectiva que pueda ayudar a mejorar el rendimiento y la eficiencia del sistema en todos los sistemas, entonces SystemD puede ser la opción ideal para usted.
¿Debería usar Grub o SystemD?
No hay una respuesta definitiva a esta pregunta, ya que tanto Grub como SystemD tienen sus propias ventajas e inconvenientes. Por un lado, Grub es una herramienta de administración de sistemas liviana que ofrece funciones simples y optimizadas para iniciar y apagar el sistema.
Por otro lado, SystemD ofrece una gama más amplia de funciones y capacidades de gestión de sistemas, lo que la convierte en una herramienta de gestión de sistemas más potente y versátil. En última instancia, si elige usar Grub o SystemD dependerá de sus necesidades y preferencias específicas como administrador del sistema o profesional de TI. Sin embargo, si está buscando una solución de administración de sistemas eficiente que pueda ayudar a mejorar el rendimiento y la eficiencia del sistema en todos los sistemas, es probable que SystemD sea la mejor opción.
Cómo usar SystemD
A continuación, cubriremos un par de formas en las que puede usar SystemD en sistemas Linux. Estos son solo algunos ejemplos que puede probar usted mismo. Lleva algún tiempo acostumbrarse a la sintaxis, pero una vez que la domina, SystemD se convierte en una herramienta poderosa.
SystemD - Inicializar
Este es el primer proceso iniciado por el kernel y obtiene el id de proceso 1 . Gestiona el proceso de arranque, tareas como la creación de sockets, la configuración del hardware, el montaje de discos, etc.
SystemD trabaja con unidades de diferentes tipos. Junto al propio servicio, también existe:
- temporizador
- montar
- red
- enchufes
- particiones
- dispositivos
Además, puede gestionar otros procesos con SystemD:
- empezar
- detener
- reiniciar
- matar
Unit-Files
Existen diferentes rutas para los archivos de unidades existentes:
| Ruta | Información |
|---|---|
| /usr/lib/systemd/sistema | archivos SystemD predefinidos (no modificar) |
| /etc/systemd/sistema | Ubicación para archivos de unidades personalizadas |
| /ejecutar/systemd/sistema | Para los archivos relevantes en tiempo de ejecución |
Información importante sobre los caminos: SystemD siempre preferirá /etc/ a /usr/lib/ . Es por eso que colocamos archivos de unidades personalizadas allí.
Puede visitar el archivo de la unidad de un servicio específico visitando la ruta o con el comando:
systemctl cat <service>
Code language: Bash (bash)Por ejemplo, OpenVPN:
[email protected]:~$ systemctl cat openvpn
# /lib/systemd/system/openvpn.service
# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.
[Unit]
Description=OpenVPN service
After=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
WorkingDirectory=/etc/openvpn
[Install]
WantedBy=multi-user.target
Code language: Bash (bash)Como podemos ver en el archivo de la unidad, define qué ruta se usa , el archivo PID y más opciones . De la que hablaremos con más detalle a continuación. Podemos ver todas las propiedades disponibles con las opciones que se pueden definir en el archivo de la unidad para el servicio usando el comando:
systemctl show <service>
Code language: Bash (bash)Por ejemplo, aquí nuevamente, están las primeras líneas de la salida de OpenVPN:
[email protected]:~$ systemctl show openvpn
Type=oneshot
Restart=no
NotifyAccess=none
RestartUSec=100ms
TimeoutStartUSec=infinity
TimeoutStopUSec=1min 30s
TimeoutAbortUSec=1min 30s
TimeoutStartFailureMode=terminate
TimeoutStopFailureMode=terminate
RuntimeMaxUSec=infinity
WatchdogUSec=0
WatchdogTimestamp=n/a
WatchdogTimestampMonotonic=0
RootDirectoryStartOnly=no
RemainAfterExit=yes
GuessMainPID=yes
MainPID=0
ControlPID=0
FileDescriptorStoreMax=0
NFileDescriptorStore=0
StatusErrno=0
Result=success
ReloadResult=success
CleanResult=success
UID=[not set]
GID=[not set]
NRestarts=0
OOMPolicy=stop
ExecMainStartTimestamp=Sat 2022-09-17 13:00:55 CEST
ExecMainStartTimestampMonotonic=9823235
ExecMainExitTimestamp=Sat 2022-09-17 13:00:55 CEST
ExecMainExitTimestampMonotonic=9824084
ExecMainPID=1164
ExecMainCode=1
ExecMainStatus=0v
Code language: Bash (bash)Si ahora queremos editar el archivo de unidad del servicio, ejecutamos el comando:
systemctl edit – full <service>
Code language: Bash (bash)
Cuando ejecutamos el comando sin el full opción, obtendremos un archivo en blanco. Tenemos la opción de crear una copia del archivo fuente, que podemos editar.
Como ejemplo de una posible opción, imaginemos que queremos que OpenVPN siempre se esté ejecutando. Incluso cuando el proceso se detiene o se cancela, queremos que se reinicie solo.
Abrimos el editor y añadimos la opción específica:
# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.
[Unit]
Description=OpenVPN service
After=network.target
[Service]
Restart=yes
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
WorkingDirectory=/etc/openvpn
[Install]
WantedBy=multi-user.target
Code language: Bash (bash)Después de esto, necesitamos recargar el archivo de configuración:
systemctl reload <service>
Code language: Bash (bash)Y finalmente, reinicie el servicio:
systemctl restart <service>
Code language: Bash (bash)Con este comando, SystemD intentará recargar el servicio. Si esto no funciona, reiniciará el servicio:
systemctl reload-or-restart <service>
Code language: HTML, XML (xml)En los comandos anteriores, aprendimos cómo controlar los servicios manualmente. SystemD también le permite habilitar o deshabilitar permanentemente los servicios para que se inicien automáticamente cuando sea necesario o no estén disponibles en absoluto. La siguiente tabla mostrará los comandos disponibles:
| Comando | Función |
|---|---|
| activar | Activa un servicio |
| deshabilitar | Desactiva un servicio |
| está habilitado | Comprobar si un servicio está habilitado |
| rehabilitar | deshabilita un servicio y luego lo vuelve a habilitar |
| máscara | Si desea deshabilitar completamente un servicio, enmascárelo - Tenga cuidado |
| desenmascarar | desenmascara un servicio |
Ejemplo de uso:
systemctl enable <service>
Code language: Bash (bash)Objetivos
Estos son diferentes estados en los que el sistema puede arrancar.
SystemD agrega un nuevo concepto para los conocidos niveles de ejecución. Sin embargo, se mantiene el principio anterior. Solo los niveles de ejecución reciben nombres en lugar de números:
| Objetivo | Efecto |
|---|---|
| detener.objetivo | Apagar el sistema |
| apagar.objetivo | Apaga físicamente el sistema (apagado) |
| rescate.objetivo | Modo de usuario único |
| multiusuario.objetivo | Modo multiusuario |
| objetivo.gráfico | Modo multiusuario con interfaz gráfica |
| reiniciar.objetivo | Reinicia el sistema |
Puede cambiar a otro objetivo usando el siguiente comando:
systemctl isolate example.target
Code language: Bash (bash)Reinicie el sistema:
systemctl reboot
Code language: Bash (bash)Pone el sistema en suspensión profunda y pausa todos los procesos en ejecución:
systemctl hybrid-sleep
Code language: Bash (bash)Apaga el sistema con un mensaje de difusión a todos los usuarios registrados:
systemctl shutdown
Puede modificar esto usando los parámetros:
systemctl shutdown -r now
Code language: Bash (bash)Esto reiniciaría el sistema (-r) y omitiría el mensaje de difusión y se reiniciaría directamente. Hay muchos parámetros diferentes para usar este comando. Puede buscarlos en la página de manual.
Puede mostrar el destino actual en el que se está iniciando el sistema con el siguiente comando:
systemctl get-default
Code language: Bash (bash)Adicional, puede modificar el objetivo:
systemctl set-default example.target
Code language: Bash (bash)Los diferentes niveles de ejecución también se pueden ver aquí:
ls -la /usr/lib/systemd/system |grep runle*
Code language: Bash (bash)[email protected]:~$ ls -la /usr/lib/systemd/system |grep runle*
lrwxrwxrwx 1 root root 15 Apr 18 22:12 runlevel0.target -> poweroff.target
lrwxrwxrwx 1 root root 13 Apr 18 22:12 runlevel1.target -> rescue.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel1.target.wants
lrwxrwxrwx 1 root root 17 Apr 18 22:12 runlevel2.target -> multi-user.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel2.target.wants
lrwxrwxrwx 1 root root 17 Apr 18 22:12 runlevel3.target -> multi-user.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel3.target.wants
lrwxrwxrwx 1 root root 17 Apr 18 22:12 runlevel4.target -> multi-user.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel4.target.wants
lrwxrwxrwx 1 root root 16 Apr 18 22:12 runlevel5.target -> graphical.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel5.target.wants
lrwxrwxrwx 1 root root 13 Apr 18 22:12 runlevel6.target -> reboot.target
-rw-r--r – 1 root root 803 Apr 18 22:12 systemd-update-utmp-runlevel.service
Code language: plaintext (plaintext)Grupos de control
SystemD organiza las tareas en grupos de control. Esto se usa para el control de recursos en Linux, y esto permite que los recursos disponibles sean limitados , priorizado , contado, y aislado .
Los siguientes comandos son, por lo tanto, muy útiles para analizar y optimizar el rendimiento del sistema:
systemd-analyze
Code language: Bash (bash)Este comando se puede utilizar para determinar el rendimiento de arranque.
[email protected]:~$ systemd-analyze
Startup finished in 12.712s (firmware) + 328ms (loader) + 8.240s (kernel) + 6.634s (userspace) = 27.916s
graphical.target reached after 6.631s in userspace
Code language: plaintext (plaintext)Como podemos ver, obtenemos un desglose de los tiempos de cuánto tarda cada tarea en comenzar.
Con el comando adicional blame Obtenemos una lista muy detallada de cuánto tiempo necesita iniciarse cada proceso individual:
systemd-analyze blame
Salida :
[email protected]:~$ systemd-analyze blame
5.573s NetworkManager-wait-online.service
3.244s plymouth-quit-wait.service
2.285s fwupd.service
467ms logrotate.service
392ms lm-sensors.service
385ms accounts-daemon.service
362ms snapd.service
290ms systemd-resolved.service
279ms networkd-dispatcher.service
247ms networking.service
213ms dev-nvme0n1p3.device
182ms apparmor.service
178ms ModemManager.service
174ms systemd-journal-flush.service
168ms udisks2.service
161ms NetworkManager.service
152ms com.system76.Scheduler.service
128ms apport.service
127ms e2scrub_reap.service
116ms rsyslog.service
115ms smartmontools.service
114ms wpa_supplicant.service
105ms [email protected]
100ms gpu-manager.service
....
Code language: plaintext (plaintext)Si queremos ver todos los grupos de control, podemos usar:
systemd-cgls
Code language: Bash (bash)o
systemctl status
Code language: Bash (bash)Obtendremos una salida basada en un árbol con toda la información necesaria:
[email protected]:~$ systemd-cgls
Control group /:
-.slice
├─user.slice
│ └─user-1000.slice
│ ├─[email protected]
│ │ ├─session.slice
│ │ │ ├─dbus-broker.service
│ │ │ │ ├─3119 /usr/bin/dbus-broker-launch – scope user
│ │ │ │ └─3120 dbus-broker – log 4 – controller 10 – machine-id 04d8535513777afc7bb291c362dd90a7 – max-bytes 100000000000000 – max-fds 25000000000000 – max-matches 50000000>
│ │ │ ├─xdg-document-portal.service
│ │ │ │ ├─3761 /usr/libexec/xdg-document-portal
│ │ │ │ └─3773 fusermount3 -o rw,nosuid,nodev,fsname=portal,auto_unmount,subtype=portal – /run/user/1000/doc
│ │ │ ├─xdg-desktop-portal.service
│ │ │ │ └─3753 /usr/libexec/xdg-desktop-portal
│ │ │ ├─pipewire-pulse.service
│ │ │ │ └─3112 /usr/bin/pipewire-pulse
│ │ │ ├─wireplumber.service
│ │ │ │ └─3111 /usr/bin/wireplumber
│ │ │ ├─plasma-xdg-desktop-portal-kde.service
│ │ │ │ └─3861 /usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde
│ │ │ └─pipewire.service
│ │ │ └─3106 /usr/bin/pipewire
│ │ ├─background.slice
│ │ │ ├─plasma-kactivitymanagerd.service
│ │ │ │ └─3546 /usr/lib/x86_64-linux-gnu/libexec/kactivitymanagerd
│ │ │ ├─plasma-kscreen.service
│ │ │ │ └─3610 /usr/lib/x86_64-linux-gnu/libexec/kf5/kscreen_backend_launcher
│ │ │ ├─plasma-baloorunner.service
│ │ │ │ └─5633 /usr/lib/x86_64-linux-gnu/libexec/baloorunner
│ │ │ ├─plasma-kglobalaccel.service
│ │ │ │ └─3452 /usr/bin/kglobalaccel5
│ │ │ └─tracker-miner-fs-3.service
│ │ │ └─3148 /usr/libexec/tracker-miner-fs-3
│ │ ├─app.slice
│ │ │ ├─app-\\x2fusr\\x2fbin\\x2fkorgac-d27ecb9065d646918a10df1c4fa798fe.scope
│ │ │ │ └─3599 /usr/bin/korgac -session 10dfe2702d000165869202400000083140007_1663442587_18526
│ │ │ ├─gvfs-goa-volume-monitor.service
│ │ │ │ └─3171 /usr/libexec/gvfs-goa-volume-monitor
│ │ │ ├─app-dbus\\x2d:1.2\\x2dorg.gnome.OnlineAccounts.slice
│ │ │ │ └─dbus-:[email protected]
│ │ │ │ └─3174 /usr/libexec/goa-daemon
│ │ │ ├─xdg-permission-store.service
│ │ │ │ └─3765 /usr/libexec/xdg-permission-store
│ │ │ ├─com.system76.SystemUpdater.Local.service
Code language: plaintext (plaintext)
Con el systemd-cgtop comando, obtenemos una lista de todos los grupos de control ordenados por la utilización actual de recursos:
systemd-cgtop
Code language: Bash (bash)Ahora bien, ¿por qué es esto importante para nosotros? Ahora podemos analizar la utilización de recursos de procesos individuales y, si es necesario, ajustar la prioridad del proceso o cambiar el límite de recursos.
La página man nos da muchas posibilidades para gestionar esto:
man systemd.resource-control
Code language: Bash (bash)Por ejemplo, si queremos establecer el límite de memoria de un servicio específico, podemos usar:
systemctl set property example.service MemoryLimit=1G
Code language: Bash (bash)Registro - DiarioD
JournalD registra todos los eventos en la RAM del sistema. Esto se borrará con un reinicio del sistema.
Puede usar JournalD con el siguiente comando:
journalctl
Code language: Bash (bash)Podemos refinar aún más la salida agregando filtros, por ejemplo, con un tiempo específico:
journalctl – since yesterday
Code language: Bash (bash)Podemos refinarlo aún más especificando un período de tiempo exacto desde hasta:
journalctl – since "date" – until "date"
Code language: Bash (bash)Otra forma de filtrar es seguir servicios específicos:
journalctl -u example
Code language: Bash (bash)También podemos seguir un servicio específico y filtrar solo por este:
journalctl -fu example
Code language: Bash (bash)También podríamos filtrar solo por eventos del kernel:
journalctl -k
Code language: Bash (bash)Resumen
SystemD es un sólido sucesor del demonio de inicio System V clásico y brinda al administrador una gran cantidad de información y herramientas útiles que aceleran el trabajo y el flujo de trabajo diarios. Si desea obtener más información sobre otros temas de Linux en profundidad, asegúrese de visitar el blog de Max Wilke.
- SystemD es una herramienta de administración del sistema que se puede usar para tareas como administrar los recursos del sistema y procesos , optimización del rendimiento del sistema y mejorar la seguridad .
- SystemD ofrece una serie de beneficios que pueden ayudar a las organizaciones a mejorar la eficiencia y la productividad , incluida la priorización de procesos , registro de eventos del sistema y controles de asignación de recursos .
- Si bien SystemD es ampliamente utilizado por muchas industrias diferentes debido a sus poderosas capacidades, a algunos usuarios no les gusta porque es complejo o difícil de usar . Además, algunos críticos argumentan que puede afectar negativamente el rendimiento del sistema .
- A pesar de estas preocupaciones, SystemD sigue siendo una de las herramientas de administración de sistemas más populares del mercado actual.