Un servidor Linux que tarda un minuto en iniciarse puede pasar la mayor parte de ese tiempo esperando una o dos unidades systemd. A continuación se explica cómo utilizar systemd-analyze para identificar retrasos y solucionar causas comunes relacionadas con esperas en línea, /etc/fstab y dependencias de unidades.
Imagínese reiniciar su servidor después de una actualización del kernel y descubrir que SSH sigue sin estar disponible durante más de un minuto. El hardware puede estar bien. Una interfaz de red que nunca está lista, un disco que ha caducado o un servicio que está esperando otra unidad pueden retrasar el proceso de inicio.
systemd La unidad de seguimiento inicia la actividad mientras systemd-analyze Le ayuda a comprobar los tiempos de inicio e identificar posibles cuellos de botella. Los comandos de esta guía se aplican a La mayoría de las distribuciones de Linux Y la ruta de configuración puede variar según la distribución.
Cómo funcionan las dependencias de unidades de systemd
Aprende como systemd La programación de unidades facilita la resolución de problemas de retrasos en el inicio. systemd Inicie unidades independientes en paralelo y utilice dependencias y reglas de ordenación para determinar qué unidades deben esperar a otras unidades.
Dos pares de instrucciones controlan gran parte de este comportamiento:
Wants=yRequires=Definir dependencias.Wants=Introduce otra unidad en el intercambio sin forzarla a tener éxito mientrasRequires=Genera dependencias más fuertes, aunque su comportamiento exacto de falla y detención también depende de las relaciones de orden y otras configuraciones de la unidad.After=yBefore=Solo se define la secuencia de inicio y no incorporan otra unidad a una transacción ni inician ellos mismos. Por ejemplo,After=network-online.targetIndica que una unidad comienza después de este objetivo (si ambos son parte de una transacción).
en un tipico linux servidor, multi-user.target es el objetivo predeterminado. Las unidades que deben iniciarse antes de que el sistema alcance este objetivo pueden provocar retrasos en el inicio. La cadena crítica muestra la secuencia relacionada más larga de iniciaciones de unidades ordenadas, lo que te ayuda a determinar dónde investigar primero.
![Cómo compartir la pantalla del escritorio de Fedora [GNOME] remotamente](https://muylinux.xyz/wp-content/uploads/2023/01/1673311581_Como-compartir-la-pantalla-del-escritorio-de-Fedora-GNOME-remotamente-220x150.jpg)
1. Utilice systemd-analyze para comprobar el tiempo de inicio
Comience midiendo el tiempo de inicio para establecer una línea de base. Puede comparar este resultado con mediciones posteriores para ver si sus cambios realmente mejoraron el inicio:
systemd-analyze time
Ejemplo de salida:
Startup finished in 1.912s (kernel) + 2.877s (initrd) + 34.118s (userspace) = 38.907s multi-user.target reached after 34.090s in userspace.
En este ejemplo, el sistema tarda aproximadamente 39 segundos en iniciarse y la mayor parte del tiempo informado transcurre en el espacio del usuario. Aquí es donde systemd inicia servicios, monta sistemas de archivos e inicia otros componentes del sistema. El tiempo variará según el hardware, la distribución y la configuración.
2. Encuentre unidades lentas a través de systemd-analyze
Una vez que tenga una línea de base, podrá determinar qué unidad tiene el tiempo de activación más largo. La directiva de culpa ordena las unidades por tiempo de inicio, colocando primero las entradas con el tiempo de ejecución más largo:
systemd-analyze blame | head -n 4
Ejemplo de salida:
30.061s systemd-networkd-wait-online.service 4.882s snapd.seeded.service 1.912s snapd.service 1.204s cloud-init-local.service
En este ejemplo, systemd-networkd-wait-online.service fue la primera unidad en realizar la encuesta, ya que tardó aprox. 30 Activar en segundos.
Sin embargo, no asuma que la unidad más lenta necesariamente retrasará todo el tiempo de arranque. Las unidades pueden comenzar al mismo tiempo y algunas unidades pueden continuar comenzando sin bloquear el objetivo preestablecido.
usar systemd-analyze blame Identifique al sospechoso y luego examine la cadena crítica y los registros de la unidad para determinar si un servicio específico realmente está bloqueando el inicio.
3. Utilice cadenas críticas para encontrar cuellos de botella en las startups
Para determinar qué unidades están realmente retrasando un objetivo preestablecido, utilice critical-chain. Muestra la cadena de dependencia relevante, activada en @ y la duración del arranque del dispositivo +:
systemd-analyze critical-chain
Salida (fila de título recortada):
multi-user.target @34.090s
└─nginx.service @33.851s +231ms
└─network-online.target @33.842s
└─systemd-networkd-wait-online.service @3.779s +30.061s
└─systemd-networkd.service @3.551s +215ms
nginx Fue ordenado después network-online.targetespera 30 segundos para wait-online servicea pesar de snapd Nunca aparece en la cadena.
Si esto le ayuda a comprender la diferencia entre un dispositivo lento y un dispositivo que retrasa el inicio, compártalo con cualquier persona que todavía esté desactivando el servicio directamente desde la Lista de responsabilidad.
4. Utilice systemctl para bloquear servicios innecesarios
Antes de ajustar el retraso de inicio, desactive los servicios que su servidor no necesita. Enumere las unidades de servicio habilitadas y verifique si hay software o hardware que la máquina nunca haya usado:
systemctl list-unit-files --type=service --state=enabled
Por ejemplo, es posible que un servidor virtual sin un módem de banda ancha móvil no requiera ModemManager. Si nada depende de ello, detenga el servicio y desactívelo al inicio:
sudo systemctl disable --now ModemManager.service
La desactivación elimina la habilitación de inicio del servicio, pero aún es posible que otra unidad o solicitud de D-Bus lo inicie. Para evitar la activación normal, bloquee el servicio:
sudo systemctl mask ModemManager.service
Producción:
Created symlink '/etc/systemd/system/ModemManager.service' → '/dev/null'.
Bloquear es más fuerte que deshabilitar porque systemd Mientras la mascarilla permanezca colocada, el dispositivo no podrá activarse por medios normales. Para revertirlo, unmask Atender:
sudo systemctl unmask ModemManager.service
Ten cuidado: No deshabilite ni bloquee ciegamente systemd-*, almacenamiento o servicios de red. Algunos de ellos son fundamentales para iniciar, montar sistemas de archivos y mantener el acceso remoto. Verifique el propósito y las dependencias de cada servicio antes de realizar cambios.
5.Reparar el retraso systemd-networkd-wait-online
existir ubuntu servidor, systemd-networkd-wait-online El inicio puede retrasarse cuando una interfaz administrada nunca alcanza el estado en línea requerido. Por ejemplo, una NIC secundaria que no está conectada puede dejar de funcionar network-online.target hasta que expire el tiempo de espera configurado y se muestre un mensaje en la consola, p.e. «El trabajo de inicio se está ejecutando, esperando la configuración de la red».
Si Nginx u otras aplicaciones dependen del servicio de espera, no lo desactive ciegamente. network-online.target. Primero, verifique su configuración actual y ruta ejecutable:
systemctl cat systemd-networkd-wait-online.service
Verifique sus interfaces de red para determinar cuáles deben estar en línea:
ip -br link
Si la versión de systemd instalada admite el comportamiento específico de la interfaz requerido, cree una anulación directa:
sudo systemctl edit systemd-networkd-wait-online.service
Agregue la siguiente configuración y reemplace enpu1s0 Utilice su interfaz real y ajuste el tiempo de espera para adaptarlo a su entorno:
# /etc/systemd/system/systemd-networkd-wait-online.service.d/override.conf [Service] ExecStart= ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --interface=enp1s0 --timeout=20
Guarde el archivo y salga del editor.
ExecStart=Borre el comando original para que systemd use el comando de reemplazo.--interface=enp1s0Especifique interfaces cuyo estado en línea sea importante. Verifica el comportamiento de esta opción para la versión de systemd que tienes instalada.--timeout=20Limite el tiempo de espera a 20 segundos.
Vuelva a cargar la configuración de systemd y reinicie el servicio para aplicar la anulación para inicios posteriores:
sudo systemctl daemon-reload
Reinicie en la ventana de mantenimiento adecuada y compare los resultados:
systemd-analyze critical-chain network-online.target
existir LokiLinux, AlmaLinuxy RHEL, NetworkManager Normalmente maneja la configuración de la red. si NetworkManager-wait-online.service Retrasando el inicio, verifique el perfil de conexión antes de cambiar la configuración para determinar por qué está esperando, como por ejemplo una respuesta DHCP que nunca llegó.
Si una tarjeta de red desconectada agrega dos minutos al tiempo de inicio, comparta esta información con los compañeros de equipo que estén reiniciando el servidor durante una ventana de mantenimiento.
6.Solucionar el problema del montaje lento de fstab cuando se usa nofail
Los discos faltantes y los recursos compartidos de red inalcanzables pueden retrasar el inicio mientras systemd espera sus unidades de instalación. Utilice nofail para discos opcionales y utilice x-systemd.automount para retrasar el montaje de recursos compartidos de red hasta que se acceda a ellos.
Abierto /etc/fstab existir ubuntu o Durban:
sudo nano /etc/fstab
existir LokiLinux, AlmaLinuxy RHELVaso mínimo de instalación vi en cambio:
sudo vi /etc/fstab
Por ejemplo, configure el disco de datos y el uso compartido de la copia de seguridad NFS de la siguiente manera:
# /etc/fstab UUID=3f1c2a7e-8b4d-4e2a-9c61-5d7f0b9e2a14 /data ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2 192.168.122.250:/srv/backups /mnt/backups nfs defaults,_netdev,x-systemd.automount 0 0
Reemplace el UUID de muestra con el valor informado por blkid y la dirección NFS con la dirección de su servidor.
Estas opciones controlan cómo systemd maneja los montajes:
- promesa fallida Permite que el inicio continúe si no se puede montar el disco opcional.
- x-systemd.device-timeout=10s Limita el tiempo que systemd espera hasta que aparezca un dispositivo. No limita el tiempo necesario para montar el sistema de archivos.
- _netdev Marque la instalación como dependiente de la red.
- x-systemd.automount Cree una unidad de montaje automático que active el montaje real cuando se acceda a la ruta, en lugar de montar el recurso compartido inmediatamente durante el arranque.
Verifique el archivo editado y vuelva a cargar la configuración de la unidad de systemd:
sudo findmnt --verify sudo systemctl daemon-reload
Comprueba las unidades resultantes:
systemctl status data.mount systemctl status mnt-backups.automount
El nombre de la unidad se deriva de su ruta de instalación, por lo que /data convertirse data.mount y /mnt/backups convertirse mnt-backups.automount.
Corrija cualquier error de validación antes de continuar. En un sistema de prueba adecuado, verifique que el disco opcional pueda estar ausente sin impedir el arranque y que el recurso compartido NFS se monte correctamente en las siguientes condiciones: /mnt/backups fue visitado. \
recordar Los servicios de inicio que acceden al recurso compartido aún pueden desencadenar montajes de NFS y experimentar retrasos en la red.
7. Utilice Wants= en lugar de Requires=
Los errores de dependencia de Systemd pueden retrasar el inicio o hacer que el servicio se detenga inesperadamente. Por ejemplo, una aplicación que sólo escucha en un socket nativo no necesariamente necesita esperar network-online.target. Asimismo, Requires= crear dependencias más fuertes Wants=pero ninguna directiva reemplaza el procesamiento adecuado de preparación del servicio.
Crea un archivo unitario con nano ubuntu y Durban:
sudo nano /etc/systemd/system/myapp.service
existir LokiLinux, AlmaLinuxy RHELusar vi:
sudo vi /etc/systemd/system/myapp.service
Agregue la siguiente configuración, reemplazando la ruta ejecutable y la cuenta de servicio con sus propios valores:
# /etc/systemd/system/myapp.service [Unit] Description=Internal API for tecmint.lan Wants=postgresql.service After=network.target postgresql.service [Service] User=tecmint ExecStart=/opt/myapp/bin/myapp Restart=on-failure [Install] WantedBy=multi-user.target
Guarde el archivo y salga del editor.
Wants=postgresql.servicePostgreSQL se incorpora a la transacción cuando se inicia la aplicación, pero si PostgreSQL falla, la aplicación aún puede iniciarse.After=network.target postgresql.serviceOrdena las aplicaciones después de estas unidades durante el inicio. Por sí solo no los incluye en transacciones ni garantiza que PostgreSQL esté listo para aceptar conexiones.Restart=on-failureSi la aplicación no sale, se reinicia, sujeta a las restricciones de reinicio de systemd. La aplicación no reintentará la conexión a la base de datos a menos que salga o implemente su propia lógica de reintento.
usar Wants=network-online.target con After=network-online.target Solo si el servicio requiere configuración de red antes de comenzar, esto puede reintroducir el retraso de espera en línea discutido en el Consejo 5.
Verifique la unidad, recargue systemd y habilite el servicio:
sudo systemd-analyze verify /etc/systemd/system/myapp.service sudo systemctl daemon-reload sudo systemctl enable --now myapp.service
Si la validación es exitosa, generalmente no se produce ningún resultado. Verifique el estado del servicio y los registros para confirmar que la aplicación realmente se está iniciando y conectando a PostgreSQL:
systemctl status myapp.service journalctl -u myapp.service -b --no-pager
recordar: Wants= Activación dependiente del control mientras After= Secuenciación de controles. Para un inicio confiable de la base de datos, configure la aplicación para reintentar conexiones o use comprobaciones de preparación apropiadas para la aplicación y la base de datos.
si es necesario = con Wants= Finalmente tiene sentido compartir esto con los desarrolladores que escriben unidades systemd para su equipo.
Consejo profesional: confirme las ganancias y evite fallas en el lanzamiento
Después de realizar estos cambios, reinicie y ejecute systemd-analyze time y critical-chain Compare nuevamente con su línea de base.
Si el inicio se detiene en «Estás en modo de emergencia.”Después de editar fstab, ejecute journalctl -xb encontrar el fracaso .mount unidad. Ubuntu bloquea la cuenta raíz de forma predeterminada, por lo que es posible que el modo de emergencia no abra el shell, he aquí por qué findmnt --verify Importante en servidores que solo admiten SSH.
«Unidad ModemManager.service está bloqueado» significa que la unidad todavía es necesaria para algo, y «Descubra el ciclo de pedidos«significa dos After= Las líneas apuntan una hacia la otra.
en conclusión
Ahora puede medir los tiempos de arranque, encontrar unidades que realmente están retrasadas en el inicio y reparar servicios no utilizados, retrasos en la espera en línea, instalaciones lentas y secuenciación de unidades.
Nos encantaría saber lo que descubrió. ¿Qué unidad está en la cima de su cadena crítica? ¿Alguna vez el servicio de bloqueo ha roto algo inesperado? No dude en compartir sus anulaciones de espera en línea u opciones de fstab en los comentarios.
