ssh: Interaktive Programme lassen Session einfrieren

spirit

spirit

New Member
Hallo,

mein SSH-Server zeigt seit gestern ein so seltsames wie störendes Verhalten: bei der Nutzung von einigen (hauptsächlich interaktiven) Programmen (v.a. Editoren wie vim, vi, nano, aber auch oft bei einem 'apt-get update' oder einfach nur bei 'ps aux') scheint die Session einzufrieren. D.h. ich sehe z.B. die ersten 3 Prozesse der 'ps aux'-Ausgabe, aber nichts passiert danach mehr. Kein Cursor, nichts. Bei Editoren sehe ich das Editorfenster (im vim ja nicht all zu viel, aber man sieht durch die Zeileninfo unten, dass vim gestartet wurde) und eine leere Fläche, wo eigentlich der Dateiinhalt sein sollte. Es sieht aus, als wäre das ssh-Fenster ein Bildschirmfoto. Weder 'STRG+C' noch sonst irgendwas hilft, ich kann nur lokal das xterm, indem die ssh-Session clientseitig läuft, beenden und mich neu verbinden.

Hat jemand sowas schonmal beobachtet und 'nen Tipp parat, was man dagegen tut?

Ich habe einen vServer mit Debian Sarge bei S4Y und laut vzfree keinerlei RAM-Probleme. Logfiles sind alle ok (es laufen tripwire und logcheck und ich habe da ein Auge drauf). Ich habe den Server grade bereits erfolglos neugestartet und bin etwas irritiert über dieses Verhalten.
 
Bei interaktiven Sessions kann es einem passieren, dass man unbemerkt Strg-S drückt und damit den Ausgabe-Strom anhält (mit Strg-Q geht es dann weiter).
In Deinem Fall klingt das nicht ganz so wahrscheinlich (auch wenn es mit vi funktioniert).
Aber es könnte sein, dass bestimmte Zeichen nicht richtig übertragen werden (Stichwort: unterschiedliche Zeichenkodierungen, UTF8, etc) und daher vom lokalen Terminal als der Strg-S-Steuercode interpretiert werden. Probier mal aus, ob es mit Strg-Q weiter geht. Wenn ja, weißt Du, in welche Richtung Du suchen musst.

Viele Grüße,
LinuxAdmin
 
An sowas wie Kodierungen oder Terminalsettings hatte ich auch schon gedacht, nur weiss ich nicht genau, wo ich konkret nachsehen soll.

Aus Versehen STRG+S drücke ich nicht jedesmal, STRG+Q hilft leider nicht weiter. Dennoch danke für die Idee.

Anscheinend ist das Problem aber auch nicht auf SSH begrenzt. Wie ich grade gemerkt habe ist der Apache auf dem Server praktisch tot. Er zeigt zwar eine Seite an, das Klicken auf einen der Links führt jedoch zu nichts außer einer anscheinend unendlichen Ladezeit. Manche Dienste funktionieren allerdings wunderbar, z.B. der FTP-Server.

Der Server lief seit Monaten in der aktuellen Konfiguration und verbrauchte ungefähr 180 der mir zustehenden 256 MB RAM. Nach dem oben erwähnten Neustart habe ich einige Dienste nicht gestartet (ich lasse nicht alles automatisch starten), die zusammen über 100 MB benötigen, laut vzfree lag mein RAM-Verbrauch nach dem Neustart bei 50 MB.

