sowas habe ich noch nicht erlebt, jedenfalls nicht unter Linux.
Unser Server ist ein aktuelles debian-queeze und er bedient seit Jahren 5 bis 6 windows und linux Clients, routed ins Internet, macht den DB-Server, den File-Server usw.
Am Sonntag gegen 14.00 Uhr war niemand an den Rechnern. Wie ich nachträglich recherchieren konnte, ist zu der Zeit das Telefon ausgefallen (seitens der Telekom) - möglicherweise dann auch DSL.
Jedenfalls begannen zu dem Zeitpunkt die Programme nacheinander auszusteigen und lassen sich seither nicht wieder starten.
Die letzten vernünftigen Meldungen z.B. von fetchmail lauten beispielsweise:
Feb 5 14:20:50 ottoserver fetchmail[8015]: Server certificate verification error: unable to get local issuer c
Feb 5 14:20:50 ottoserver fetchmail[8015]: This means that the root signing certificate (issued for /C=DE/ST=B
oder der INN:
SERVER cant exec in /usr/lib/news/bin/nnrpd Permission denied
oder wwwofled
Fatal: Cannot create spool directory /var/cache/wwwoffle [Permission denied]....failed.
Apache:
[error] [client 192.168.0.2] (13)Permission denied: access to /apache2-default/ denied
Usw usw. Der ganze init-prozess kommt nur unvollständig zustande.
Manche Programme starten, andere steigen ohne Fehlermeldung aus.
Samba z. B. startet, läuft auch, meckert aber auch über Verzeichnisse die angeblich nicht da sind z. B:
'/tmp' does not exist or permission denied when connecting to [IPC$] Error was Permission denied
Ich habe den Eindruck, das das Rechte - System völlig durcheinander ist, und überhaupt keine Ahnung, was jetzt noch zu machen wäre.
Letztes Backup ist vom 1. Februar. Sind aber tar.gz und machen wegen den hardlinks ne Menge Arbeit beim restore. Deshalb - vielleicht hat jemand von Euch einen Tip für mich.
> Letztes Backup ist vom 1. Februar. Sind aber tar.gz und machen wegen den
> hardlinks ne Menge Arbeit beim restore. Deshalb - vielleicht hat jemand
> von Euch einen Tip für mich.
Kuck dir das Ganze doch erstmal in Ruhe mit ner Live-DVD/Stick an, dann siehst du, was noch/nicht mehr da ist, wie die Rechte aussehen usw.
Am 2012-02-07, Theodor R"uthers <as...@gmx.de> schrieb:
> ist zu der Zeit das Telefon ausgefallen (seitens der Telekom) -
> möglicherweise dann auch DSL.
Und warum fielen diese Komponenten aus?
Richtig. Wegen eines Ueberspannungsschadens. Und dabei hat es Dir
auch die Technik Deines Servers zerlegt.
Ich wuerde mit Speicher- und Plattentests des Server beginnen. Dazu
ein Lebendig-Betriebssystem Linux von einer Kompaktscheibe starten,
nicht mehr versuchen, den Server anzufahren, weil Du nur mehr und
mehr (womoegliche) Spuren, die Dir helfen koennten, ruinierst.
> Letztes Backup ist vom 1. Februar. Sind aber tar.gz und machen
> wegen den hardlinks ne Menge Arbeit beim restore.
Bei dieser Gelegenheit ueberdenkst Du gleichzeitig Dein
DatensIcherungskonzept und schaffst etwas Vernuenftiges an. Und ja,
"rsync" existiert und hat maechtige Parameter mitgebracht.
Alle anderen Ueberlegungen erscheinen mir augenblicklich
Spekulationen zu sein.
> Am 2012-02-07, Theodor R"uthers<as...@gmx.de> schrieb:
>> ist zu der Zeit das Telefon ausgefallen (seitens der Telekom) -
>> möglicherweise dann auch DSL.
> Und warum fielen diese Komponenten aus?
Das wissen wir nicht!
> Richtig. Wegen eines Ueberspannungsschadens. Und dabei hat es Dir
> auch die Technik Deines Servers zerlegt.
Das ist erst mal nur eine Spekulation. ;-)
> Ich wuerde mit Speicher- und Plattentests des Server beginnen. Dazu
> ein Lebendig-Betriebssystem Linux von einer Kompaktscheibe starten,
> nicht mehr versuchen, den Server anzufahren, weil Du nur mehr und
> mehr (womoegliche) Spuren, die Dir helfen koennten, ruinierst.
Für mich sehen die Fehler wie massive Probleme mit den Partitionen
und/oder Festplatten aus. Da könnte einige Partition und/oder HDD
drunter defekt sein. Ein read-only-Test der Partitionen von einer
Live-CD wäre da erst mal angesagt. Da wirst der OP wahrscheinlich
fündig werden. Das läuft allerdings sehr schön konform mit Deiner
Spekulation.
> Für mich sehen die Fehler wie massive Probleme mit den Partitionen
> und/oder Festplatten aus. Da könnte einige Partition und/oder HDD
> drunter defekt sein.
Jo, hab ich auch erst mal vermutet.
> Ein read-only-Test der Partitionen von einer
> Live-CD wäre da erst mal angesagt.
Dann sprich bitte mal, wie genau. Ein fsck.ext3 über alle Partitionen mit Knoppix wirft keine Fehler aus.
> sowas habe ich noch nicht erlebt, jedenfalls nicht unter Linux.
>[...]
> Usw usw. Der ganze init-prozess kommt nur unvollständig zustande.
> Manche Programme starten, andere steigen ohne Fehlermeldung aus.
> Samba z. B. startet, läuft auch, meckert aber auch über > Verzeichnisse die angeblich nicht da sind z. B:
> '/tmp' does not exist or permission denied when connecting to [IPC$] > Error was Permission denied
Ja, gut - und? Ist die Platte voll (z. B. durch vollgelaufene Logs)?
Existiert /tmp? Welche Rechte sind da?
# ls -ld /tmp
drwxrwxrwt 34 root root 4096 Feb 7 13:02 /tmp
> Ich habe den Eindruck, das das Rechte - System völlig durcheinander > ist, und überhaupt keine Ahnung, was jetzt noch zu machen wäre.
Nachgucken, ob vielleicht die ein oder andere Meldung doch ihre
Berechtigung hat ('/tmp' does not exist).
> Letztes Backup ist vom 1. Februar. Sind aber tar.gz und machen wegen > den hardlinks ne Menge Arbeit beim restore. Deshalb - vielleicht > hat jemand von Euch einen Tip für mich.
Wieso machen tarfiles wegen Hardlinks Probleme? Und wieso werden sie
dann trotzdem verwendet?
>> Für mich sehen die Fehler wie massive Probleme mit den Partitionen
>> und/oder Festplatten aus. Da könnte einige Partition und/oder HDD
>> drunter defekt sein.
> Jo, hab ich auch erst mal vermutet.
>> Ein read-only-Test der Partitionen von einer
>> Live-CD wäre da erst mal angesagt.
> Dann sprich bitte mal, wie genau. Ein fsck.ext3 über alle Partitionen
> mit Knoppix wirft keine Fehler aus.
Äh *stammel* *glaskugelpolier* Optionen read only (-n) und force (-f)?
Am 2012-02-07, Theodor R"uthers <as...@gmx.de> schrieb:
> Am 7.2.2012 12:39, schrieb Uwe Borchert:
>> Ein read-only-Test der Partitionen von einer Live-CD wäre da erst
>> mal angesagt.
> Dann sprich bitte mal, wie genau. Ein fsck.ext3 über alle
> Partitionen mit Knoppix wirft keine Fehler aus.
Wie hast Du denn fsck.ext3 aufgerufen? Ich hoffe fuer Dich, dasz Du
das Dateisystem zunaechst NUR LESEND anfaszt. Mit einem Filecheck
drauf zugreifen, wenn die darunter physische Platte Defekte hat,
kann das Ende jeglichen Datenzugriffes sein.
Platten prueft man zunaechst mit
badblocks -v /dev/sdX
Bitte das X entsprechend richtig setzen. Kann es sein, dasz Du bei
der von mir vermuteten Sensibilitaet der Daten einen Fachmann an die
Sache lassen solltest?
Am 2012-02-07, Uwe Borchert <wetterfro...@yahoo.com> schrieb:
> Am 07.02.2012 11:56, schrieb Peter Blancke:
> Das ist erst mal nur eine Spekulation. ;-)
Nun, nichts sonst. Was auch sonst? Hier existiert keine Glaskugel.
> Für mich sehen die Fehler wie massive Probleme mit den Partitionen
> und/oder Festplatten aus.
Fuer mich auch. Bis hin zu locker sitzenden Kabeln und was nicht
mehr.
Darum wird dem Problembehafteten ja nun auch vermehrt empfohlen,
zunaechst die Hardware zu untersuchen und nicht auch noch mit
Filesystemchecks auf die Daten zuzugreifen und diese womoeglich noch
zu veraendern.
> Existiert /tmp? Welche Rechte sind da?
> # ls -ld /tmp
> drwxrwxrwt 34 root root 4096 Feb 7 13:02 /tmp
Na klar:
# ls -ld /tmp
drwxrwxrwt 6 root root 4096 7. Feb 13:31 /tmp
> Nachgucken, ob vielleicht die ein oder andere Meldung doch ihre
> Berechtigung hat ('/tmp' does not exist).
Da sollte nur ein Beispiel dafür sein, das manche Programme ihre angestammten Verzeichnisse nicht erreichen können.
Noch schärfer wird es wenn ich zum Testen ein neues Programm installiere. Also apt-get install irgendwas.
Dann hat das irgendwas nicht einmal Rechte auf
/etc/irgendwas/irgendwas.conf
Da kommt sofort: permission denied
irgendwas Auffälliges, wie z. B. "readonly = 1"? Auch ein
for DAT in a1 a5 a6 b5 b6 c5 c6; do mount /dev/sd$DAT -o rw,remount; done
funktioniert, so dass keine Filesysteme mehr readonly gemountet sind?
>> Existiert /tmp? Welche Rechte sind da?
>> # ls -ld /tmp
>> drwxrwxrwt 34 root root 4096 Feb 7 13:02 /tmp
> Na klar:
> # ls -ld /tmp
> drwxrwxrwt 6 root root 4096 7. Feb 13:31 /tmp
Beruhigend :-)
>> Nachgucken, ob vielleicht die ein oder andere Meldung doch ihre
>> Berechtigung hat ('/tmp' does not exist).
> Da sollte nur ein Beispiel dafür sein, das manche Programme ihre > angestammten Verzeichnisse nicht erreichen können.
Dachte ich mir fast. Du kannst also allen Fehlermeldungen nachgehen, um
zu sehen, welche Berechtigungen die Dateien/Verzeichnisse haben :-P
> Noch schärfer wird es wenn ich zum Testen ein neues Programm > installiere. Also apt-get install irgendwas.
> Dann hat das irgendwas nicht einmal Rechte auf
> /etc/irgendwas/irgendwas.conf
> Da kommt sofort: permission denied
Von wem? Beim Installationsversuch? Du willst jetzt sagen, dass Du auf
ein kaputtes System noch etwas draufinstallierst? Mutig!
Bei uns ist Sonntag ein Nagios-Server ausgestiegen - hat nach
Herzenslust Fehler generiert, SMS geschickt, 15 Minuten später alles OK,
wieder SMS usw. Konnte nur durch Serverneustart behoben werden (init 6).
Der Service konnte nicht neu gestartet werden, weil der User nagios
angeblich nicht existierte... Zum Glück hat die Kiste ein eingebautes
KVM, denn das Netz war auch tot (kein Mailversand, kein ssh-Login). Nach
dem Reboot war alles in bester Ordnung.
> for DAT in a1 a5 a6 b5 b6 c5 c6; do mount /dev/sd$DAT -o rw,remount; done
> funktioniert, so dass keine Filesysteme mehr readonly gemountet sind?
In einigen Stunden. Gerade läuft zum zweiten mal ein Badblock-Test
Sieht aber nicht nach Fehlern aus.
>> Noch schärfer wird es wenn ich zum Testen ein neues Programm
>> installiere. Also apt-get install irgendwas.
>> Dann hat das irgendwas nicht einmal Rechte auf
>> /etc/irgendwas/irgendwas.conf
>> Da kommt sofort: permission denied
> Von wem? Beim Installationsversuch?
Das ist kein Versuch, das Programm wird fehlerfrei installiert.
Das ist alles völlig Problemlos. Nur starten, das tuts nicht.
> Du willst jetzt sagen, dass Du auf
> ein kaputtes System noch etwas draufinstallierst? Mutig!
Wieso nicht, spätestens morgen früh wird neu installiert. Wenn ich den Fehler nicht bis dahin gefunden habe. Alle wichtigen Daten, die Datenbank und die Homverzeichnisse der User sind gesichert.
Ein Server ohne X ist ratzfatz installiert. Mich wurmt nur, das ich den Fehler nicht finde. Wie ich schon schrieb, seit 1995 mit Linux unterwegs, aber das habe ich noch nicht erlebt.
Und hier liegt bestimmt kein Hardware-Fehler vor. Den hätte ich längst gefunden.
Am 2012-02-07, Theodor R"uthers <as...@gmx.de> schrieb:
> spätestens morgen früh wird neu installiert. Wenn ich den Fehler
> nicht bis dahin gefunden habe.
Hmmm... Ist doch ein Linuxsystem.
> Ein Server ohne X ist ratzfatz installiert.
Das ist voellig richtig. Und trotzdem wuerde ich, sofern Du
Plattenplatz hast, vorweg ein Abbild des verkorksten Systems machen
und beizeiten dort forensisch nachsteigen, respektive dann, wenn die
derzeitige Platte problemlos auslesbar ist.
Angriffsszenarien koennen vielschichtig sein und sie nicht erkannt
zu haben, koennte beizeiten gleiche/aehnliche Probleme auf den Plan
rufen.
> Und hier liegt bestimmt kein Hardware-Fehler vor. Den hätte ich
> längst gefunden.
Thermische Probleme koennten ebenfalls die Probleme der Platten
verursachen. Ich rate dazu, fuer das kommende System zusaetzlich
lm-sensors und evt. Munin oder Konsorten zu installieren, auch
liefert smartctl hier passende Informationen.
"Neuinstallieren und die Probleme sind weg" waere fuer mich
persoenlich voellig unbefriedigend.
Wenn auch das nicht hilft (die Verzeichnisse müssen/sollten "root:root"
gehören und 755 als Rechte haben): dann könnte die Platte einen
gewaltigen Hau haben;
Knoppix-CD,
badblocks -nsv -b65536 -c16384 /dev/sdx
(o.ä.). Die Kiste ist dann eine Weile beschäftigt ...
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
> Am 2012-02-07, Theodor R"uthers<as...@gmx.de> schrieb:
>> Am 7.2.2012 12:39, schrieb Uwe Borchert:
>>> Ein read-only-Test der Partitionen von einer Live-CD wäre da erst
>>> mal angesagt.
>> Dann sprich bitte mal, wie genau. Ein fsck.ext3 über alle
>> Partitionen mit Knoppix wirft keine Fehler aus.
> Wie hast Du denn fsck.ext3 aufgerufen? Ich hoffe fuer Dich, dasz Du
> das Dateisystem zunaechst NUR LESEND anfaszt. Mit einem Filecheck
> drauf zugreifen, wenn die darunter physische Platte Defekte hat,
> kann das Ende jeglichen Datenzugriffes sein.
Ich habe ja extra darauf hingewiesen. Die Option sollte -n sein.
Ich bin mir aber nicht sicher ob das eine oder andere System diese
Option als Default aufweisen könnte. Daher immer explizit anknipsen.
> Platten prueft man zunaechst mit
> badblocks -v /dev/sdX
> Bitte das X entsprechend richtig setzen.
Das würde ich aber erst als zweiten Schritt anwenden. Nach meinen
bisherigen Erfahrungen waren es fast immer Probleme mit kaputten
Dateisystemen. Man sollte aber beide Tests fahren? Die Reihenfolge
ist aber IMHO Geschmackssache und bei fsck vor badblocks hatte ich
(in meinen Fällen!) immer schneller den Fehler raus. badblocks
lief da bei mir fast immer ohne Maulen und Mosern dann am Ende
(teilweise über Nacht) durch, so ich es nicht unterlassen habe.
PS: Vollgelaufenes /tmp könnte übrigens auch sein. Oder aber
verdrehte Rechte auf /tmp
drwxrwxrwt 8 root root 20480 7. Feb 17:03 tmp
Falls das nicht so da steht: chmod 1777 /tmp sollte helfen? IIRC
kann tar beim Entpacken von / (z.B. von einem alten Systemabbild zur
Wiederherstellung) in einem Verzeichnis da die Rechte verbiegen.
>> Ja Hallo aber auch - das ist es vielleicht:
>> drwxrwx--- 22 theo users 4096 6. Feb 18:55
> So etwas habe auch ich (versehentlich) erreicht, indem ich einen Tarball
> mit diesen Verzeichnis-Rechten drüber-entpackte.
Genau danach wollte ich Theodor fragen: Hast Du einen Tarball mit
diesen Rechten direkt in / entpackt? Mir ist dies in /tmp passiert.
Das war ein Systemabbild als Tarball mit den handelsüblichen Rechten
von / und root. Danach waren die User weg vom X und ihren Anwendungen.
> Noch schärfer wird es wenn ich zum Testen ein neues Programm > installiere. Also apt-get install irgendwas.
Auf eine kaputte Platte / ein kaputtes Dateisystem installieren ist schon
recht wagemutig...
> Dann hat das irgendwas nicht einmal Rechte auf
> /etc/irgendwas/irgendwas.conf
> Da kommt sofort: permission denied
Hast Du mal nachgesehen, was "/" für Rechte hat? (ls -ld /)
Ein Bekannter hat da schon zweimal das Problem gehabt, daß dem das "d"
entfallen war, womit natürlich alles, was nicht root war, keinen Zugriff
mehr fand. Natürlich waren keine Logins möglich, niemand außer root konnte
irgendwelche Dateien finden u.s.w.
Wie das zustande kommen konnte, war nie zu eruieren...
-- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
> > Thermische Probleme koennten ebenfalls die Probleme der Platten
> > verursachen.
> Im Moment bestimmt nicht. Unbeheizter Serverraum.
Kommt auf die aktuelle Temperatur an - Platten gehen nicht nur durch
Überhitzung kaputt, sie verkraften auch keine Unterkühlung. Schließlich
sind das schnelllaufende Motoren, die geschmiert werden wollen, und wenn's
zu kalt wird, schmiert sich nix mehr -> Lagerschaden. Vorher wird aber wohl
schon das Motörchen überlastet - viel an Reserven haben die ja nicht - und
damit passen die Bits nicht mehr in die Abtastelektronik (Fehlanpassung der
Zeitkonstanten). Die 0 "bad blocks" sprechen da zwar etwas dagegen, aber
badblocks ist eher wenig zimperlich und probiert schon recht extensiv,
wenn ein Fehler auftritt, bevor es aufgibt und den auch meldet.
-- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
> Apache:
> [error] [client 192.168.0.2] (13)Permission denied: access to
> /apache2-default/ denied
> '/tmp' does not exist or permission denied when connecting to [IPC$]
> Error was Permission denied
Was ist denn mit den fraglichen Verzeichnissen und ihren Rechten? Ist das alles auf einem einzigen Volume? Hat da möglicherweise das Dateisystem in Teilen die Grätsche gemacht und/oder sind (wenn auch schlecht erklärlich) Mountoptionen durcheinander geraten (siehe /proc/mounts)? Grundsätzlich ist strace Dein Freund, um das Problem einzugrenzen.
>> So etwas habe auch ich (versehentlich) erreicht, indem ich einen Tarball
>> mit diesen Verzeichnis-Rechten drüber-entpackte.
> Genau danach wollte ich Theodor fragen: Hast Du einen Tarball mit
> diesen Rechten direkt in / entpackt? Mir ist dies in /tmp passiert.
Leute, ich war nicht am Rechner, als die Probleme auftraten. Das schrieb ich schon im OP. Ich habe alles erst Stunden später aus den log-files herausgelesen. Ich habe auch nichts entpackt, oder sonstwie am Rechner gemacht.
Wenn ich die Zeit finde werde ich aber versuchen den Fehler zu reproduzieren.
