SSH Verbindung friert ein

caMelCase

New Member
Hallo zusammen,

beim Zugriff per SSH auf meinen VirtualServer der unter Debian Etch läuft, hängt sich öfter mal die Verbindung auf.

Beim Verwenden einzelner Shell-Befehle, wie ls, cp, mv, vzfree tritt dies nur sehr selten auf. Häufiger kommt die SSH-Verbindung beim Aufruf von z.B. mc, apt-get update, top zum erliegen, wobei es mit "apt-get update" am häufigsten vorkommt. Es gibt also eher Probleme mit Programme, die viel oder regelmäßigen Output produzieren. Allerdings macht ein "cat /var/log/messages" weniger bzw. keine Probleme.

Es äußert sich so, dass z.B. beim Aufsühren von "apt-get update" alle Paketquellen angezeigt werden, jedoch bleibt es am Schluss beim lesen der Paketquellen bei 99% stehen.

Das Terminal friert sozusagen ein. Ein Close der Verbindung vom Server erfolgt nicht (damit meine ich die Meldung die "connection reset by peer" oder so ähnlich lautet). Eine Trennung der DSL-Verbindung durch den ISP liegt zu diesem Zeitpunkt nicht vor.

Hier noch die technischen Daten:
vom Server (Debian 4.0 ETCH)
Code:
# dpkg -l | grep ssh
ii  openssh-blacklist              0.1.1                                list of blacklisted OpenSSH RSA and DSA keys
ii  openssh-client                 4.3p2-9etch3                         Secure shell client, an rlogin/rsh/rcp repla
ii  openssh-server                 4.3p2-9etch3                         Secure shell server, an rshd replacement
ii  ssh                            4.3p2-9etch3                         Secure shell client and server (transitional

und vom Client (Ubuntu 8.10)
Code:
# dpkg -l | grep ssh
ii  openssh-client                            1:5.1p1-3ubuntu1                                           secure shell client, an rlogin/rsh/rcp replacement


Wer hat dazu eine Idee?

MfG,
Frank
 
Hi,

sofern mit Virtuozzo oder OpenVZ virtualisiert wird, könnte die Ausgabe von 'cat /proc/user_beancounters' hilfreich sein.


-W
 
Code:
# cat /proc/user_beancounters 
Version: 2.5                                                                   
       uid  resource           held    maxheld    barrier      limit    failcnt
      5917: kmemsize        6823406    6838968    9813565   10794921          0
            lockedpages           0          0        331        331          0
            privvmpages       84733      84779     136843     150528          0
            shmpages           3322       3322      38400      38400          0
            dummy                 0          0          0          0          0
            numproc              81         81        240        240          0
            physpages         49316      49316          0 2147483647          0
            vmguarpages           0          0      98304 2147483647          0
            oomguarpages      49499      49499      98304 2147483647          0
            numtcpsock           23         23        240        240          0
            numflock             18         20        262        288          0
            numpty                1          1         16         16          0
            numsiginfo            0          1       1024       1024          0
            tcpsndbuf        185588     185588    1589979    2261723          0
            tcprcvbuf        182172     182172    1589979    2261723          0
            othersockbuf     234012     234012     794989    1466733          0
            dgramrcvbuf           0          0     794989     794989          0
            numothersock        148        148        240        240          0
            dcachesize       379135     380902    1511424    1556766          0
            numfile            3085       3085       3840       3840       3746
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            numiptent            14         14         35         35          0

Dabei fällt mir numfile auf. Ist das die Anzahl der aktuell geöffneten Dateien?
Das hohe failcnt kann evtl. auch etwas mit dem Ausfall des Servers auf dem die Virtualisierung läuft zu tun haben. Das war am 14.5.09. Das Problem mit ssh besteht jedoch schon länger.

Frank
 
Hi,

mit "Ausfall" verstehe ich in Deinem Fall, dass das Hostsystem ausgefallen ist und vermutlich mindestens einen Reboot erlebt hat. Der failcount wird in diesem Fall auf 0 zurückgesetzt.
Bei 'numfile' handelt es sich in der Tat um die Anzahl geöffneter Dateien. Da die jetzt schon wieder nah am limit sind, könnte das durchaus die Ursache deines Problems sein. 'lsof' sollte dir in diesem Fall helfen, die verursachenden Prozesse ausfindig zu machen.


-W
 
Bei einem Ausfall und damit verbundenem Reboot des Hostsystems werden alle Failcnt Werte auf 0 zurück gesetzt. Davon kann es also eher nicht kommen.
 
Hallo

danke für den Tipp mal mit lsof zu suchen!

Es zeigt mir nur rund 2400 offene Dateien an, obwohl der numfile-Zähler auf ~3000 steht. :confused:
Habe auch bemerkt, dass die Anzahl der offenen Dateien ziemlich schnell (paar Minuten) von 3000 bis auf ca. 3400 steigt und genauso schnell wieder auf 2800 bis 3000 sinkt.

Das Einzige was mir aufgefallen ist, sind mehrmals vom Apache (jeweils selbe PID) geöffnete Access-Logfiles meiner Kunden. Das macht schon mal ca. 150 offene Dateien.

Werde auch mal das im 4-Stunden-Rhythmus laufende rsnapshot-Backup der Kundenverzeichnisse auf täglich reduzieren und weiter beobachten.

Sind 3000 offene Dateien viel für einen VServer (mein Ubuntu hat aktuell 6700 offene Files) und kann es für das SSH Problem doch noch andere Ursachen geben?

Was mir noch eingefallen ist:
Manchmal - aber wirklich nur manchmal - gelingt es, ein "hängendes" Terminal mit einem Tastendruck auf ENTER wiederzubeleben. Vorher 1 Minute lang kein Output, dann ENTER gedrückt (es erscheint im Terminal eine Leerzeile). Ein paar Sekunden später geht es dann weiter mit dem erwarteten Output. Meistens bleibt jedoch nur das Schließen des Terminals und eine Neuanmeldung.

MfG,
Frank
 
Sind 3000 offene Dateien viel für einen VServer (mein Ubuntu hat aktuell 6700 offene Files) und kann es für das SSH Problem doch noch andere Ursachen geben?
Falls Du Plesk einsetzt, hast Du pro Datei mal eben 3 Logfiles ;)

