Wird die Platte bald abrauchen?

[anmu]

Hallo,
vorhin hat sich mein Rootserver bei 1&1 aufgehängt. Beim Aufruf von Webseiten kamen Meldungen a la "File system mountet read only". Ich habe den Server dann schon mit Grummeln im Magen rebootet und er kam natürlich nicht hoch.
Also Rescue-System gebootet, Platte gemountet und fsck.ext durchgeführt (-pyf).

Zuvor hatte ich allerdings einmal smartctl -a /dev/hda ausgeführt. Es gab dazu mal einen guten ct-Artikel, den ich leider nicht wiederfinde. Was sagt Ihr zu der Ausgabe? Die Platte ist von 2002...

Code: Select all

rescue:/mnt/backup# smartctl -a /dev/hda
smartctl version 5.30 Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model:     IC35L040AVVN07-0
Serial Number:    VNP214B2SG6Y7D
Firmware Version: VA2OAG0A
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   5
ATA Standard is:  ATA/ATAPI-5 T13 1321D revision 1
Local Time is:    Thu Jan 12 09:50:24 2006 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity was
                                        never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                 (1177) seconds.
Offline data collection
capabilities:                    (0x1b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        No Conveyance Self-test supported.
                                        No Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        No General Purpose Logging support.
Short self-test routine
recommended polling time:        (   1) minutes.
Extended self-test routine
recommended polling time:        (  20) minutes.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   096   096   060    Pre-fail  Always       -       393218
  2 Throughput_Performance  0x0005   100   100   050    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0007   100   100   024    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       4
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       3
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   100   100   020    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0012   097   097   000    Old_age   Always       -       25524
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       4
192 Power-Off_Retract_Count 0x0032   100   100   050    Old_age   Always       -       1068
193 Load_Cycle_Count        0x0012   100   100   050    Old_age   Always       -       1068
194 Temperature_Celsius     0x0002   253   253   000    Old_age   Always       -       16 (Lifetime Min/Max 15/29)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       3
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

Viele Grüße,
Andreas

[eisbärmann]

Hi Andreas,

was sagt

Code: Select all

smartctl -t long /dev/hda

oder

Code: Select all

smartctl -q errorsonly -H -l selftest /dev/hda

Sind nur die Beispiele aus der man-page.
Sorry, hab aber gerade keine Linux-Kiste zur Hand.

Die smarttools haben bei mir eigentlich immer ganz gute Dienste geleistet, aber wenn eine Platte mal am Abrauchen ist, dann sagen Dir diverse Kernel-Messages mehr aus.

Ganz andere Frage:

Hast Du mal in den Systemlogs überprüft, wieso Deine Partition für die Webdaten auf "read-only" war?

Unter welcher Partition liegen denn Deine Webdaten? Existiert eine quota?
Und hast Du das System zuvor mal rebootet?

Derartige Probleme stammen oftmals von einer fehlerhaften Quota Datei.
Wenn beim Booten die Quota-Dateien überprüft werden und ein Fehler festgestellt wird, dann wird die Partition ro gemounted.

Da hilft dann nur ein umount und ein quota-check.

[anmu]

Hi Eisbärmann,

was sagt

Code: Select all

smartctl -t long /dev/hda

oder

Code: Select all

smartctl -q errorsonly -H -l selftest /dev/hda

Das kann ich leider erst später ausprobieren.

Die smarttools haben bei mir eigentlich immer ganz gute Dienste geleistet, aber wenn eine Platte mal am Abrauchen ist, dann sagen Dir diverse Kernel-Messages mehr aus.

Hast Du mal in den Systemlogs überprüft, wieso Deine Partition für die Webdaten auf "read-only" war?

Das war das erste, was ich gemacht habe, habe aber leider nichts gefunden. Um 2:00 Uhr ist noch ein Backup gelaufen (bis 2:01, das war das kleine - cool, 5 Minuten vor dem Absturz noch ein Backup :) ). Um 2:05 wurden noch Emails abgeholt, um 2:06 Uhr kam noch eine Email und es erfolgten Webserverzugriffe, danach nichts mehr in message, mail, warn, Apache-Logs...

