j-Serie DS215j legt sich nicht mehr schlafen

[beaviz]

Hi!

Ich habe eine DS215j mit DSM 6.0.2-8451 Update 1.

Ich habe das Gefühl dass mein NAS nicht mehr in den Sleep-Mode geht.

Einzig die Einstellung unter Hardware & Energie --> Ruhezustand der Festplatte habe ich auf 10min gestellt.

Den Artikel von Synology warum das NAS nicht schlafen geht habe ich schon gelesen und bin alle meiner Meinung nach relevanten Punkte durchgeschaut und konnte auch nix finden.

Ich habe das Gefühl das seit den letzten Updates sich irgendwas geändert hat und es daher nicht funktioniert.

Ich habe aber auch keinen Beweis dass es nicht funktioniert, es kommt mir nur seltsam vor, da es oft so ist wenn ich nach Hause komme eigentlich keine geplanten Jobs auf dem NAS laufen und normalerweise auch keine Geräte mit dem NAS eine Verbindung haben sollten...

Kann ich irgendwo nachvollziehen ob (ich mich täusche) das NAS doch in den Sleep geht bzw. kann ich irgendwo sehen warum es möglicherweise verhindert wird?

Gern poste ich auch Logs etc wenn gewünscht. Ich habe soeben nochmal alle Optionen durchgeschaut aber komme einfach nicht weiter.


Beste Grüße
beaviz

 

[dil88]

Hast Du Portforwards auf die DS in Deinem Router definiert?

 

[beaviz]

Ja habe ich, aber auch schon Ewigkeiten die selben.

Einmal für VPN und einmal für den Zugriff auf die Weboberfläche...

 

[dil88]

Dann nimm die testweise einmal heraus und schau, ob es etwas ändert.

 

[beaviz]

Mach ich, aber gibt es keine Logs in die ich schauen kann ob ich mich nicht sogar täusche und es einfach nur Zufälle waren dass das NAS in den Momenten immer lief in denen ich dachte dass es im Sleep sein müsste?

 

[dil88]

Klar, aber da steht nur drin, dass die DS zu Zeitpunkt x aufgewacht ist, nicht aber warum. Schau Dir dazu das Logfile /var/log/scemd.log an - entweder per Shell oder unter Windows z.B. mit WinSCP.

 

[beaviz]

Hi!

Vielen Dank für den Tip!

Ich habe hier mal die letzten Zeilen des Logs...

Was mir auffällt, laut Log wurde das NAS zum letzten Mal am 10.09. aus Hibernate aufgeweckt... Am Anfang des Logs (als auch nach meinem subjektiven Empfinden) noch alles korrekt funktionierte passierte das 2-3 mal am Tag.

Die restlichen Zeilen kann ich noch nicht richtig interpretieren...

2016-09-10T20:02:32+02:00 Der-Speicher scemd: event_disk_hibernation_handler.c:42 The internal disks wake up, hibernate from [Sep 10 19:53:02]
2016-09-10T20:02:32+02:00 Der-Speicher scemd: disk/disk_config_single.c:187 apply /usr/syno/bin/syno_disk_ctl --ncq-off /dev/sdb 1>/dev/null 2>&1
2016-09-10T20:02:32+02:00 Der-Speicher scemd: disk/disk_config_single.c:187 apply /usr/syno/bin/DiskApmSet.sh 255 /dev/sda 1>/dev/null 2>&1
2016-09-10T20:02:33+02:00 Der-Speicher scemd: disk/disk_config_single.c:187 apply /usr/syno/bin/syno_disk_ctl --ncq-off /dev/sda 1>/dev/null 2>&1
2016-09-13T09:26:25+02:00 Der-Speicher scemd: space_info_enum.c:109 failed to check virtual space. [0x0900 file_get_key_value.c:29]
2016-09-14T02:08:54+02:00 Der-Speicher scemd: space_info_enum.c:109 failed to check virtual space. [0x0900 file_get_key_value.c:29]
2016-09-18T02:16:29+02:00 Der-Speicher scemd: space_info_enum.c:109 failed to check virtual space. [0x0900 file_get_key_value.c:29]
2016-09-19T22:48:31+02:00 Der-Speicher scemd: fan_config_get.c:49 Type: INTERNAL Fan Mode: LOW_STOP
2016-09-19T22:48:35+02:00 Der-Speicher scemd: manage_services.c:459 fan gpio detect thread exit
2016-09-20T08:37:57+02:00 Der-Speicher scemd: manage_services.c:496 fan gpio detect thread 836760592 created
2016-09-20T08:43:50+02:00 Der-Speicher scemd: manage_services.c:459 fan gpio detect