-W
 
Last edited by a moderator:
Hallo nochmal,

also am Plesk kann es nicht liegen, da ich SysCP laufen habe (ich weiss, ist auch nicht das Gelbe vom Ei).

Habe jetzt den numfile-Zähler etwas beobachtet und nun den Apache in Verdacht:
Mein Apache ist als mpm-prefork installiert. Da mein VServer nur 386 MB RAM hat und neben Apache noch Postfix, Amavis, ClamAV, mysql, postgresql, openLDAP und ein regelmäßiges Backup (vorher alle 4h, jetzt alle 24h) läuft, habe ich den Apache so eingestellt, dass er die bei Bedarf eröffneten Child-Prozesse so schnell wie möglich wieder los wird. Dies könnte der Grund für die zwischen 2400 und 3400 schwankenden offenen Files sein. Wenn dann während der Rush-Hour noch ein Backup dazu kommt, dann gelangt der Server vermutlich mit den offenen Files ans Limit.
Ein Apache Prozess hat bei meiner aktuellen Konfiguration ungefähr 150 offene Files.

So was nun? Größerer VServer? Serveranbieter nach einem höheren Limit der numfiles fragen? Server-Konfiguration überarbeiten?

Sind die failcnts der numfiles wirklich die Ursache für die Probleme mit dem ssh?

Danke für Eure Beiträge!

MfG,
Frank
 
Es zeigt mir nur rund 2400 offene Dateien an, obwohl der numfile-Zähler auf ~3000 steht. :confused:
Wenn ich mich richtig erinnere, werden diverse Ressourcen bei Virtuozzo in 8er-Blöcken alloziert, so dass 8 abgerechnet werden, auch wenn nur 1 gebraucht wurde. Numfiles gehört --glaube ich-- auch dazu.
 
Als ich schrieb...
Es zeigt mir nur rund 2400 offene Dateien an, obwohl der numfile-Zähler auf ~3000 steht. :confused:
... wusste ich noch nicht, dass die Zahl der offenen Files ziemlich schnell rauf und auch wieder runter geht. Bin zuerst davon ausgegangen, dass es sich um einen stetigen Anstieg der numfiles handelt.

MfG,
Frank
 
Du könntest Dich mit "strace" (-> man strace) an den laufenden sshd (den Masterprozess) connecten und die Ausgaben in eine Datei schreiben lassen. So könntest Du die Hypothese untermauern, indem Du z.B. siehst, dass bei einer neuen Verbindung bestimmte Dateien (Libraries, Config-Files) oder Sockets nicht geöffnet werden können.
Achtung die Datei wird ziemlich schnell sehr groß und enthält sensible Informationen (u.U. Passworte oder andere Login-Credentials im Klartext).
 
Back
Top