Unter welcher Partition liegen denn Deine Webdaten? Existiert eine quota?

Es sind 23% der Datenpartition (hda3) benutzt, eine Quota gibts nicht.

Und hast Du das System zuvor mal rebootet?

Ja. Nach den Fehlermeldungen habe ich ein Reboot durch 1&1-System durchgeführt. Ich kam per ssh nicht mehr rauf.
Als der Server dann nach 15 Minuten immer noch nicht oben war, habe ich das Rescue-System gebootet.

Derartige Probleme stammen oftmals von einer fehlerhaften Quota Datei.
Wenn beim Booten die Quota-Dateien überprüft werden und ein Fehler festgestellt wird, dann wird die Partition ro gemounted.
Da hilft dann nur ein umount und ein quota-check.

Hier die /etc/mtab:

Code: Select all

/dev/hda3 / ext3 rw,usrquota 0 0
proc /proc proc rw 0 0
devpts /dev/pts devpts rw,mode=0620,gid=5 0 0
/dev/hda1 /boot ext3 rw 0 0
shmfs /dev/shm shm rw 0 0

Das interessante war ja, dass er offensichtlich im normalen Betrieb auf ro umgeschaltet hat.

Viele Grüße,
Andreas

[eisbärmann]

Sorry, aber

Es sind 23% der Datenpartition (hda3) benutzt, eine Quota gibts nicht.

beist sich mit

Code: Select all

/dev/hda3 / ext3 rw,usrquota 0 0

Demnach müsste in / eine Datei (a)quota.user liegen.

Das mit der Quota war nur so eine Vermutung, da ich es schon einige male live erlebt habe.

Von einem "spontan" re-mount habe ich allerdings noch nichts gehört.

Wenn keine Einträge in den Logs mehr zu finden sind, dann muss allerdings was mit dem System passiert sein.

Gibt es in der Ausgabe von last etwas auffälliges? Einträge ohne reboot oder ähnlichem?

Ein mögliches Szenario wäre, dass ein Techniker im RZ über das Netzkabel gestolpert ist :lol:

Scherz bei Seite:

Wenn der Strom weg war und die Kiste neu gebootet hat, dann kann man sich den fehler so erklären:
Beim fs-check kam es zu einem Fehler zum "ro"
oder
die Quotafile war beschädigt und daher das "ro".

Ich weiss, ich weiss, ich bin quota geschädigt :roll:

[anmu]

Sorry, aber

Es sind 23% der Datenpartition (hda3) benutzt, eine Quota gibts nicht.

beist sich mit

Code: Select all

/dev/hda3 / ext3 rw,usrquota 0 0

Demnach müsste in / eine Datei (a)quota.user liegen.

Das mit der Quota war nur so eine Vermutung, da ich es schon einige male live erlebt habe.

Okay! Das muß noch vom alten Confixx übrig sein, dass ich eiegntlich nie benutzt habe. Eine quota.user-Datei gibt es. Ein
repquota /dev/hda3
ergibt auch die Ausgabe einiger User, aber fast nur Systemuser, root und 1-2 Testuser von damals. Allerdings stehen in allen Spalten von hard- und soft-limit eine 0. Beispiel:

Code: Select all

*** Report for user quotas on device /dev/hda3
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      --  513212       0       0          35214     0     0
...

Demnach dürfte es das eigentlich nicht gewesen sein, oder?

Von einem "spontan" re-mount habe ich allerdings noch nichts gehört.

Wenn keine Einträge in den Logs mehr zu finden sind, dann muss allerdings was mit dem System passiert sein.

Gibt es in der Ausgabe von last etwas auffälliges? Einträge ohne reboot oder ähnlichem?

Ein mögliches Szenario wäre, dass ein Techniker im RZ über das Netzkabel gestolpert ist :lol:

In "last" gibts nichts besonderes.
Wenn der Rechner rebootet wurde und mit ro hochkam, warum kam er dann nicht wieder mit ro hoch als ich ihn neu startetet? Und warum liefen die Dienste (apache + named haben zumindest Anfragen beantwortet)?

Viele Grüße,
Andreas