Leider kann ich selbst 'cat /proc/user_beancounters' nicht ausführen, ohne das die Session stirbt. Hier mal eine Ausgabe, die sehr weit gekommen ist (die fehlenden Zeilen gibt's eben nicht, da war Ende). Nach sehr langer Zeit kommen dann auch SSH-Timeouts:

Code: 
root@srv:/home/user# cat /proc/user_beancounters
Version: 2.5
       uid  resource                     held              maxheld              barrier                limit              failcnt
   12345678: kmemsize                  3537626              6388432              8467453              9314198                    0
            lockedpages                     0                    0                  344                  344                    0
            privvmpages                 16509               120676               131072               139264                    1
            shmpages                      655                 1951                19567                19567                    0
            dummy                           0                    0                    0                    0                    0
            numproc                        33                   70                  128                  128               Read from remote host 12.34.56.78: Connection reset by peer

Dummerweise hindert mich das Problem daran, irgendwelche Logfiles zu lesen - ich kann sie weder mit cat, less/more noch mit einem Editor öffnen, da alle die Programme nicht funktionieren.

Ich werde jetzt das Rettungssystem booten und die Logs per scp kopieren, bin aber weiter für Tipps sehr offen.
 
Last edited by a moderator:
Du könntest Deine Versuche (cat UBC) auch mal innerhalb einer screen-Session machen. Dann siehst Du, ob es nur an der ssh-Übertragung liegt (klingt nach den Apache-Symptomen aber eher nicht danach), denn dann könntest Du nach dem erneuten Einloggen, Dich wieder mit der abgebrochenen Session verbinden und ggfs. sehen, dass es (bzw. nicht) weiter gegangen ist.

Ich würde mal stark sagen, dass das ein Fall für den Support ist.

Edit: Vorher solltest Du aber mit Sicherheit ausschließen können, dass es an Deiner Netzanbindung liegt. D.h. wenn es über den DSL-Anschluss eines Nachbarn/Freundes/Kollegen/Arbeit/etc. auch nicht funktioniert, hättest Du ein schlagendes Argument für den Support.
 
Last edited by a moderator:
So, ich habe mir die Logfiles über das Rescue-System beschafft. Ich kann darin auf den ersten Blick allerdings nichts Auffälliges finden.

Ich habe mir /proc/userbeancounters aus dem laufenden System (nicht Rescue natürlich) kopiert (das geht im Gegensatz zum 'cat'ten) und dann per SCP beschafft. Hier mal die Ausgabe:

Code: 
Version: 2.5
       uid  resource                     held              maxheld              barrier                limit              failcnt
   12345678: kmemsize                  3205805              3440275              8467453              9314198                    0
            lockedpages                     0                    0                  344                  344                    0
            privvmpages                 11395                11698               131072               139264                    0
            shmpages                      655                  671                19567                19567                    0
            dummy                           0                    0                    0                    0                    0
            numproc                        31                   35                  128                  128                    0
            physpages                    4955                 5019                    0  9223372036854775807                    0
            vmguarpages                     0                    0                65536  9223372036854775807                    0
            oomguarpages                 4956                 5019                65536  9223372036854775807                    0
            numtcpsock                     11                   11                  172                  172                    0
            numflock                        6                    8                  224                  246                    0
            numpty                          1                    1                   16                   16                    0
            numsiginfo                      0                    2                  512                  512                    0
            tcpsndbuf                  105480               105480              1416560              2768240                    0
            tcprcvbuf                  169552               169552              1416560              2768240                    0
            othersockbuf                 9376                17864               655717              1153621                    0
            dgramrcvbuf                     0                 8488               655717               655717                    0
            numothersock                   13                   16                  228                  228                    0
            dcachesize                 677322               695304              1503190              1548286                    0
            numfile                      1289                 1519                 3008                 3008                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            numiptent                      32                   32                   64                   64                    0

Ich habe noch ein paar Rechner, auf die ich SSH-Zugriff habe (an der Uni 'ne ganze Menge), und bei denen funktioniert alles. Freunde können von zu Hause aus auch nicht auf den Apache zugreifen. An meinem SSH-Client oder meiner Verbindung liegt das also nicht.

Habe dem Support geschrieben. Ich inspiziere mal weiter die Logs...

EDIT: Habe mal versucht, Sachen im screen auszuführen. Leider lässt sich damit das Problem nicht umschiffen. Auch im screen friert die Session komplett ein und man muss sich wieder komplett neu per SSH einloggen. Ziemlich anstrengend alles.
 
Last edited by a moderator:
spirit said:
Ich habe noch ein paar Rechner, auf die ich SSH-Zugriff habe (an der Uni 'ne ganze Menge), und bei denen funktioniert alles. Freunde können von zu Hause aus auch nicht auf den Apache zugreifen.
Click to expand...
Aha, da kommt der interessante Teil. Wenn es aus dem DFN immer funktioniert und über diverse ISPs nur sporadisch, wird wohl ein Fehler in einer der Anbindungen des Hosters zu vermuten sein. Du solltest mal checken, ob ping (von den verschiedenen Rechnern aus) während der Ausfälle Paketverluste anzeigt.
 
LinuxAdmin said:
Aha, da kommt der interessante Teil. Wenn es aus dem DFN immer funktioniert und über diverse ISPs nur sporadisch, wird wohl ein Fehler in einer der Anbindungen des Hosters zu vermuten sein. Du solltest mal checken, ob ping (von den verschiedenen Rechnern aus) während der Ausfälle Paketverluste anzeigt.
Click to expand...

Hm ne, so war das nicht gemeint, sorry. Der erste Teil sollte heißen, dass ich mich per SSH zu anderen Rechnern verbinden kann und die SSH-Session zu diesen Rechnern dann funktioniert - nicht, dass man von dort dann problemfrei auf den Apache zugreifen kann.
 
Also das Problem ist seit heute morgen wie von Geisterhand verschwunden. Ich werde das mal im Auge behalten.

Der Support hat mir trotz eindeutiger Problembeschreibung Standardmails mit Tipps dazu, wie man den UBC anzeigt, geschickt. Hatte ich auch nicht anders erwartet. :rolleyes:

Habe ein paar Mails mit denen ausgetauscht, aber da war von Anfang an klar, dass da nicht viel kommt. Auf meine eigentliche Frage, ob Probleme mit dem Server (Hardware oder evtl. Security-Probleme, deswegen hatte ich in dem anderen Thread nach der uptime-Geschichte gefragt) bekannt seien, wurde gar nicht eingegangen. Ob jemand von denen was gemacht hat weiss ich nicht sicher, kann es mir aber kaum vorstellen. Jedenfalls hat sich das Problem anscheinend (vorerst) erledigt und ich kann leider keine Tipps zur Lösung hier weitergeben.
 
You must log in or register to reply here.
Back
Top