+-Serie DS 109+ Volume-Absturz

Alle Geräte der +-Serie. Geräte für kleinere und mittlere Unternehmen.
Status
Für weitere Antworten geschlossen.

jahlives

Benutzer
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
4
Punkte
0
Hallo zusammen,

in den letzten drei Tagen ist mir jeweils 3 Mal das Volume einer meiner DSsen über Nacht abgestürzt. Das Teil piepte und blinkte am Morgen nur noch. Liess sich jedoch jeweils via Button runterfahren und dann neustarten. Der Neustart dauert zwar, wohl wegen dem Filesystemcheck. Aber danach kommt die DS wieder hoch als wäre nichts gewesen. Nur um in der nächsten Nacht wieder das Volume zu verlieren.
Leider verwende ich syslog-ng, welcher auf /opt loggt und damit sind die Logs im Fehlerfall nicht aktuell, wenn sich das Volume verabschiedet. Die Meldung der DS bezüglich des Volumes erhalte ich auch erst, wenn die DS neugestartet ist.
So kam die Meldung heute 07:06. Ich sehe aber in den Logs des Postfix, dass dieser seit 03:15 Probleme damit hatte Mails zuzustellen. Allerdings muss dann auch das Volume1 noch bestanden haben, sonst hätte sich der Mailserver gar nicht mehr bewegen dürfen. Gewisse File aus /opt konnten also noch gelesen werden.
Hat irgendjemand eine Idee? Die SMART Werte der Platten sehen (schon beinahe verdächtig) unproblematisch aus. Keine fehlerhaften Sektoren. Wirklich nichts verdächtiges. Auch startet die DS ja nach so einem Zwischenfall immer wieder sauber rauf, also kann das Dateisystem wohl auch ned völlig im A sein.
Als erstes werde ich auf jeden Fall wieder auf den Default-Logger umstellen. Denn /var/log müsste ja noch existieren, wenn sich volume1 verabschieden tut.

Für jede weiter Idee bin ich jedoch sehr dankbar
 

ubuntulinux

Benutzer
Mitglied seit
23. Jan 2010
Beiträge
2.063
Punkte für Reaktionen
0
Punkte
82
Andere Platte an der DS getestet? Wenn's funktioniert, die Platte in die Garantie ;)
 

Trolli

Benutzer
Mitglied seit
12. Jul 2007
Beiträge
9.848
Punkte für Reaktionen
1
Punkte
0
Stürzt das Volume ab, oder die komplette DS? Der Beschreibung nach kannst Du sie ja auch nicht mehr über den DSM erreichen, oder? Dann wäre es ja nicht nur das Volume. Wenn andererseits nur Volume1 hinübergeht, müsste der DSM ja eigentlich noch normal verfügbar sein...

Vielleicht mal einen Smart-test machen...
 

jahlives

Benutzer
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
4
Punkte
0
Ne andere Platte werde ich sicher auchmal noch probieren. Allerdings frage ich mich schon warum dann nichts in den SMART Werten erkennbar ist, wenn es die Platte sein soll. Auch startet das Teil danach ja wieder sauber. Und öfter als 1 mal pro 24h stürzt sie auch ned ab. Wenns die Platte wäre müsste das noch häufiger auftreten, oder?
 

Trolli

Benutzer
Mitglied seit
12. Jul 2007
Beiträge
9.848
Punkte für Reaktionen
1
Punkte
0
Vielleicht ein Dateisystem-Fehler. Passiert das zu einer bestimmten Uhrzeit?
 

ubuntulinux

Benutzer
Mitglied seit
23. Jan 2010
Beiträge
2.063
Punkte für Reaktionen
0
Punkte
82
Wenn die Elektronik der Platte eine Macke hat wirst Du das nicht bei den SMART Werten sehen.
 

jahlives

Benutzer
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
4
Punkte
0
Vielleicht ein Dateisystem-Fehler. Passiert das zu einer bestimmten Uhrzeit?
Tendenziell ja. Ich kanns jetzt nicht auf die Sekunde genau sagen, aber verdächtig oft so kurz nach 03:00 (gemäss den Fehlermeldungen). Ich müsste mal gucken ob ich da verdächtige Cronjobs am laufen habe. Allerdings wäre es trotzdem komisch, weil ich an diesen Jobs nichts geändert habe und das Problem erst seit dieser Woche auftritt.
Da ich es immer erst am Morgen merke und dann den reboot einleite, weiss ich ned ob der DSM noch funzen tut (keine Zeit das zu prüfen). Allerdings bin ich fast sicher, dass der noch läuft, sprich die Syspart und SWAP sollten noch i.O. sein. Sonst könnte der Mailserver ja keine Statusmails zu Problemen mehr verschicken. Im DSM wird unter Benachrichtigung auch jeweils nur volume1 erwähnt und nicht das System
 

