ECS : Latence rencontrée lors de la connexion ou de l’authentification à un nœud spécifique
Résumé: Latence ou lenteur de réponse rencontrée lors de la connexion à un système à l’aide de SSH ou de l’exécution de commandes qui nécessitent une authentification pour une session à distance. ...
Cet article concerne
Cet article ne concerne pas
Cet article n’est associé à aucun produit spécifique.
Toutes les versions du produit ne sont pas identifiées dans cet article.
Symptômes
Lors de l’établissement d’une connexion SSH à un nœud, de l’exécution de sudo ou de toute autre commande nécessitant une authentification, un délai se produit. Après le délai, la commande s’exécute normalement. Le nœud n’est pas surchargé et le temps d’activité affiche des moyennes de charge normales.
Si verbosity est activé pour une connexion ssh à l’aide de -vvv, le délai de connexion se produit après « pledge : exec »
Exemple :
Après une pause de 20+ secondes, la connexion se déroulera normalement.
Sur le nœud rencontrant le problème, si l’état du service dbus est vérifié, il signale les délais d’expiration :
Des messages de délai d’expiration similaires se trouvent dans /var/log/messages
Si verbosity est activé pour une connexion ssh à l’aide de -vvv, le délai de connexion se produit après « pledge : exec »
Exemple :
admin:~> ssh 169.254.1.2 -vvv OpenSSH_7.2p2, OpenSSL 1.0.2p-fips 14 Aug 2018 debug1: Reading configuration data /home/admin/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 25: Applying options for * debug2: resolving "169.254.1.2" port 22 debug2: ssh_connect_direct: needpriv 0 debug1: Connecting to 169.254.1.2 [169.254.1.2] port 22. debug1: Connection established. ... <truncated debugging> debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug3: send packet: type 90 debug1: Requesting no-more-sessions@openssh.com debug3: send packet: type 80 debug1: Entering interactive session. debug1: pledge: exec
Après une pause de 20+ secondes, la connexion se déroulera normalement.
Sur le nœud rencontrant le problème, si l’état du service dbus est vérifié, il signale les délais d’expiration :
admin:~> sudo systemctl status dbus
● dbus.service - D-Bus System Message Bus
Loaded: loaded (/usr/lib/systemd/system/dbus.service; static; vendor preset: disabled)
Active: active (running) since Fri 2024-01-23 04:56:00 UTC; 1 months 2 days ago
Docs: man:dbus-daemon(1)
Main PID: 3060 (dbus-daemon)
Tasks: 1 (limit: 512)
Memory: 5.8M
CPU: 10h 45min 897ms
CGroup: /system.slice/dbus.service
└─3060 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
Mar 22 18:28:54 <ecs-node-fqdn> dbus[3060]: [system] Connection has not authenticated soon enough, closing it (auth_timeout=30000ms, elapsed: 30000ms)
Mar 22 18:28:54 <ecs-node-fqdn> dbus[3060]: [system] Connection has not authenticated soon enough, closing it (auth_timeout=30000ms, elapsed: 30000ms)
Mar 22 18:28:54 <ecs-node-fqdn> dbus[3060]: [system] Connection has not authenticated soon enough, closing it (auth_timeout=30000ms, elapsed: 30000ms)
Mar 22 18:28:54 <ecs-node-fqdn> dbus[3060]: [system] Connection has not authenticated soon enough, closing it (auth_timeout=30000ms, elapsed: 30000ms)
Mar 22 18:28:54 <ecs-node-fqdn> dbus[3060]: [system] Connection has not authenticated soon enough, closing it (auth_timeout=30000ms, elapsed: 30000ms)
Mar 22 18:28:54 <ecs-node-fqdn> dbus[3060]: [system] Connection has not authenticated soon enough, closing it (auth_timeout=30000ms, elapsed: 30000ms)
Mar 22 18:29:22 <ecs-node-fqdn> dbus[3060]: [system] Connection has not authenticated soon enough, closing it (auth_timeout=30000ms, elapsed: 30009ms)
Mar 22 18:29:24 <ecs-node-fqdn> dbus[3060]: [system] Connection has not authenticated soon enough, closing it (auth_timeout=30000ms, elapsed: 30002ms)
Mar 22 18:29:54 <ecs-node-fqdn> dbus[3060]: [system] Connection has not authenticated soon enough, closing it (auth_timeout=30000ms, elapsed: 30000ms)
Mar 22 18:30:01 <ecs-node-fqdn> dbus[3060]: [system] Connection has not authenticated soon enough, closing it (auth_timeout=30000ms, elapsed: 30000ms)
Des messages de délai d’expiration similaires se trouvent dans /var/log/messages
Cause
Une limite de connexion pour le service dbus est atteinte, ce qui entraîne un retard pour la connexion et/ou l’authentification
Résolution
Ce problème peut être corrigé en redémarrant le service dbus et aussi, pour les nœuds principaux : le service dnsmasq. Aucun impact n’est prévu, mais vous devez obtenir l’approbation du client si nécessaire.
À partir du nœud présentant le problème, redémarrez dbus à l’aide de la commande :
Une fois la commande terminée, vérifiez l’état du service dbus pour vous assurer qu’il est actif (en cours d’exécution) en exécutant la commande ci-dessous :
Si le nœud est un nœud principal (généralement le nœud 1), il est également nécessaire de redémarrer dnsmasq avec la commande :
Après le redémarrage de dnsmasq, vérifiez que le service est actif (en cours d’exécution) à l’aide de la commande :
Une fois les services redémarrés, testez l’accès au nœud à l’aide de SSH ou en exécutant une commande sudo pour observer que le retard a été résolu.
À partir du nœud présentant le problème, redémarrez dbus à l’aide de la commande :
sudo systemctl restart dbus admin:~> sudo systemctl restart dbusAucun résultat n’est attendu de cette commande.
Une fois la commande terminée, vérifiez l’état du service dbus pour vous assurer qu’il est actif (en cours d’exécution) en exécutant la commande ci-dessous :
sudo systemctl status dbus
admin ~> sudo systemctl status dbus
● dbus.service - D-Bus System Message Bus
Loaded: loaded (/usr/lib/systemd/system/dbus.service; static; vendor preset: disabled)
Active: active (running) since Fri 2024-07-19 18:07:00 UTC; 5s ago
Docs: man:dbus-daemon(1)
Main PID: 19340 (dbus-daemon)
Tasks: 1 (limit: 512)
Memory: 884.0K
CPU: 22ms
CGroup: /system.slice/dbus.service
└─19340 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
Si le nœud est un nœud principal (généralement le nœud 1), il est également nécessaire de redémarrer dnsmasq avec la commande :
sudo systemctl restart dnsmasq admin:~> sudo systemctl restart dnsmasqAucun résultat n’est attendu de cette commande.
Après le redémarrage de dnsmasq, vérifiez que le service est actif (en cours d’exécution) à l’aide de la commande :
sudo systemctl status dnsmasq
admin~> sudo systemctl status dnsmasq
● dnsmasq.service - DNS caching server.
Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; disabled; vendor preset: disabled)
Drop-In: /run/systemd/generator/dnsmasq.service.d
└─50-insserv.conf-$named.conf
Active: active (running) since Fri 2024-07-19 18:14:47 UTC; 2s ago
Process: 61272 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS)
Main PID: 61297 (dnsmasq)
Tasks: 1 (limit: 512)
Memory: 2.1M
CPU: 8ms
CGroup: /system.slice/dnsmasq.service
└─61297 /usr/sbin/dnsmasq --log-async --enable-dbus --keep-in-foreground
Une fois les services redémarrés, testez l’accès au nœud à l’aide de SSH ou en exécutant une commande sudo pour observer que le retard a été résolu.
Produits concernés
ECS, ECS Appliance, ECS Appliance Gen 1, ECS Appliance Gen 2, ECS Appliance Gen 3, ECS Appliance Hardware Gen1 U-Series, ECS Appliance Hardware Gen1 C-Series, ECS Appliance Hardware Gen2 C-Series, ECS Appliance Hardware Gen2 D-Series
, ECS Appliance Hardware Gen2 U-Series
...
Produits
ECS Appliance Hardware Gen3 EX5000, ECS Appliance Hardware Gen3 EX300, ECS Appliance Hardware Gen3 EX3000, ECS Appliance Hardware Gen3 EX500, ECS Appliance Hardware Gen3 EXF900, ECS Appliance Hardware Series, ECS Appliance Software with Encryption
, ECS Appliance Software without Encryption, ECS Software
...
Propriétés de l’article
Numéro d’article: 000227096
Type d’article: Solution
Dernière modification: 02 août 2024
Version: 1
Trouvez des réponses à vos questions auprès d’autres utilisateurs Dell
Services de support
Vérifiez si votre appareil est couvert par les services de support.