DS immer wieder nicht erreichbar (Absturz?)

[ottomane]

Hallo,

meine DS 213+ kann ich nach einem Neustart nur kurz erreichen (sofort oder nach einigen Minuten ist sie wieder bis auf Ping unerreichbar).

Auf Ping antwortet sie dauerhaft.
Auf Anfragen per HTTP/HTTPS, SMB, SSH usw. folgt nach anfänglich normaler Funktion dann plötzlich keine Reaktion mehr.

Nur ein harter Neustart hilft, aber auch nur kurz.

Platten sind laut Schnelltest OK. Im Protokoll habe ich nichts auffälliges gefunden. DSM ist die für die 213+ aktuellste Version. Ich nutze im wesentlichen Cloud Station intensiv. Sonst kaum Pakete installiert.

Hat jemand eine Idee, was ich tun kann? In welchen Systemlogs kann ich Hinweise auf die Ursache finden?

Danke vorab für jede Idee!

VG
om

 

[Wollfuchs]

/var/log/messages ?

 

[ottomane]

OK, ich boote das Ding nochmal und schaue, ob ich rankomme....

 

[ottomane]

So, das hat geklappt. Ich habe mir das mal angesehen und fand nur folgende Dinge, die auf Fehler hinweisen:


2020-12-12T18:10:08+01:00 HAL-1 synodrivehook: synodrivehook.cpp:211 Failed [FALSE == SLIBServiceIsRunning(SZ_PGSQL_SERVICE_NAME)], err=No such file or directory

2020-12-12T18:11:01+01:00 HAL-1 hotplugd: scemd_connector/scemd_connector.c:143 Fail to sendto() for scemd connector client.

2020-12-12T18:11:15+01:00 HAL-1 syno-cloud-syncd: [ERROR] main.cpp(164): cannot find pid int pid file at '/var/run/syno-cloud-syncd.pid', daemon is not running

2020-12-12T18:14:00+01:00 HAL-1 syno_smart_test: syno_smart_test.c:69 --force wrong format
2020-12-12T18:37:34+01:00 HAL-1 syno_smart_test: syno_smart_test.c:69 --force wrong format
2020-12-12T18:41:07+01:00 HAL-1 syno_smart_test: syno_smart_test.c:69 --force wrong format
(alle drei direkt hintereinander, danach endet das Log bis zum Reboot)


EDIT: Die Datei /var/run/syno-cloud-syncd.pid' wurde inzwischen angelegt und existiert.

Hm. So richtig Verdächtiges sehe ich ehrlich gesagt nicht.

 

[Wollfuchs]

wenn danach nix mehr kommt .. wuerde ich mal das Netzteil checken.
ploetzliches ausschalten riecht nach strom. aber wenn ping noch geht,
dann scheidet das eigentlich aus ... vermutlich.

ansonsten . hmm .. macht er nach dem reboot einen check der disks,
ist da was in den smart werten auffaellig? viele reconnects von einer
platte?

was ist denn "ploetzlich" .. laeuft die ne stunde .. tage .. wochen und
dann ist sie nicht mehr erreichbar oder eher minuten ..

ist ein ruhezustand definiert fuer die karre? falls ja, abschalten und
kucken ob die nur "nicht mehr hoch kommt".

Nachtrag fuer Mutige:
Was passiert, wenn Du den smart_test selber aufrufst, also den letzten
Eintrag quasi gezielt durchfuehrst?

in /usr/syno/bin liegt ja die syno_smart_test .. die mal mit --type=quick --disk=all
auf die Karre loslassen und wenn sie dann nicht mehr erreichbar ist, anzuenden.

 

[ottomane]

wuerde ich mal das Netzteil checken.

Guter Punkt. Das ist ein NoName-Ersatznetzteil, was schon einige Jahre auf dem Buckel hat. Vielleicht reicht die Spannung nicht mehr und die DS stürzt "halb" ab.

macht er nach dem reboot einen check der disks,
ist da was in den smart werten auffaellig? viele reconnects von einer
platte?

Von einem Check sehe ich nichts. Wonach müsste ich suchen?

Ich fand allerdings dies hier:

2020-12-12T19:45:32+01:00 HAL-1 kernel: [ 26.370362] vender Mac1 checksum error ucSum:0x00 Buf:0x00 Sum:0.
2020-12-12T19:45:32+01:00 HAL-1 kernel: [ 26.376473] vender Mac2 checksum error ucSum:0x00 Buf:0x00 Sum:0.
2020-12-12T19:45:32+01:00 HAL-1 kernel: [ 26.382559] vender Mac3 checksum error ucSum:0x00 Buf:0x00 Sum:0.
...
2020-12-12T19:45:32+01:00 HAL-1 kernel: [ 26.657561] md: invalid raid superblock magic on sda3
2020-12-12T19:45:32+01:00 HAL-1 kernel: [ 26.662611] md: sda3 does not have a valid v0.90 superblock, not importing!
2020-12-12T19:45:32+01:00 HAL-1 kernel: [ 26.701121] md: invalid raid superblock magic on sdb3
2020-12-12T19:45:32+01:00 HAL-1 kernel: [ 26.706170] md: sdb3 does not have a valid v0.90 superblock, not importing!
2020-12-12T19:45:32+01:00 HAL-1 kernel: [ 26.727161] md: sda2 has different UUID to sda1
2020-12-12T19:45:32+01:00 HAL-1 kernel: [ 26.734926] md: sdb2 has different UUID to sda1
...
2020-12-12T19:45:38+01:00 HAL-1 kernel: [ 50.054276] init: syno-auth-check main process (1547) killed by TERM signal