Trolli

Benutzer
Mitglied seit
12. Jul 2007
Beiträge
9.848
Punkte für Reaktionen
1
Punkte
0
Aus eigener Erfahrung kann ich sagen, dass genau das bei einem Dateisystemfehler passiert. Sobald auf eine defekte Datei zugegriffen wird, schmiert das dazugehörige Volume ab. Nach einem Neustart ist es dann nach dem Check wieder da und man sieht keine Smart-Fehler.
 

ubuntulinux

Benutzer
Mitglied seit
23. Jan 2010
Beiträge
2.063
Punkte für Reaktionen
0
Punkte
82
Kannst ja mal versuchen das Filesystem unmounten (IPKG nicht vergessen):

umount /dev/md2

Dann Filesystem Check

e2fsck /dev/md2
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Platte sichern und neuformatieren und restoren und schauen, ob dann das Problem noch besteht. Dateisystemproblem, Datenblockprobleme und Platten-Blockprobleme müsste dann verschwunden sein. Das einzige, was dann noch sein kann, wäre dann eine korrupte Datei und die müsste sich eigentlich aus der /var/log/messages erkennen lassen.

Itari
 

jahlives

Benutzer
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
4
Punkte
0
Macht dieser Filesystemcheck denn etwas anders als der Filesystemcheck bei booten?
Was mir noch eingefallen ist: Das Problem hat sich langsam angedeutet. Zuerst, also noch bevor das Volume verlorenging, hatte ich bei jedem Reboot (egal ob via DSM, reboot oder Taster) einen Filesystemcheck. Dann seit irgendwann letzter Woche hatte ich immer wieder doppelt gestartete Prozesse. So lieft cron direkt nach dem Boot genau einmal, nach einer gewissen Zeit, waren dann zwei crons am Werke. Auch verschiedene andere Prozesse liefen plötzlich doppelt. Es waren jeweils Prozesse die durch Scripte in /opt/etc/init.d gestartet wurden. Noch bevor jemand fragt: Die Scripte sind sauber und arbeiten stop, start, und restart allesamt korrekt ab ;) Diese Scripte laufen unverändert seit Monaten einige seit Jahren..
Gerade jetzt laufen wieder zwei Instanzen von ipkg cron???
Mal noch die Logs angeschaut. Um 03:06 letzter Eintrag von cron und um 08:00 die ersten Einträge von cron (heute). Leider sind die Ausfälle nicht so regelmässig (zeitlich) wie ich dachte. Gestern scheint sich das Volume erst um 07:08 verabschiedet zu haben. Vorgestern sind die letzten Einträge von cron um 04:06. Also leider alles andere als regelmässig. Aber bis heute NIEMALS öfter als 1 Mal pro 24h.
Im Log habe ich aber keinerlei "verdächtige" Meldungen gefunden. Einfach ein letzter Eintrag von cron und dann sense bis Neustart.
Ich denke ich mache mich mal an die SMART-Tests der Platte.

Wenn jemand noch eine Idee hat, immer her damit. Eine Neuinstallation der Firmware resp des Volumes würde das Problem wohl lösen, aber dann habe ich wieder keine Idee was genau da passiert ist ;)

Gruss

tobi

p.s. in den Benachrichtigungen im DSM steht 04:06 (vorgestern), 07:07 (gestern) und 03:06 (heute) als Zeitpunkt des Volumeabsturzes
 

goetz

Super-Moderator
Teammitglied
Sehr erfahren
Mitglied seit
18. Mrz 2009
Beiträge
14.167
Punkte für Reaktionen
415
Punkte
393
Hallo,
Macht dieser Filesystemcheck denn etwas anders als der Filesystemcheck bei booten?
ja, beim booten wird quotacheck aufgerufen, am Filesystem wird nichts repariert. e2fsck checkt wirklich das Filesystem und kann es gegebenenfalls reparieren.

Gruß Götz
 

jahlives

Benutzer
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
4
Punkte
0
Und ich dachte ich hätte jedesmal bem booten einen fschk gehabt. Habe jetzt mal volume1 un-mounted und den e2fschk drauf losgelassen. Scheint ne gute Idee gewesen zu sein :)
mailserver> e2fsck /dev/sda3
e2fsck 1.41.12 (17-May-2010)
1.41.3-1141 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 425997 has zero dtime. Fix<y>? yes

Deleted inode 458765 has zero dtime. Fix<y>? yes
Wie lange dauert das für eine 1TB-Platte?
 

jahlives

