ECS: Latenz beim Anmelden oder Authentifizieren bei einem bestimmten Node
Summary: Latenz oder langsame Reaktion bei der Anmeldung an einem System über SSH oder beim Ausführen von Befehlen, die eine Authentifizierung für eine Remotesitzung erfordern.
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Symptoms
Beim Herstellen einer SSH-Verbindung zu einem Node, beim Ausführen von sudo oder einem anderen Befehl, für den eine Authentifizierung erforderlich ist, tritt eine Verzögerung auf. Nach der Verzögerung wird der Befehl normal ausgeführt. Der Node ist nicht stark ausgelastet und die Betriebszeit zeigt Durchschnittswerte der normalen Auslastung an.
Wenn die Ausführlichkeit für eine SSH-Verbindung mit -vvv aktiviert ist, tritt die Anmeldeverzögerung nach "pledge: exec"
auf. Beispiel:
Nach einer Pause von 20+ Sekunden wird die Anmeldung normal fortgesetzt.
Wenn auf dem Node mit diesem Problem der dbus-Servicestatus überprüft wird, werden Timeouts gemeldet:
Ähnliche Timeout-Meldungen finden Sie in /var/log/messages
Wenn die Ausführlichkeit für eine SSH-Verbindung mit -vvv aktiviert ist, tritt die Anmeldeverzögerung nach "pledge: exec"
auf. Beispiel:
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
Nach einer Pause von 20+ Sekunden wird die Anmeldung normal fortgesetzt.
Wenn auf dem Node mit diesem Problem der dbus-Servicestatus überprüft wird, werden Timeouts gemeldet:
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)
Ähnliche Timeout-Meldungen finden Sie in /var/log/messages
Cause
Ein Verbindungslimit für den dbus-Service wird erreicht, was zu einer Verzögerung bei der Anmeldung und/oder Authentifizierung führt
Resolution
Dieses Problem kann behoben werden, indem Sie den dbus-Service und für primäre Nodes auch den dnsmasq-Service neu starten. Es sind keine Auswirkungen zu erwarten. Holen Sie jedoch bei Bedarf die Genehmigung des Kunden ein.
Starten Sie dbus auf dem Node, der das Problem aufweist, mit dem folgenden Befehl neu:
Überprüfen Sie nach Abschluss des Befehls den Status des dbus-Service, um sicherzustellen, dass er "active (running)" ist, indem Sie den folgenden Befehl ausführen:
Wenn es sich bei dem Node um einen primären Node handelt (in der Regel Node 1), muss dnsmasq mit dem folgenden Befehl neu gestartet werden:
Überprüfen Sie nach dem Neustart von dnsmasq, ob der Service "active (running)" ist, indem Sie den folgenden Befehl verwenden:
Sobald die Services neu gestartet wurden, testen Sie den Zugriff auf den Node mithilfe von SSH oder führen Sie einen sudo-Befehl aus, um festzustellen, ob die Verzögerung behoben wurde.
Starten Sie dbus auf dem Node, der das Problem aufweist, mit dem folgenden Befehl neu:
sudo systemctl restart dbus admin:~> sudo systemctl restart dbusVon diesem Befehl wird keine Ausgabe erwartet.
Überprüfen Sie nach Abschluss des Befehls den Status des dbus-Service, um sicherzustellen, dass er "active (running)" ist, indem Sie den folgenden Befehl ausführen:
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
Wenn es sich bei dem Node um einen primären Node handelt (in der Regel Node 1), muss dnsmasq mit dem folgenden Befehl neu gestartet werden:
sudo systemctl restart dnsmasq admin:~> sudo systemctl restart dnsmasqVon diesem Befehl wird keine Ausgabe erwartet.
Überprüfen Sie nach dem Neustart von dnsmasq, ob der Service "active (running)" ist, indem Sie den folgenden Befehl verwenden:
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
Sobald die Services neu gestartet wurden, testen Sie den Zugriff auf den Node mithilfe von SSH oder führen Sie einen sudo-Befehl aus, um festzustellen, ob die Verzögerung behoben wurde.
Affected Products
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
...
Products
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
...
Article Properties
Article Number: 000227096
Article Type: Solution
Last Modified: 02 Aug 2024
Version: 1
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.