Reconnects habe ich gelegentlich, ja. Das habe ich irgendwann als "normal" abgehakt

Bei LW1 hatte ich drei Reconnects im März. Dies ist LW2:

was ist denn "ploetzlich" .. laeuft die ne stunde .. tage .. wochen und
dann ist sie nicht mehr erreichbar oder eher minuten ..

Das Problem fing erst gestern abend an. Die Laufzeiten sind grob zwischen 2 Stunden und 5 Minuten. Ich habe das Log mal weiter erforscht. Es endet vor dem Reboot immer mit irgendeiner anderen Meldung, also kommt der Stopp urplötzlich.

Ich habe einen HDD-Ruhezustand von 2h eingestellt. Aber das ist schon ewig so. Ich schalte den mal ab und beobachte.

Und ich werde testen, ob es irgendwie mit Cloud Station zusammenhängt. Seit gestern abend habe ich da einen größeren Job laufen und vielleicht besteht da ja ein Zusammenhang (--> vielleicht zum Stromproblem, weil sie gefordert ist).


Allerbesten Dank für deine Hilfe!!

 

[Wollfuchs]

ich hatte oben noch nachgetragen:
Was passiert, wenn Du den smart_test selber aufrufst, also den letzten
Eintrag quasi gezielt durchfuehrst?

in /usr/syno/bin liegt ja die syno_smart_test .. die mal mit --type=quick --disk=all
auf die Karre loslassen und wenn sie dann nicht mehr erreichbar ist, anzuenden.

mich wundert, dass in der Webansicht des Speichermanagers halt nix rot oder
orange leuchtet .. bei bad superblock haette ich vermutet, dass es das Raid zerlegt
hat.

Das sind aber nicht zufaellig Seagate Platten?

Falls ne Komplettsicherung existiert .. mach die Kiste halt platt

 

[ottomane]

Rumms, sie ist wieder weg.

Ruhezustand war abgeschaltet. Der Absturz erfolgte kurz nachdem ich das Cloud Station Drive am Rechner wieder gestartet habe. Das nudelt minutenlang mit immer den vier selben Dateien herum. Irgendwann verliert er die Verbindung. Nix sinnvolles im Log.

Zum Nachtrag: Den Check werfe ich gleich mal an.

Ich habe gar kein RAID, mich wundert der Eintrag mit dem Superblock. Die eine Platte ist tatsächlich orange, aber es sind noch 100+ GB frei, insofern sollte das kein Probem sein. Es sind WD Red-Platten.


EDIT: Der Test meckert im Log:

2020-12-12T21:04:57+01:00 HAL-1 syno_smart_test: smartctl/smartctl_selftest_log_read.c:38 open /dev/sda failed.
2020-12-12T21:04:57+01:00 HAL-1 syno_smart_test: syno_smart_test.c:86 Failed to get test log report
2020-12-12T21:04:57+01:00 HAL-1 syno_smart_test: smartctl/smartctl_selftest_log_read.c:38 open /dev/sdb failed.
2020-12-12T21:04:57+01:00 HAL-1 syno_smart_test: syno_smart_test.c:86 Failed to get test log report
--> fehlte nur das sudo

Test ist nun gelaufen, aber wo sind Ergebnisse? OK, ich sehe in DSM, dass er testet. Keine aktuellen Probleme.


Die Platten sind also irgendwie abgemeldet. WTF?! --> Netzteil? Ich könnte ja mal testweise ein neues besorgen.

Nun ist auch SSH gestorben.

PS: Backups habe ich natürlich. Aber den Aufwand scheue ich doch sehr. Oder ich kaufe mir gleich eine neue DS220+

EDIT2: Mir fällt gerade auf, wo ich ans Netzteil denke. Die DS hängt an einer USV. Vielleicht hat die ein Problem.... EDIT4: Konnte ich gerade ausschließen.

EDIT3: Die Meldung mit dem invalid superblock kommt im Log schon immer bei jedem Reboot. Das ist vermutlich also nicht das jetzige Problem.

EDIT5: Problem lässt sich 100% durch Start des Cloud Station Drive Client reproduzieren. Er klemmt lange an 4 Dateien ("Vorbereiten"), dann stürzen die Dienste der DS ab.

 

[ottomane]

So, ich habe mal Cloud Station Server und auch den Client komplett neu konfiguriert.

Im Moment synchronisieren die beiden sich erst einmal für ein paar Stunden. Das läuft aber bisher problemlos. Hoffe, dass es so bleibt.

Vielleicht gab es irgendeinen Fehler in der Datenbank oder so. Vielleicht ist auch die DS213+ mit dem Umfang des Datenbestands (30GB, zw. 50.000 und 100.000 Dateien) überfordert und sie verschluckt sich irgendwann. Synology rät ja dazu, die 213+ nicht mit mehr als 50.000 Dateien zu syncen.

Anschließend werde ich einen Test machen.

 

[ottomane]

Ergebnis: Die DS läuft wieder stabil. Cloud Station Drive funktioniert ebenfalls wieder. Warum die ganze DS crasht, wenn Cloud Station ein Problem hat, bleibt ein Rätsel.