Benutzer
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
4
Punkte
0
Okay der check ist durch. Hat doch einige Fehler gefunden, welche aber scheinbar gefixt wurden
1.41.3-1141: ***** FILE SYSTEM WAS MODIFIED *****
1.41.3-1141: 276658/60760064 files (0.3% non-contiguous), 4962144/243010360 blocks
Dann werde ich wohl jetzt einen Reboot wagen
**edit**
Sodele, der reboot war in 30 Sekunden erledigt. So solls sein. cron läuft (bis jetzt) auch nur einmal. Alle Dienste wieder - problemlos wie es scheint - gestartet.
Ich muss mir unbedingt hinter die Ohren schreiben, dass bei Start jeweils nur ein Quotacheck und eben kein fschk ausgeführt wird :)
Würde es nicht Sinn machen wenn Synology via Firmware in diesem Fall erst einen fschk machen würde? Oder besteht da das Risiko sich ein Filesystem komplett zu zerschiessen?

Dann nochmals danke für Euren Support. Kann nur wiedermal sagen: Echt Klasse wie sie hier geholfen werden :)
**/edit**
 
Zuletzt bearbeitet:

goetz

Super-Moderator
Teammitglied
Sehr erfahren
Mitglied seit
18. Mrz 2009
Beiträge
14.167
Punkte für Reaktionen
415
Punkte
393
Hallo,
ich kann es mir nur so erklären: der Check kann, je nach Plattengröße, recht lange dauern und der User rechnet ja nicht damit. Er wartet und wartet und ungeduldig wie er ist, wird schnell mal der Stecker gezogen. Das kann aber bei einem e2fsck extrem heikel sein und das Filesystem noch mehr zerschießen.

Gruß Götz
 

jahlives

Benutzer
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
4
Punkte
0
ich kann es mir nur so erklären: der Check kann, je nach Plattengröße, recht lange dauern und der User rechnet ja nicht damit. Er wartet und wartet und ungeduldig wie er ist, wird schnell mal der Stecker gezogen. Das kann aber bei einem e2fsck extrem heikel sein und das Filesystem noch mehr zerschießen.
Das macht Sinn. Heisst das aber, dass bei einem Quotacheck nix kapputtgehen kann wenn man den Strom zieht?
Synology könnte das auch so lösen: Nach dem reboot nach einem Absturz des Volumes könnte es ja einen Hinweis dazu im DSM geben mit der Option einen e2fschk einzuleiten. Danach weiss der User ja dass was wichtiges am Laufen ist. Zusätzlich könnte Syno die Statusled ja SOS morsen lassen, solange der Check noch läuft ;)
Ich bin wie selbstverständlich davon ausgegangen, dass es ein Filesystemcheck war beim Booten

Gruss

tobi
 

goetz

Super-Moderator
Teammitglied
Sehr erfahren
Mitglied seit
18. Mrz 2009
Beiträge
14.167
Punkte für Reaktionen
415
Punkte
393
Hallo,
dem quotacheck scheint das nix zu machen, ich denke viele haben schon aus Ungeduld da öfter mal den Stecker gezogen.
quotacheck - scan a filesystem for disk usage, create, check and repair quota files
Nach dem reboot nach einem Absturz des Volumes könnte es ja einen Hinweis dazu im DSM geben mit der Option einen e2fschk einzuleiten. Danach weiss der User ja dass was wichtiges am Laufen ist. Zusätzlich könnte Syno die Statusled ja SOS morsen lassen, solange der Check noch läuft
Das wirft aber die nächsten Probleme auf, es müssen ja fast alle Services runter gefahren werden und wenn dann noch ipkg dazwischen funkt wird es schwer. Die Bedeutung der LEDs müsste man sich aber vorher angelesen haben, wer macht das schon:rolleyes:.

Gruß Götz
 

jahlives

Benutzer
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
4
Punkte
0
Das mit ipkg sehe ich ein. Mit sauberen Startscripten (bei ipkg) wäre das Risiko aber eher gering, oder?
Ich habe mich gefragt ob denn bei mir eventuell die Quotachecks zu Fehlern geführt haben könnten bzw ob die Quotachecks allfällige Fehler nicht verschlimmert haben. Denn die "Verluste" des Volumes sind erst aufgetreten, als ich schon eine zeitlang Quotachecks bei jedem boot hatte.
Hätte hier noch die komplette Ausgabe des checks
mailserver> e2fsck /dev/sda3
e2fsck 1.41.12 (17-May-2010)
1.41.3-1141 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 425997 has zero dtime. Fix<y>? yes

Deleted inode 458765 has zero dtime. Fix<y>? yes

Deleted inode 21430276 has zero dtime. Fix<y>? yes

