Login auf entferntem Rechner nicht mehr möglich

[hupfdule]

Hallo,

ich bin mir nicht sicher, ob das die richtige Sektion ist und ob der Titel geschickt gewählt ist. Ich habe folgendes Problem. Ich habe bei Hetzner einen Root-Server gemietet. Auf diesem kann ich mich leider nicht mehr per ssh einloggen. Das an sich ist natürlich schon ein Problem, schlimmer aber ist wohl, dass ich keine Ahnung hab, warum das nicht geht. Die letzte Aktion, der ich mir bewusst bin, ist, dass ich den mailserver (exim) dort eingerichtet habe. Dieser funktioniert auch nicht mehr, da liegt die Vermutung nahe, dass er das Problem ist.

Mich würde nun natürlich sehr interessieren, was das genaue Problem wäre, habe da aber keine Idee, wie ich vorgehen könnte. Vlt. kann mir ja jemand hier aus dem Forum helfen.
Das sind die Fehlermeldungen, die einzelne daemons mir geben:

ssh mit debug-ausgabe:

Code: Alles auswählen

OpenSSH_3.6.1p2 Debian 1:3.6.1p2-2, SSH protocols 1.5/2.0, OpenSSL 0x0090702f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug2: ssh_connect: needpriv 0
debug1: Connecting to sout.de [213.133.110.15] port 22.
debug1: Connection established.
debug1: identity file /home/marco/.ssh/identity type -1
debug1: identity file /home/marco/.ssh/id_rsa type -1
debug1: identity file /home/marco/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.4p1 Debian 1:3.4p1-1
debug1: match: OpenSSH_3.4p1 Debian 1:3.4p1-1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2 Debian 1:3.6.1p2-2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

Danach bleibt die Verbindung stehen, bis der Client aufgibt.

telnet auf Port 25:

Code: Alles auswählen

421 Unexpected log failure, please try later

Ein php-Skript auf diesem Rechner aufgerufen:

Code: Alles auswählen

Warning: PrivoxyWindowOpen(/tmp/sess_298788556bb4b6e177d02149ca7a692b, O_RDWR) failed: Read-only file system (30) in /var/www/eskf.de/html/includes/functions/sessions.php on line 67
3 - Error writing file '/var/log/mysql.log' (Errcode: 30)

delete from whos_online where time_last_click < '1057071823'

[TEP STOP]

Hat jemand eine Idee, woran das liegen kann? Es macht fast den EIndruck als wäre die Platte überfüllt (es gibt nur eine einzige Partition). Nur hab ich keine Idee, wodurch das passiert sein soll. Es sind 60GB, die werden doch so schnell nicht mit logs vollgeschrieben...

[Olaf Dietsche]

Ein php-Skript auf diesem Rechner aufgerufen:

Code: Alles auswählen

Warning: PrivoxyWindowOpen(/tmp/sess_298788556bb4b6e177d02149ca7a692b, O_RDWR) failed: Read-only file system (30) in /var/www/eskf.de/html/includes/functions/sessions.php on line 67
3 - Error writing file '/var/log/mysql.log' (Errcode: 30)

delete from whos_online where time_last_click < '1057071823'

[TEP STOP]

Hat jemand eine Idee, woran das liegen kann? Es macht fast den EIndruck als wäre die Platte überfüllt (es gibt nur eine einzige Partition). Nur hab ich keine Idee, wodurch das passiert sein soll. Es sind 60GB, die werden doch so schnell nicht mit logs vollgeschrieben...

Das Dateisystem ist readonly gemountet, deswegen kann nichts mehr geschrieben werden. Daran kann man sehen, daß es sinnvoll sein kann, mehrere unabhängige Partitionen einzurichten. Wobei es natürlich auf den Auslöser für dieses readonly mounten ankommt.

Vielleicht kann im http://www.rootforum.de jemand mehr dazu sagen.

[pdreker]

Wahrscheinlich eine "platte Platte"

Patrick

[hupfdule]

Ja, den Eindruck habe ich mittlerweile auch. Es scheint so, dass ich die debug-option bei exim nicht mehr entfernt hab. Ist es denn möglich, dass mir exim, obwohl maximal ein paar mails pro tag eingehen, jetzt ca. 60 GB an Logfiles erstellt hat? Naja, ich hab das debug-level 9 eingestellt....

Und wichtiger, wie komm ich jetzt per ssh auf den rechner? Ich hab mir gedacht, dass logrotate ja jeden Tag um 6:25 (laut /etc/crontab) die älteren logfiles löscht. Da werden zwar die exim-logfiles nicht dabei sein, aber irgendwas anderes müsste ja dann weg kommen. Lieg ich da richtig, dass ich dann etwa um diese Zeit die Chance haben könnte mich per ssh wieder einzuloggen, da ja dann temporärer Speicher für ssh bereit steht.

[Olaf Dietsche]

Ja, den Eindruck habe ich mittlerweile auch. Es scheint so, dass ich die debug-option bei exim nicht mehr entfernt hab. Ist es denn möglich, dass mir exim, obwohl maximal ein paar mails pro tag eingehen, jetzt ca. 60 GB an Logfiles erstellt hat? Naja, ich hab das debug-level 9 eingestellt....

Ich kenne exim nicht, aber um 60 GB voll zu bekommen, muß er schon sehr viel schreiben.

Und wichtiger, wie komm ich jetzt per ssh auf den rechner? Ich hab mir gedacht, dass logrotate ja jeden Tag um 6:25 (laut /etc/crontab) die älteren logfiles löscht. Da werden zwar die exim-logfiles nicht dabei sein, aber irgendwas anderes müsste ja dann weg kommen. Lieg ich da richtig, dass ich dann etwa um diese Zeit die Chance haben könnte mich per ssh wieder einzuloggen, da ja dann temporärer Speicher für ssh bereit steht.

Wenn eine volle Platte die Ursache ist, ja. Aber wenn die Platte readonly gemountet ist, dann kann auch logrotate nicht schreiben bzw. löschen.

[pdreker]

Eine volle Platte ist mit Sicherheit nicht das Problem. Es sind immer 5% Platz für root reserviert (Falls Du root bist ), damit der sich auch im Notfall einloggen kann. Wenn das System die Platte auf read-only geschaltet hat, dann macht es das nur, weil ein nicht behebbarer Fehler beim Zugriff aufgetreten ist, um Inkonsistenzen zu vermeiden. Eine volle Platte fällt nicht in diese Kategorie...

Entweder hatte die Platte einen Schluckauf (vorübergehender Fehler), oder sie stirbt gerade. Ich würde die Platte ersetzen (lassen), bevor echter Datenverlust eintritt.

Das klingt echt nach einem Fall für den Support... (Du hast doch Backups?)

Patrick

[hupfdule]

Ein harter reboot vom Rechenzentrum hat geholfen. Der Rechner läuft wieder und ich kann mich einloggen.
Ein Blick in /var/log/messages brachte dann mehr Aufschluss:

Code: Alles auswählen

Jun 30 13:01:13 pendrageon kernel: hda: timeout waiting for DMA
Jun 30 13:01:13 pendrageon kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14
Jun 30 13:01:13 pendrageon kernel: hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
Jun 30 13:01:13 pendrageon kernel: hda: drive not ready for command

Sieht echt nach einem Aussetzer der Platte aus. Ich werde sie austauschen lassen.