Sieht hier schon jemand etwas Auffälliges?

 

[Red5FS]

Hi,
hast Du mal das LAN Kabel abgezogen und geschaut, ob die DS sich dann schlafen legt?
Ich hatte vor längerer Zeit auch ein ähnliches Problem. In meinem Router hatte ich wohl eine Portfreigabe, die dafür verantwortlich war. Durch das LAN Kabel abziehen weist du, obs von "außerhalb" kommt oder aber eine Einstellung der DS sein sollte. Das DS-Cloud hatte bei mir auch ständig die Kiste wieder aufgewacht.

Gruß Red5FS

 

[beaviz]

das probiere ich gleich mal...

Meldung kommt dann in den nächsten Minuten

 

[bfpears]

2016-09-10T20:02:32+02:00 Der-Speicher scemd: event_disk_hibernation_handler.c:42 The internal disks wake up, hibernate from [Sep 10 19:53:02]

Also bei mir ist fast nur diese Zeile im Log.

Schon den Klassiker mit aus und einschalten probiert?
RAID in Ordnung?

 

[beaviz]

das ist schon freaky.

Ich komme gerade in meine Wohnung, wollte den Test mit dem gezogenen LAN-Kabel machen und sehe gerade dass es im Sleep ist...

Also geht es doch??? Mich wundert nur dass es seit mehreren Tagen nicht mehr in den Sleep ging...

Was bedeuten die anderen Zeilen in meinem Log?

BTW: Mir ist aufgefallen dass ich am 10.09. das letzte Update installiert habe und seitdem das NAS nicht mehr im Sleep war. Gestern Abend habe ich es mal gerebootet. Ich guck gleich nochmal ins Log ob sich seit gestern Abend was geändert hat.

Das RAID guck ich mir auch gleich mal an, weil die anderen Zeilen im Log mich irgendwie irritieren. Ich mache jedoch regelmäßig und automatisch SMART-Checks und bisher wurden mir noch keine Fehler reported...

Melde mich gleich wieder nachdem ich mir das Log nochmal angeschaut habe, evtl. hat der Reboot ja was gebracht...


Update: Log sieht m. E. n. nun, seit dem Reboot wieder gut aus. Mir ist das garnicht im Zusammenhang mit dem letzten Update aufgefallen, aber wirklich seit dem Update legte es sich ganze Zeit nicht mehr schlafen...

RAID ist laut Speichermanager in Ordnung genau so wie die Platten selbst...

Schon komisch dass das seit Install letztes Update diese Probleme gab.


BTW:

Ich habe öfters diese Zeilen bei mir im Log zwischen den hibernation-Einträgen:

2016-09-21T19:18:29+02:00 XXXXXX scemd: disk/disk_config_single.c:187 apply /usr/syno/bin/DiskApmSet.sh 255 /dev/sdb 1>/dev/null 2>&1
2016-09-21T19:18:29+02:00 XXXXXX scemd: disk/disk_config_single.c:187 apply /usr/syno/bin/syno_disk_ctl --ncq-off /dev/sdb 1>/dev/null 2>&1

Ich habe WD-RED-Platten im Einsatz, die sollten doch NCQ können? Hat hier jemand das gleiche in seinen Logs?

BTW2: Das eigentliche Problem scheint sich durch den Reboot gelöst zu haben