[eisbärmann]

Wenn der Rechner rebootet wurde und mit ro hochkam, warum kam er dann nicht wieder mit ro hoch als ich ihn neu startetet? Und warum liefen die Dienste (apache + named haben zumindest Anfragen beantwortet)?

Stecker ziehen ist kein "reboot" :lol:
Das mit den Diensten ist so eine Sache. Aber Du hast Recht, die Dienste hätten dann aber auch keine PIDs usw. speichern können.

Wenn Du die Quota nicht nutzt, dann wirf sie aus der fstab und schau nach, ob in irgendeinem runlevel die Quota gestartet wird - gg. entfernen.

Ich glaube dennoch nicht, dass es an der Platte liegt.

Andere Scherze wie Rootkit oder Cracker kannst Du ausschließen?

[anmu]

Wenn Du die Quota nicht nutzt, dann wirf sie aus der fstab und schau nach, ob in irgendeinem runlevel die Quota gestartet wird - gg. entfernen.

Das ist soeben erledigt.

Ich glaube dennoch nicht, dass es an der Platte liegt.

Andere Scherze wie Rootkit oder Cracker kannst Du ausschließen?

Warum nicht die Platte?

Rootkit kann man natürlich nie ausschließen. Aber ich überprüfe die Kiste mit täglichen Emails sehr genau. Ich bekomme alle untypischen Meldungen in /message + mail jeden Tag zugemailt, außerdem freien Plattenplatz, letzten Logins, Fehlermeldungen des Apache etc. Und stündlich den Traffic, wo es dann ab 300 MB auch noch eine SMS gibt.

Da der Server von 2002/2003 ist, kann natürlich noch veraltete Software drauf sein. Sicherheitshalber ist vorhin erstmal ein neuer Rechner bestellt. Die haben standardmäßig ja inzwischen ein RAID-System.

Viele Grüße,
Andreas

[isotopp]

Von einem "spontan" re-mount habe ich allerdings noch nichts gehört.

ext2 enthält Code, der das Dateisystem als r/o remounted, wenn bestimmte Fehler im ext2-Code auftreten. In der man-Page zu mount(8) ist dies unter "Mount Options for ext2" als mit der "errors="-Option einstellbar dokumentiert. Der Default kann mit dumpe2fs abgefragt werden ("Errors behavior").

[eisbärmann]

...In der man-Page zu mount(8 ) ist dies unter "Mount Options for ext2" als mit der "errors="-Option einstellbar dokumentiert...

Stimmt, allerdings hatte ich bisher nur die Erfahrung gemacht, dass die Option auf "continue" gesetzt war.

Bei einem System mit zwei Partitionen finde ich die Option "remount-ro" allerdings sehr problematisch, da wie hier gesehen kein Dienst mehr korrekt arbeiten kann.

Somit scheint es doch ein Problem mir der Platte gegeben zu haben.
Die genaue Ursache des Fehlers lässt sich dann allerdings ohne Log-Files(konnten ja dann auch nicht geschrieben werden) nicht mehr bestimmen.

Das ist einer der Gründe, warum ich es für besser halte, wichtige Bereiche eines Dateisystems auf verschiedene Partitionen aufzusplitten.

Ja, ich weiß - darüber wurden bereits Glaubenskriege geführt :lol:

[isotopp]

Somit scheint es doch ein Problem mir der Platte gegeben zu haben.
Die genaue Ursache des Fehlers lässt sich dann allerdings ohne Log-Files(konnten ja dann auch nicht geschrieben werden) nicht mehr bestimmen.

Code: Select all

# dmesg

Das fischt Dir stattdessen die Kernelbuffers bevor sie geschrieben werden.

[lord_pinhead]

Ja, ich weiß - darüber wurden bereits Glaubenskriege geführt :lol:

Wenn jemand dein FTP knackt und die sollange Dateien auf die Platte schiebt bis sie voll ist, dann funktioniert auch kein Dienst mehr ;) Deshalb werden Userpartitionen einfach extra gelegt, wenn die dann voll geladen wird laufen die Dienste noch weiter. Einfacher Grund würde ich sagen :)