Deleted inode 48152580 has zero dtime. Fix<y>? yes

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(1734656--1734669) -(1865728--1865741) +15973529 -83082393 -(85745664--85745695) -(85745720--85745722) -(192624640--192624653)
Fix<y>? yes

Free blocks count wrong for group #52 (32228, counted=32242).
Fix<y>? yes

Free blocks count wrong for group #56 (32228, counted=32242).
Fix<y>? yes

Free blocks count wrong for group #487 (31933, counted=31932).
Fix<y>? yes

Free blocks count wrong for group #2535 (22089, counted=22090).
Fix<y>? yes

Free blocks count wrong for group #2616 (32219, counted=32254).
Fix<y>? yes

Free blocks count wrong for group #5878 (32240, counted=32254).
Fix<y>? yes

Free blocks count wrong (238048139, counted=238048216).
Fix<y>? yes

Inode bitmap differences: -425997 -458765 -21430276 -48152580
Fix<y>? yes

Free inodes count wrong for group #52 (8179, counted=8180).
Fix<y>? yes

Free inodes count wrong for group #56 (8179, counted=8180).
Fix<y>? yes

Free inodes count wrong for group #2616 (8191, counted=8192).
Fix<y>? yes

Free inodes count wrong for group #5878 (8191, counted=8192).
Fix<y>? yes

Free inodes count wrong (60483402, counted=60483406).
Fix<y>? yes


1.41.3-1141: ***** FILE SYSTEM WAS MODIFIED *****
1.41.3-1141: 276658/60760064 files (0.3% non-contiguous), 4962144/243010360 blocks
Kann vielleicht jemand aus der Art der Fehler rauslesen wo das ursprüngliche Problem gelegen haben könnte?
 

jahlives

Benutzer
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
4
Punkte
0
Leider habe ich immer noch den doppelten cron. Gerade jetzt wieder einen zweiten cron Prozess gehabt. Kann man irgendwie abfragen wann eine bestimmte Instanz eines Prozesses gestartet wurde?
 

jahlives

Benutzer
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
4
Punkte
0
Sorry, dass ich das wieder hochkrame. Das Problem mit dem doppelten cron konnte ich lösen, indem ich auf den Firmware cron ausgewichen bin. Damit ist die Box die letzte Zeit gut gefahren.
Am Dienstag (resp Mittwoch sehr früh) habe ich etwas im Netzwerk umhängen wollen und wollte daher alle Netzwerkkomponenten stromloas machen. Also die DS auch runterfahren wollen. Das Teil ist beim Runterfahren hängengeblieben. Die DS war nicht mehr erreichbar, aber die Festplatten LED zeigte immer noch Aktivität an. Also nach gut 15min beherzt den Strom gezogen. Die DS quittierte dies nach dem Neustart mit einem Notfallstop, weil sich diesmal die Systempartition verabschiedet hat. Also die Platte ausgebaut und an den Lapi mit Linux gehängt. Der folgende fschk fand etliche Fehler und die wurden gefixed. Danach bootete auch die DS wieder sauber.
Ich dachte dann, dass dies wohl an einem meiner cronjobs liegen könnte, denn es hat sich ja wieder die Part verabschiedet wo auch die Daten des crons liegen.
Aber um mir zu beweisen, dass ich falsch liege, verabschiedete sich letzte Nacht wieder das volume1. Nach dem obligaten Quotacheck, startete die DS aber wieder sauber.
Der e2fschk hat wieder "gelöschte Inodes mit zero dtime" gemeldet und die folgenden Fehler:
Block bitmap differences: -(192638976--192638989)
Fix? yes

Free blocks count wrong for group #5878 (32239, counted=32253).
Fix? yes

Free blocks count wrong (238127089, counted=238127103).
Fix? yes

Inode bitmap differences: -48152579
Fix? yes

Free inodes count wrong for group #5878 (8190, counted=8191).
Fix? yes

Free inodes count wrong (60479602, counted=60479603).
Fix? yes


1.41.3-1141: ***** FILE SYSTEM WAS MODIFIED *****
1.41.3-1141: 280461/60760064 files (0.3% non-contiguous), 4883257/243010360 blocks
Ich frage ganz blöd: Könnte es sein, dass der Quotacheck hier etwas verschlimmbessert hat? Oder greift der nicht schreibend auf das Dateisystem zu?
Und ja ich weiss, ich könnte das Problem wohl schneller lösen, wenn ich die Platte plätten würde und dann komplett neuinstallieren täte. Nur würde ich dem Übeltäter schon gerne auf die Schliche kommen :)

Danke für alle Tipps und Hilfen

tobi
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat