Seltsame Verzoegerungen beim Remote-Login

bitmuncher

bitmuncher

Senior-Nerd
Ich habe hier eine Dell-Kiste zu stehen (PowerEdge 2950), bei der ein Login via SSH oder auf dem Samba-Server ziemlich seltsame Verzoegerungen hat. Bevor z.B. beim SSH-Login die Shell angezeigt wird, dauert es 3-5 Sekunden. Auch beim Anmelden am Samba-Server (als PDC eingerichtet), dauert es immer ein paar Sekunden. In den Logs findet sich rein garnichts, was auf eine Unregelmaessigkeit hinweisen wuerde. Hardwaretechnisch scheint auch alles in Ordnung zu sein (Festplatte liefert 106,87MB/sec Durchsatz, CPU bringt volle Leistung usw.) und Last liegt auf dem Server auch nicht sonderlich viel an (zwischen 0.6 und 1.5), die primaer durch den dbus-daemon und den nmbd verursacht wird. Der lokale Login funktioniert allerdings ohne Verzoegerung. Ein Problem in der Netzwerkkarte schliesse ich auch aus, da nach dem Login der volle Datendurchsatz zur Verfuegung steht. Was evtl. noch wichtig ist, ist die Tatsache, dass die Kiste 3 Netzwerkkarten hat, wobei 2 zu einer zusammengefasst sind, so dass beim Ausfall der einen Karte die zweite deren Arbeit uebernimmt. Sie laufen also auf der gleichen IP. Leider konnte ich im BIOS noch keine Moeglichkeit entdecken diese Failover-Loesung zu deaktivieren.

Vielleicht hat ja jemand eine Idee woher diese Verzoegerungen beim Login kommen koennen. Ich bin langsam ratlos. Ist es moeglich, dass die Failover-Loesung des Netzwerks das Problem darstellt? Kann mir evtl. jemand sagen, wie ich das im BIOS, ueber IPMI, Dells srvadmin/OMSA oder wie auch immer deaktivieren kann (handelt sich um einen Office-Server, muss also nicht hochverfuegbar sein)?
 
Ich kenne das Phänomen eigentlich nur von Kisten mit deutlicher Belastung (>>1.5).
Da entsteht das dann, wenn der ssh daemon die shell startet, selber in den sleep geht und es noch ne ganze weile dauert, bis die shell das erste mal dran kommt.

Wenn das allerdings beim Samba auch eintritt, dann würde ich an deiner Stelle mal folgendes versuchen:
1. log dich mal mit falschem Kennwort ein, wenn die entsprechende Antwort ebenfalls lange dauert, dann liegts an am sshd bzw. an der Netzwerkverbindung, in dem Fall ist tcpdump dein Freund um mal zu schauen, wie lange die replys so brauchen. (Eventuell gehen die ja auch irgendwo verschütt?)

2. Wenn diese Antwort sehr schnell erfolgt kann es eigtl. nur am scheduling liegen, dann könnten konkurrierende HD, LAN Zugriffe etc. eine Rolle spielen. Einfach mal den ein oder anderen Prozess stoppen um das zu testen.

Ist eventuell sshd einfach nur geniced? Was passiert denn bei ssh bitmuncher@localhost?
 
Der Hinweis mit dem localhost war gut. Nun kann ich das Netzwerk also auch ausschliessen, denn auch dabei kommt es zu Verzoegerungen. Wuerden Konflikte zwischen Hardware-Komponenten (HD vs. Netzwerk o.ae.) bestehen, wuerde davon aber im Normalfall was in den Boot-Logs auftauchen. Die sind aber sauber. Selbst wenn ich alles stoppe, was nicht absolut notwendig ist (also SSH und Samba laufen weiter, alle anderen Tools wie IDS, NTop, OMSA usw. sind aus), aendert das nichts an der Situation.

Edit: Hab's jetzt mal mit 'time' durchgemessen. Der Login dauert etwa 3 Mal so lange wie auf allen anderen Rechnern im Netzwerk und das obwohl die Kiste eigentlich die ist, die die schnellste Hardware hier im LAN hat.
 
Juhu, danke. Das strace hat mir das Problem gezeigt. Ich hatte noch LDAP in der nsswitch.conf drin, obwohl LDAP-Auth erstmal deaktiviert wurde. Herzlichen Dank. :)

Er hing naemlich bei dieser Stelle:

Code: 
[pid  1628] rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
[pid  1628] rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
[pid  1628] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid  1628] nanosleep({1, 0}, {1, 0})   = 0
[pid  1628] stat64("/etc/libnss-ldap.conf", {st_mode=S_IFREG|0644, st_size=9820, ...}) = 0

Hab aus der nsswitch.conf nun die ldap-Sachen rausgenommen und alles hat die Geschwindigkeit, die man von der Kiste erwarten kann. Grosses Knuddel, hab da naemlich jetzt bestimmt 3 Stunden mit verschwendet. :)
 
Nix zu danken, dafür hockt man ja Freitagnachmittag noch am Rechner, obwohl man längst im Auto von Berlin in die Prignitz sitzen müsste!
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben