[Gelöst] Unmotivierte Systemabstürze (CentOS)

gehrke · 7 Juni 2016

marce schrieb:
Code:

mdadm -Asv | more

geht nicht?

Nein, ging nicht.
Für alles weitere ist es zu spät - habe mittlerweile die Büchse gebootet.

Auf den ersten Blick scheint alles zu tun (ssh, Dateisysteme, wiki, kvm, nfs). Genau wie beim letzten Mal.

Code:

[root@j4 ~]# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] [raid1] 
md0 : active raid1 sdb1[1] sda1[0]
      199668 blocks super 1.0 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md127 : active (auto-read-only) raid1 sde2[0] sdf2[1]
      899700415 blocks super 1.2 [2/2] [UU]
        resync=PENDING
      
md1 : active raid6 sda2[4] sdd1[7] sdb2[1] sdc1[2] sde1[6] sdf1[8]
      11720260608 blocks super 1.0 level 6, 128k chunk, algorithm 2 [6/6] [UUUUUU]
      bitmap: 1/11 pages [4KB], 131072KB chunk
      
unused devices: <none>

md127 kann tatsächlich ignoriert werden, ist nur für Tests.

Code:

[root@j4 ~]# lsblk
NAME                                                   MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sdc                                                      8:32   0   2,7T  0 disk  
└─sdc1                                                   8:33   0   2,7T  0 part  
  └─md1                                                  9:1    0  10,9T  0 raid6 
    └─luks-bc648035-bdf2-4627-8042-bb58e0602e16 (dm-0) 253:0    0  10,9T  0 crypt 
      ├─system-os2 (dm-1)                              253:1    0    15G  0 lvm   /
      ├─system-swap (dm-2)                             253:2    0     4G  0 lvm   [SWAP]
      ├─system-home (dm-3)                             253:3    0  10,9T  0 lvm   /home
      └─system-vm (dm-4)                               253:4    0  27,4G  0 lvm   /vm
sdb                                                      8:16   0   2,7T  0 disk  
├─sdb1                                                   8:17   0   195M  0 part  
│ └─md0                                                  9:0    0   195M  0 raid1 /boot
└─sdb2                                                   8:18   0   2,7T  0 part  
  └─md1                                                  9:1    0  10,9T  0 raid6 
    └─luks-bc648035-bdf2-4627-8042-bb58e0602e16 (dm-0) 253:0    0  10,9T  0 crypt 
      ├─system-os2 (dm-1)                              253:1    0    15G  0 lvm   /
      ├─system-swap (dm-2)                             253:2    0     4G  0 lvm   [SWAP]
      ├─system-home (dm-3)                             253:3    0  10,9T  0 lvm   /home
      └─system-vm (dm-4)                               253:4    0  27,4G  0 lvm   /vm
sdd                                                      8:48   0   3,7T  0 disk  
├─sdd1                                                   8:49   0   2,8T  0 part  
│ └─md1                                                  9:1    0  10,9T  0 raid6 
│   └─luks-bc648035-bdf2-4627-8042-bb58e0602e16 (dm-0) 253:0    0  10,9T  0 crypt 
│     ├─system-os2 (dm-1)                              253:1    0    15G  0 lvm   /
│     ├─system-swap (dm-2)                             253:2    0     4G  0 lvm   [SWAP]
│     ├─system-home (dm-3)                             253:3    0  10,9T  0 lvm   /home
│     └─system-vm (dm-4)                               253:4    0  27,4G  0 lvm   /vm
└─sdd2                                                   8:50   0   858G  0 part  
sda                                                      8:0    0   2,7T  0 disk  
├─sda1                                                   8:1    0   195M  0 part  
│ └─md0                                                  9:0    0   195M  0 raid1 /boot
└─sda2                                                   8:2    0   2,7T  0 part  
  └─md1                                                  9:1    0  10,9T  0 raid6 
    └─luks-bc648035-bdf2-4627-8042-bb58e0602e16 (dm-0) 253:0    0  10,9T  0 crypt 
      ├─system-os2 (dm-1)                              253:1    0    15G  0 lvm   /
      ├─system-swap (dm-2)                             253:2    0     4G  0 lvm   [SWAP]
      ├─system-home (dm-3)                             253:3    0  10,9T  0 lvm   /home
      └─system-vm (dm-4)                               253:4    0  27,4G  0 lvm   /vm
sde                                                      8:64   0   3,7T  0 disk  
├─sde1                                                   8:65   0   2,8T  0 part  
│ └─md1                                                  9:1    0  10,9T  0 raid6 
│   └─luks-bc648035-bdf2-4627-8042-bb58e0602e16 (dm-0) 253:0    0  10,9T  0 crypt 
│     ├─system-os2 (dm-1)                              253:1    0    15G  0 lvm   /
│     ├─system-swap (dm-2)                             253:2    0     4G  0 lvm   [SWAP]
│     ├─system-home (dm-3)                             253:3    0  10,9T  0 lvm   /home
│     └─system-vm (dm-4)                               253:4    0  27,4G  0 lvm   /vm
└─sde2                                                   8:66   0   858G  0 part  
  └─md127                                                9:127  0   858G  0 raid1 
sdf                                                      8:80   0   3,7T  0 disk  
├─sdf1                                                   8:81   0   2,8T  0 part  
│ └─md1                                                  9:1    0  10,9T  0 raid6 
│   └─luks-bc648035-bdf2-4627-8042-bb58e0602e16 (dm-0) 253:0    0  10,9T  0 crypt 
│     ├─system-os2 (dm-1)                              253:1    0    15G  0 lvm   /
│     ├─system-swap (dm-2)                             253:2    0     4G  0 lvm   [SWAP]
│     ├─system-home (dm-3)                             253:3    0  10,9T  0 lvm   /home
│     └─system-vm (dm-4)                               253:4    0  27,4G  0 lvm   /vm
└─sdf2                                                   8:82   0   858G  0 part  
  └─md127                                                9:127  0   858G  0 raid1 
sdg                                                      8:96   0   7,3T  0 disk

sdg ist die neue Platte.

Zur Fehlersuche bin ich bislang noch nicht gekommen. Später mehr...

gehrke · 7 Juni 2016

Zur Fehlerursache kann ich in /var/log/messages leider gar nichts finden.

Hier der Auszug vom ersten Vorfall:

Code:

Jun  3 08:31:24 j4 dhclient[1879]: bound to 172.16.13.10 -- renewal in 3137 seconds.
Jun  3 16:57:42 j4 kernel: imklog 4.6.2, log source = /proc/kmsg started.

Und hier vom zweiten:

Code:

Jun  6 07:52:29 j4 dhclient[1842]: bound to 172.16.11.8 -- renewal in 3382 seconds.
Jun  7 19:00:37 j4 kernel: imklog 4.6.2, log source = /proc/kmsg started.

Scheint aus heiterem Himmel gekommen zu sein.

josef-wien · 7 Juni 2016

Das ist eine sehr interessante (oder eher mysteriöse) Konstellation. Nachdem es zwar viele Platten, aber nur wenige Partitionen gibt, sind die für das RAID6 notwendigen Informationen am Bildschirm zu sehen. Alle 6 Teile von md1 werden zwar erkannt, aber mit der Meldung "requires wrong number of drives" versehen. Bei den vier keine Teile von md0 enthaltenen Platten kommt zusätzlich "Cannot assemble mbr metadata". Mir sind die Meldungen noch nicht untergekommen, vielleicht kann robi dazu etwas sagen.

Und beim nächsten Systemstart lösen sich die Probleme von selbst und das System startet wieder ...

gehrke · 7 Juni 2016

gehrke schrieb:
Falls das klappt, werde ich neben der LogFile-Analyse insbesondere mal einen Check der jüngst hinzugekommenen Backup-Disk durchführen.

Code:

[root@j4 ~]# smartctl -a -t short /dev/sdg
[...]
=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 2 minutes for test to complete.
Test will complete after Tue Jun  7 22:50:07 2016

Use smartctl -X to abort test.

Code:

[root@j4 ~]# smartctl -a /dev/sdg
smartctl 5.39.1 2010-01-28 r3054 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Device Model:     HGST HUH728080ALE600
Serial Number:    <xxx>
Firmware Version: A4GNT7J0
User Capacity:    8.001.563.222.016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  ATA-8-ACS revision 4
Local Time is:    Tue Jun  7 22:50:19 2016 CEST
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:  (0x82) Offline data collection activity
                                        was completed without error.
                                        Auto Offline Data Collection: Enabled.
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:                 ( 101) seconds.
Offline data collection
capabilities:                    (0x5b) 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.
                                        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.
                                        General Purpose Logging supported.
Short self-test routine 
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 255) minutes.
SCT capabilities:              (0x003d) SCT Status supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

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   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   134   134   054    Pre-fail  Offline      -       104
  3 Spin_Up_Time            0x0007   100   100   024    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       1
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   128   128   020    Pre-fail  Offline      -       18
  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       144
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       1
 22 Unknown_Attribute       0x0023   100   100   025    Pre-fail  Always       -       100
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       10
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       10
194 Temperature_Celsius     0x0002   133   133   000    Old_age   Always       -       45 (Lifetime Min/Max 21/47)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
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
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%       144         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Als unbedarfter Laie sehe ich da erst mal keine Probleme?!?
Ich probiere mal die längere Testvariante, aber die braucht mehr als 4 Stunden...

Anonymous · 8 Juni 2016

Auf dem RAID md1 liegt ein LUKS-Container und darin eine LVM-Partitionierung.

tolle Geschichte, ich hoffe du hast das in deinem Backups und den Howtos wie du daraus wieder ein funktionierendes System erstellen kannst alles fein säuberlich berücksichtigt. :???: (nur Späßle g'macht)

Die Ausgaben die du nach dem Absturz bekommen hast stammen scheinbar aus einem boot der eventuell automatisch nach einem Fehler angestoßen wird und den Befehlen die du dann dort wahrscheinlich innerhalb einer Notshell auf der initrd abgegeben hast??? Oder ???

Was genau dort passiert ist erst zu erkennen wenn es dir gelingt dieses irgendwie komplett zu protokollieren.
ZB. Bootparameter und dort eine serielle Konsole konfigurieren und mit einem 2. Rechner und Terminal dort mitlogen wenn die Kiste das nächste mal abschmiert.

Die Meldungen wie du sie bei mdadm hattest, sind soweit normal und stammen vom Einsammeln der Daten, zum Schluss sollte sich aber daraus im Normalfall zusammenpassende Konfigurationen für die Raids geben. Kommt bei einem raid1 nicht, aber es ist nicht zu sehen was du genau für einen Befehl abgesetzt hast. Die Einzelnen Ausgaben sind auch soweit schlüssig mit den Daten die du in der Zwischenzeit hier gepostet hast. Problem dort kann es geben zB wenn doppelte oder nicht eindeutige Raidblöcke auf den Partitionen vorhanden sind, wenn zu viele Raidbestandteile offline/defekt markiert sind die mdadm.conf nicht mehr passend ist oder ähnliches mehr.
Oder in seltenen Fällen auch die Reihenfolge der Platten dort nicht stimmt, dass kann passieren wenn eine Platte zB vor dem Restart in einen TiefSchlaf oder Defekt verfallen ist oder eine Platte wegen irgend welcher Probleme länger mit dem eigenen Reset beschäftigt ist oder sich nicht schnell genug nach einem Controllerreset meldet. Dann kann mal schnell in der Reihenfolge aus einer sdc eine sdf werden und dazwischen sind die anderen Devicenamen auch verschoben. In den einzelnen Raidsuperblöcken auf den Partitionen ist neben der unbedingt wichtigen UID und denn allgemeinen Parametern wie Größe ...... auch die eigene Position innerhalb des Raids und die der anderen zum Raid gehörenden Partitionen in Form von Major/Minor Nummern bzw dem damit korrospondierenden /dev/sd?? Namen, und nicht zuletzt für die anderen Raidteile der Status vermerkt. Wenn da die Daten der einzelen Raidsuperblöcke nicht wirklich zusammenpassen, weil zB die Plattenreihenfolge nicht schlüssig zu den Einträgen der Superblöcke passt, muss das Raid mit "force" und/oder komplett per entsprechender Kommandozeile Assembled werden, eventuell auch einzelne Teile manuell wieder online gesetzt werden, das machen die normalen Startscripte nicht automatisch.
Aber ich glaube das liegt bei dir so nicht zwingend vor, die Daten sehen soweit für mich zu mindestens mal schlüssig und nicht durcheinander aus.

Bei einem dann manuellem reboot dann von dieser Halte-Stelle aus der Notshell der initrd, scheint dann aber alles anschließend wieder zu passen, ???
All das würde aber auch noch lange nicht erklären warum die Kiste überhaupt abschmiert.

Wofür ich auch noch keine Erklärung habe

md1 : active raid6 sda2[4] sdd1[7] sdb2[1] sdc1[2] sde1[6] sdf1[8]
11720260608 blocks super 1.0 level 6, 128k chunk, algorithm 2 [6/6] [UUUUUU]
bitmap: 1/11 pages [4KB], 131072KB chunk

hattest du dort mal mehr Devices drinnen ( Spare, Missing, Dummy .... ) oder sind dort schon vorher mal Platten re-added worden?

Irgendwie müssen zur Fehleranalyse die Ausgaben vom Crash und dem anschließendem "Startversuch" bis zu seinem Abbruch her, ist das überhaupt ein richtiger normaler Bootvorgang oder einer mit sicheren Optionen ? alles andere ist wohl Spekulazius.

robi

gehrke · 8 Juni 2016

robi schrieb:
tolle Geschichte, ich hoffe du hast das in deinem Backups und den Howtos wie du daraus wieder ein funktionierendes System erstellen kannst alles fein säuberlich berücksichtigt. :???: (nur Späßle g'macht)

Uh Oh, doppelte Warnstufe: Jetzt wird das Problem schon zur Chefsache und der spricht auch noch das fiese Schlüsselwort. Oh weh...

Ja, ich habe zwei valide Backup-Sätze aus den Vormonaten, so dass ich die wichtigen Daten keinesfalls verlieren sollte (evtl. wird es einige Zeit kosten, das System wieder zum laufen zu bekommen, aber das Schlimmste sollte abgedeckt sein). Ich ziehe auch noch mal ein aktuelles Image vom System.
Nur ist es leider so, dass dieser Server auch als Backup-Server dient. Und er scheinbar genau während des Voll-Backups abstürzt. Demnach werde ich zukünftig kein aktuelles Backup mehr haben. Nicht von diesem System und auch nicht von allen anderen in meiner Infrastruktur... :zensur:

robi schrieb:
[...]Aber ich glaube das liegt bei dir so nicht zwingend vor, die Daten sehen soweit für mich zu mindestens mal schlüssig und nicht durcheinander aus.

Bei einem dann manuellem reboot dann von dieser Halte-Stelle aus der Notshell der initrd, scheint dann aber alles anschließend wieder zu passen, ???
All das würde aber auch noch lange nicht erklären warum die Kiste überhaupt abschmiert.

Das sehe ich auch so. Ich habe den Eindruck, dass das zwei vollständig eigenständige Paar Schuhe sind:

Einerseits komme ich nach einem Crash mit dieser Notfall-Shell nicht wirklich auf ein sauberes System. Das ist zwar unschön, aber tut mir nicht weh, weil ich lokalen Zugang habe und jederzeit von einem USB-Medium booten und zugreifen können sollte. Übrigens könnte ich mir da auch vorstellen, dass es irgendwo einen Timeout für die Eingabe der LUKS-Passphrase gibt, der dann nach dem Crash abgelaufen ist und alleine deswegen schon alles weitere versagt. Jedenfalls glaube ich nicht, dass das mein Kernproblem ist und demnach würde ich diesen Aspekt (alles was bislang mangels Alternativen über Fotos abgehandelt wurde) bis auf weiteres ignorieren wollen.

Andererseits der Crash an sich, bei dem ich aktuell vollkommen ohne Vorstellung bin, was dafür die Ursache ist.

robi schrieb:
Wofür ich auch noch keine Erklärung habe

md1 : active raid6 sda2[4] sdd1[7] sdb2[1] sdc1[2] sde1[6] sdf1[8]
11720260608 blocks super 1.0 level 6, 128k chunk, algorithm 2 [6/6] [UUUUUU]
bitmap: 1/11 pages [4KB], 131072KB chunk

Zum Vergrößern anklicken....

hattest du dort mal mehr Devices drinnen ( Spare, Missing, Dummy .... ) oder sind dort schon vorher mal Platten re-added worden?

Ja, es waren im Laufe der letzten Jahre auch mal Disks defekt und wurden getauscht oder erneuert und das RAID6 wurde um Platten erweitert. Hatte ich übrigens öffentlich gemacht, Du findest das noch in der linupedia und unter linux-talk.de dokumentiert (teilweise unter Deiner Beteiligung). Die letzte Änderung daran ist aber mindestens 1 Jahr her und in dieser Zeit lief das Teil stabil 24x7.

robi schrieb:
Irgendwie müssen zur Fehleranalyse die Ausgaben vom Crash und dem anschließendem "Startversuch" bis zu seinem Abbruch her, ist das überhaupt ein richtiger normaler Bootvorgang oder einer mit sicheren Optionen ? alles andere ist wohl Spekulazius.

Genau das denke ich auch. Ich brauche Debug-Informationen, um Anhaltspunkte für die Ursache zu bekommen. Derzeit habe ich aber keine Vorstellung, was genau da zu tun ist. Evtl. den Log-Level hochsetzen?

Zum Thema Spekulation: Weil ich in den Logs rein gar nichts sehe, könnte ich mir vorstellen, dass es ein Problem mit der Stromversorgung gegeben hat. Kein globales (weil andere Systeme nicht betroffen waren), sondern ein lokales.
Weiteres Argument dafür ist, dass in der fraglichen Zeit das Vollbackup lief und somit insgesamt 7 Festplatten (6 in md1 und die Backup-Festplatte) beschäftigt waren und die Prozessoren durch Software-RAID und doppelte Verschlüsselung (LUKS auf md1 und auf der Backup-Festplatte) ebenfalls ordentlich gezogen haben sollten.
Das wird zwar prinzipiell so auch schon seit geraumer Zeit durchgeführt und machte bislang keine Probleme, aber Netzteile sind wahrscheinlich auch nicht endlos auf gleichbleibender Qualität zu betreiben?!?

EDIT: Gegen die These mit dem Netzteil spricht die Tatsache, dass noch im April zwei Disks zu einem RAID0 als Backup-Disk zusammengefasst waren. Zu diesem Zeitpunkt liefen demnach nicht nur 7, sondern 8 Festplatten problemlos (restliche Umgebung vergleichbar zu heute).

Dank für Deine Antwort...

gehrke · 8 Juni 2016

gehrke schrieb:
Ich probiere mal die längere Testvariante, aber die braucht mehr als 4 Stunden...

Code:

[root@j4 ~]# smartctl -a -t long /dev/sdg

Am nächsten Morgen:

Code:

[root@j4 ~]# smartctl -a /dev/sdg
smartctl 5.39.1 2010-01-28 r3054 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Device Model:     HGST HUH728080ALE600
Serial Number:    <...>
Firmware Version: A4GNT7J0
User Capacity:    8.001.563.222.016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  ATA-8-ACS revision 4
Local Time is:    Wed Jun  8 08:20:52 2016 CEST
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:  (0x82) Offline data collection activity
                                        was completed without error.
                                        Auto Offline Data Collection: Enabled.
Self-test execution status:      ( 243) Self-test routine in progress...
                                        30% of test remaining.
Total time to complete Offline 
data collection:                 ( 101) seconds.
Offline data collection
capabilities:                    (0x5b) 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.
                                        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.
                                        General Purpose Logging supported.
Short self-test routine 
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 255) minutes.
SCT capabilities:              (0x003d) SCT Status supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

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   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   134   134   054    Pre-fail  Offline      -       104
  3 Spin_Up_Time            0x0007   100   100   024    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       1
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   128   128   020    Pre-fail  Offline      -       18
  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       154
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       1
 22 Unknown_Attribute       0x0023   100   100   025    Pre-fail  Always       -       100
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       10
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       10
194 Temperature_Celsius     0x0002   122   122   000    Old_age   Always       -       49 (Lifetime Min/Max 21/49)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
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
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%       144         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Ich sehe dabei keine Probleme.

Geier0815 · 8 Juni 2016

Hast Du schon mit zB der UltimateBootCD einen burn-in-test also einen Streßtest der CPU und damit auch des Motherboards gemacht? Und von der gleichen CD oder aus dem grub-menü einen RAM-Test? Wenn nicht, hol das mal nach. Danach können wir immer noch mal weiter in Richtung Netzteil oder andere Fehlerquellen gucken.

Ansonsten solltest Du evtl auch mal darüber nachdenken dir echte Serverhardware zu zulegen, so mit vernünftigem RAID-Controller incl Batterie und redundanten Netzteilen und so. Da muß es für deinen Anwendungsfall sicherlich nichts aktuelles sein (auch wenn es verführerisch ist).

gehrke · 8 Juni 2016

Geier0815 schrieb:
Ansonsten solltest Du evtl auch mal darüber nachdenken dir echte Serverhardware zu zulegen,

Darüber denke ich regelmäßig nach, wenn ich die miese Performance beim monatlichen Full-Backup betrachten muss. :zensur:
Bislang waren die Schmerzen aber nicht groß genug und ich würde diese Hardware gerne noch einige Zeit weiterverwenden.

josef-wien · 8 Juni 2016

Ich sehe in Deiner smartctl-Ausgabe nichts vom long test, sondern nur den short test. Außerdem paßt das Attribut 192 nicht zum Attribut 12. 192 zeigt an, daß der Platte bisher 10mal brutal der Stom abgedreht wurde, laut 12 wurde die Platte bisher aber nur ein einziges Mal eingeschaltet. Ob da vielleicht doch ein instabiles Netzteil mitspielt?

gehrke · 8 Juni 2016

josef-wien schrieb:
Ich sehe in Deiner smartctl-Ausgabe nichts vom long test, sondern nur den short test.

Jeder blamiert sich so gut er kann...
Es gelang mir tatsächlich bislang noch nicht, den long-Test richtig zu initialisieren:

Code:

[root@j4 ~]# smartctl -t long /dev/sdg       
smartctl 5.39.1 2010-01-28 r3054 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 255 minutes for test to complete.
Test will complete after Wed Jun  8 16:57:18 2016

Folgende Aufrufe von

Code:

[root@j4 ~]# smartctl -a /dev/sdg

brachten bislang noch keine Änderung.

Auf Deine anderen Hinweise komme ich später zurück...
TNX

gehrke · 9 Juni 2016

gehrke schrieb:
Es gelang mir tatsächlich bislang noch nicht, den long-Test richtig zu initialisieren:

Es bleibt dabei, ich bekomme zwar die Ankündigung, wann der lange Test beendet sein soll, aber keine Ergebnisse. Keine Ahnung, was ich da falsch mache. :???:

Allerdings helfen wahrscheinlich auch die Informationen vom Kurztest weiter:

josef-wien schrieb:
Außerdem paßt das Attribut 192 nicht zum Attribut 12. 192 zeigt an, daß der Platte bisher 10mal brutal der Stom abgedreht wurde, laut 12 wurde die Platte bisher aber nur ein einziges Mal eingeschaltet. Ob da vielleicht doch ein instabiles Netzteil mitspielt?

Die absoluten Zahlen lassen sich möglicherweise plausibel genug mit Tests im BIOS bzw. der frühen Boot-Phase des Systems erklären, bei denen unmittelbar nach dem Einbau tatsächlich hart abgeschaltet bzw. reseted wurde.

Das bietet aber möglicherweise einen ersten Ansatzpunkt, um auf Probleme mit der Stromversorgung zu schließen. Wenn ich die relevanten Werte für alle Platten sichere und dann das Problem beim Full-Backup wieder auftritt, sollte ich in der Lage sein, auf diesem Wege nachzuvollziehen, ob die Stromversorgung unterbrochen war. Verbunden mit einem cron-Job, der minütlich den aktuellen Timestamp als Lebenszeichen in eine Datei schreibt, um den Zeitpunkt des Vorfalls zu dokumentieren.
Oder täusche ich mich da?

Die relevanten Eigenschaften sollten dann nach josef-wien (Danke dafür!) diese sein:

Code:

 12 Power_Cycle_Count
192 Power-Off_Retract_Count

josef-wien · 9 Juni 2016

gehrke schrieb:
Keine Ahnung, was ich da falsch mache.

Das Problem scheint mir die Platte zu sein, die entweder gar nichts macht oder vergißt, die Werte auch zu speichern. Unter diesem Gesichtspunkt ist zu hoffen, daß

gehrke schrieb:
Code:

SMART Error Log Version: 1 No Errors Logged

und die Attribute die Realität abbilden (die durchaus heil aussieht).

gehrke schrieb:
Allerdings helfen wahrscheinlich auch die Informationen vom Kurztest weiter

Ein Test hat nur insofern mit den Attributen zu tun, als sich auftretende Probleme auch auf die Werte auswirken.

gehrke schrieb:
Oder täusche ich mich da?

Es klingt logisch.

gehrke · 9 Juni 2016

gehrke schrieb:
gehrke schrieb:

Das bietet aber möglicherweise einen ersten Ansatzpunkt, um auf Probleme mit der Stromversorgung zu schließen. Wenn ich die relevanten Werte für alle Platten sichere und dann das Problem beim Full-Backup wieder auftritt, sollte ich in der Lage sein, auf diesem Wege nachzuvollziehen, ob die Stromversorgung unterbrochen war. Verbunden mit einem cron-Job, der minütlich den aktuellen Timestamp als Lebenszeichen in eine Datei schreibt, um den Zeitpunkt des Vorfalls zu dokumentieren.

Zum Vergrößern anklicken....

Das ist jetzt umgesetzt und das Vollbackup läuft. Wenn es sich wieder in dem Zeitrahmen wie bei den ersten beiden malen bewegt, dann sollte das Problem zwischen Samstag und Sonntag auftreten.

Ich habe noch zwei andere Dinge getan.
1. Im BIOS den Neustart nach einem POWER LOSS abgeschaltet. Macht mit dem LUKS-Container sowieso keinen Sinn und überschreibt möglicherweise wichtige Meldungen während des Absturzes auf dem Monitor.
2. Im EventLog des Boards nach Meldungen zur Stromversorgung zu schauen. Ich habe keine gefunden.
Was ich aber fand waren einige Meldungen zu RAM-Fehlern:

Code:

Smbios 0x01 N/A - Single Bit ECC Memory Error

Oops!
Diese beginnen im größeren Umfang im Februar 2016, ziemlich genau einen Monat davor hatte ich in dem System die Speicherriegel getauscht (inkl. erfolgreichem MemTest).
In den zwei relevanten Zeiträumen mit einem Crash gab es aber keinerlei Einträge.
Unter normalen Umständen hätte ich gesagt, ECC ist dafür da, solche Fehler unschädlich zu machen. Zumal ich in den Logs des Betriebsystems so was nie gesehen habe und alles stabil lief. Aber in diesem Zusammenhang ist das natürlich durchaus verdächtig.

gehrke · 11 Juni 2016

gehrke schrieb:
Das ist jetzt umgesetzt und das Vollbackup läuft. Wenn es sich wieder in dem Zeitrahmen wie bei den ersten beiden malen bewegt, dann sollte das Problem zwischen Samstag und Sonntag auftreten.

Genau so ist es gekommen, nach 1 1/2 Tagen war Schicht. Hier die letzten Lebenszeichen von dem cron-Job:

Code:

20160611 09:20:01 up 1 day, 11:34, 1 user, load average: 1.67, 1.37, 1.48
20160611 09:21:01 up 1 day, 11:35, 1 user, load average: 0.90, 1.21, 1.42
20160611 09:22:01 up 1 day, 11:36, 1 user, load average: 0.96, 1.25, 1.42
20160611 09:23:01 up 1 day, 11:37, 1 user, load average: 1.04, 1.29, 1.43
20160611 09:24:01 up 1 day, 11:38, 1 user, load average: 0.99, 1.27, 1.41
20160611 09:25:01 up 1 day, 11:39, 1 user, load average: 1.29, 1.32, 1.42
20160611 09:26:01 up 1 day, 11:40, 1 user, load average: 1.44, 1.34, 1.42
20160611 09:27:01 up 1 day, 11:41, 1 user, load average: 1.65, 1.37, 1.41
20160611 09:28:01 up 1 day, 11:42, 1 user, load average: 1.76, 1.39, 1.41
20160611 09:29:01 up 1 day, 11:43, 1 user, load average: 2.02, 1.48, 1.44
20160611 09:30:02 up 1 day, 11:44, 1 user, load average: 1.14, 1.33, 1.39
20160611 09:31:01 up 1 day, 11:45, 1 user, load average: 1.34, 1.42, 1.42
20160611 09:32:01 up 1 day, 11:46, 1 user, load average: 2.16, 1.66, 1.50
20160611 09:33:01 up 1 day, 11:47, 1 user, load average: 2.49, 1.83, 1.57
20160611 09:34:01 up 1 day, 11:48, 1 user, load average: 1.28, 1.62, 1.51
20160611 09:35:01 up 1 day, 11:49, 1 user, load average: 1.22, 1.56, 1.50
20160611 09:36:01 up 1 day, 11:50, 1 user, load average: 1.35, 1.56, 1.50
20160611 09:37:01 up 1 day, 11:51, 1 user, load average: 1.93, 1.69, 1.55
20160611 09:38:01 up 1 day, 11:52, 1 user, load average: 2.40, 1.89, 1.63
20160611 09:39:01 up 1 day, 11:53, 1 user, load average: 2.25, 1.89, 1.64
20160611 09:40:02 up 1 day, 11:54, 1 user, load average: 0.95, 1.58, 1.54
20160611 09:41:01 up 1 day, 11:55, 1 user, load average: 0.86, 1.48, 1.52

Wenigstens habe ich jetzt einen exakten Zeitraum von 1 Minute Umfang.
Wieder nix neues in den Logs des Servers:

Code:

Jun 11 09:31:57 j4 dhclient[1787]: bound to 172.16.11.8 -- renewal in 3509 seconds.
Jun 11 10:09:08 j4 kernel: imklog 4.6.2, log source = /proc/kmsg started.

gehrke schrieb:
Ich habe noch zwei andere Dinge getan.
1. Im BIOS den Neustart nach einem POWER LOSS abgeschaltet. Macht mit dem LUKS-Container sowieso keinen Sinn und überschreibt möglicherweise wichtige Meldungen während des Absturzes auf dem Monitor.

Netter Versuch. Leider sieht der Bildschirm nach dem aktuellen Crash exakt genau so aus wie der vom ersten Screenshot. Entweder greift meine Änderung nicht oder das kommt nicht vom Board bzw. hängt nicht mit der Stromversorgung zusammen..

gehrke schrieb:
2. Im EventLog des Boards nach Meldungen zur Stromversorgung zu schauen. Ich habe keine gefunden.

Möglicherweise ein passender Eintrag dazu im EventLog des Boards! Der letzte Eintrag wegen ECC-Error stammt von 11.06.2016 07:41:19. Hier scheint eine andere Zeitzone verwendet zu werden, die im BIOS angezeigte Zeit geht im Vergleich zur aktuellen Zeit um 2 Stunden nach. Da ist jetzt wohl wirklich ein MemTest fällig...

Zu der Platteneigenschaften:

Code:

[root@j4 ~]# diff test-sdg.txt test-sdg-20160611.txt 
5,15d4
< Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
< Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
< Testing has begun.
< Please wait 255 minutes for test to complete.
< Test will complete after Thu Jun  9 01:32:34 2016
< 
< Use smartctl -X to abort test.
< smartctl 5.39.1 2010-01-28 r3054 [x86_64-unknown-linux-gnu] (local build)
< Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
< 
< === START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
20c9
< Test will complete after Thu Jun  9 22:38:16 2016
---
> Test will complete after Sat Jun 11 12:54:02 2016
34c23
< Local Time is:    Thu Jun  9 22:39:16 2016 CEST
---
> Local Time is:    Sat Jun 11 12:55:02 2016 CEST
78c67
<   4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       3
---
>   4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       4
82c71
<   9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       192
---
>   9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       230
84c73
<  12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       3
---
>  12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       4
86,88c75,77
< 192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       14
< 193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       14
< 194 Temperature_Celsius     0x0002   127   127   000    Old_age   Always       -       47 (Lifetime Min/Max 21/50)
---
> 192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       16
> 193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       16
> 194 Temperature_Celsius     0x0002   125   125   000    Old_age   Always       -       48 (Lifetime Min/Max 21/50)
99,101c88,91
< # 1  Short offline       Completed without error       00%       192         -
< # 2  Extended offline    Interrupted (host reset)      20%       178         -
< # 3  Short offline       Completed without error       00%       144         -
---
> # 1  Short offline       Completed without error       00%       230         -
> # 2  Short offline       Completed without error       00%       192         -
> # 3  Extended offline    Interrupted (host reset)      20%       178         -
> # 4  Short offline       Completed without error       00%       144         -

Ein Reboot aus der Notfall-Shell funktionierte nicht, daher habe ich die Power-Taste für den Neustart genutzt. Ich vermute, die Erhöhung um 1 bei Power_Cycle_Count kommt daher. Aber Power-Off_Retract_Count ist um 2 erhöht!?!

gehrke · 11 Juni 2016

MemTest läuft, schon Fehler zu erkennen, später mehr...

Verschoben nach 'Hardware'.

marce · 11 Juni 2016

.. und ich sach noch...

gehrke · 13 Juni 2016

gehrke schrieb:
Was ich aber fand waren einige Meldungen zu RAM-Fehlern:
[...]
Diese beginnen im größeren Umfang im Februar 2016, ziemlich genau einen Monat davor hatte ich in dem System die Speicherriegel getauscht (inkl. erfolgreichem MemTest).

Nach 1 1/2 Tagen ist der MemTest durch. Ich werde versuchen, die Bausteine zu reklamieren.

Allerdings ist es IMHO nicht plausibel, dass diese Fehler scheinbar erst seit Kurzem auftreten. Erstmals verwendet wurden die im Januar und es gab keinerlei Probleme damit bei unverändertem Nutzungsverhalten (die Backups laufen in der Intensität auch schon die ganze Zeit, 24x7). Jetzt plötzlich bekomme ich reproduzierbar einen Crash nach dem anderen. :???:

marce · 13 Juni 2016

Speicherfehler sind leider immer recht undspezifisch - sei es, daß ECC doch nicht immer alles ausbügeln kann, "aus Glück" wird die betreffente Speicherstelle nicht im relevanten Job benutzt, ...

Wenn's das wäre (also der Speicher die Ursache) - sei lieber froh, daß es so einfach zu erklären ist - alles andere (CPU, Netzteil, ggf. Board) ist meist wesentlich stressiger herauszufinden und zu beseitigen...

Je nach Speicherkonfiguration kannst Du ja mal versuchen, den defekten Riegel rauszunehmen und dann zu prüfen, was passiert...

misiu · 14 Juni 2016

Wenn man das so durchgelesen hat...
Stromspannungspitzen / Stromausfälle erzeugt vor allem in der letzten Monaten durch schlechtes Wetter,
könnten da Einfluss haben. Die Rechner sind meistens mit der Außenwelt durch Stromnetz oder Netzwerk
verbunden wenn da keine Filter eingebaut sind , kann so einiges passieren.

Du kannst bei den Ram-Steinen evtl. die Spannung um 0,25 Volt erhöhen und nochmal testen.

MfG
Misiu

[Gelöst] Unmotivierte Systemabstürze (CentOS)

Administrator

Administrator

Ultimate Guru

Administrator

Anonymous

Gast

Administrator

Administrator

Guru

Administrator

Ultimate Guru

Administrator

Administrator

Ultimate Guru

Administrator

Administrator

Administrator

Guru

Administrator

Guru

Moderator