Nummer Serie DS414 - DS wacht dauernd aus dem Hibernate auf, sogar ohne Netzwerkanschluss

[Frogman]

... obwohl ich dachte, das man die Werte der /usr/syno/etc.defaults/scemd.xml ändern muß. Sicherungskopie ..

Damit liegst Du auch richtig! Die Datei unter /usr/syno/etc ist nur eine Kopie für die Systemwiederherstellung.

 

[Contra]

Ah ok, lag ich richtig. Ich glaube bald, das meine verbauten Festplatten einfach so laut sind, denn wenn die DS anspringt ist sie nicht zu hören, trotzdem die Lüfter drehen. Der Geräuschpegel ist aber noch auszuhalten im Gegensatz zu meiner uralt BuffaloLinkStation, die macht richtig Krach, hat auch nur einen Winzlüfter, der aber rauscht wie eine kleine Turbine.
Hauptsächlich kommts mir eben darauf an, die DS im Standby zu halten, ohne das sie dreimal hintereinander aufwacht oder zwischendrin immer mal wieder ungefragt den Schlaf unterbricht. Und das werde ich jetzt mit Daves Script mal versuchen, bin gestern nicht mehr dazu gekommen. Obs funzt werde ich berichten...

Gruß
Contra

 

[Contra]

Also ich würde sagen: Perfekt! It works like a charm!
Dave, hast du schon mal dran gedacht, dein Script oder besser den Fehler, den Synology mit seinem logging da fabriziert hat, den Leuten bei Synology nahezulegen?
Ich möchte mich auf jeden Fall nochmal bei dir bedanken, bis jetzt ist die DS nicht einmal ungefragt aufgewacht.

Gruß
Contra

 

[Contra]

Zu früh gefreut... DS wacht trotzdem immer wieder mal auf. Kann das am WOL liegen? Das da einige Chinakiddies nen Portscan machen?

 

[Frogman]

Sicher.

 

[Contra]

Habs grad mit abgezogenem LAN-Kabel probiert, springt trotzdem immer wieder an... ich verstehs nicht und die logfiles kann ich nicht interpretieren, jedenfalls scheints nicht an den Lüftern zu liegen... wasn ein scheiß, tschuldige die wortwahl aber so langsam kotzt es mich nur noch an. Ich hasse es ein nur halb fertiges Produkt zu haben und den Fehler nicht korrigieren zu können. Bleibt nur wieder die Kiste ganz auszumachen ggrrrrr

 

[IPMan]

Der syslog-Filter-Patch von dave82 greift vermutlich nicht unbedingt an der richtigen Stelle. Der "fan gpio detect ..." Log-Eintrag kommt bei mir als Folge des Aufwachens und nicht zuerst.

Jan 19 09:45:50 DS414-D scemd: manage_services.c:458 fan gpio detect thread exit
Jan 19 22:34:35 DS414-D scemd: event_disk_hibernation_handler.c:50 DS wakes up from disk deep sleep
Jan 19 22:34:44 DS414-D scemd: disk/disk_config_single.c:154 apply /usr/syno/bin/DiskApmSet.sh 255  /dev/sda 1>/dev/null 2>&1
Jan 19 22:34:58 DS414-D scemd: manage_services.c:458 fan gpio detect thread exit
Jan 19 22:34:59 DS414-D scemd: event_disk_hibernation_handler.c:32 The internal disks wake up from hibernation.
Jan 19 22:35:03 DS414-D scemd: disk/disk_config_single.c:154 apply /usr/syno/bin/DiskApmSet.sh 255  /dev/sdc 1>/dev/null 2>&1
Jan 19 22:35:03 DS414-D scemd: disk/disk_config_single.c:154 apply /usr/syno/bin/DiskApmSet.sh 255  /dev/sdb 1>/dev/null 2>&1
Jan 20 05:36:37 DS414-D scemd: event_disk_hibernation_handler.c:50 DS wakes up from disk deep sleep

Das kann aber auch anders sein wenn ein Lüfterfehler festgestellt wird oder wenn der Eintrag verzögert ins log geschrieben wird. Dann erfüllt der Patch möglicherweise doch seinen Zweck...

IPMan

 

[dave82]

Der syslog-Filter-Patch von dave82 greift vermutlich nicht unbedingt an der richtigen Stelle. Der "fan gpio detect ..." Log-Eintrag kommt bei mir als Folge des Aufwachens und nicht zuerst.

Jan 19 09:45:50 DS414-D scemd: manage_services.c:458 fan gpio detect thread exit
Jan 19 22:34:35 DS414-D scemd: event_disk_hibernation_handler.c:50 DS wakes up from disk deep sleep
Jan 19 22:34:44 DS414-D scemd: disk/disk_config_single.c:154 apply /usr/syno/bin/DiskApmSet.sh 255  /dev/sda 1>/dev/null 2>&1
Jan 19 22:34:58 DS414-D scemd: manage_services.c:458 fan gpio detect thread exit
Jan 19 22:34:59 DS414-D scemd: event_disk_hibernation_handler.c:32 The internal disks wake up from hibernation.
Jan 19 22:35:03 DS414-D scemd: disk/disk_config_single.c:154 apply /usr/syno/bin/DiskApmSet.sh 255  /dev/sdc 1>/dev/null 2>&1
Jan 19 22:35:03 DS414-D scemd: disk/disk_config_single.c:154 apply /usr/syno/bin/DiskApmSet.sh 255  /dev/sdb 1>/dev/null 2>&1
Jan 20 05:36:37 DS414-D scemd: event_disk_hibernation_handler.c:50 DS wakes up from disk deep sleep

Das kann aber auch anders sein wenn ein Lüfterfehler festgestellt wird oder wenn der Eintrag verzögert ins log geschrieben wird. Dann erfüllt der Patch möglicherweise doch seinen Zweck...

IPMan

Hi IPMan,

ja das stimmt, bei mir kommt die Lüfter-Meldung mal vor und mal nach der Wakeup-Meldung. Vermutlich hängt es irgendwie mit Verzögerung beim Schreiben auf die Platten zusammen. Erklären kann ich mir das nicht.

Bis dahin wirkt der Filter bei mir ausgezeichnet, war am Wochenende nicht zuhause und die DS ist kein einziges mal ungefordert aufgewacht. (nur einmal zum Check nach Firmwareupdates)

Ich kann immernoch nicht glauben das die Meldung mit einem Lüfterfehler zusammenhängt. Wie gesagt, der Fehler besteht seit dem ich die DS habe, diese wurde einmal bei Amazon komplett gegen eine neue umgetauscht, ohne Erfolg. Danach hat mir der Support nochmal zwei Lüfter geschickt. Letztendlich habe ich die Noctua (?) verbaut wegen der Lautstärke. Die Meldung war immer da.

Gruß Dave

 

[Skyless]

Hallo Leute,

bin neu im Forum und habe schon viel über das Hypernate-Problem gelesen. Ich habe eine 415play, und bei der ist es genauso. Ich konnte das Problem auf den PLEX-Server eingrenzen, durch deaktivieren und aktivieren einzelner Dienste.
Immer wenn Plex läuft, wachen die Plattenexakt alle30 Minuten auf. Deaktiviere ich den Dienst, machen sie es nicht mehr, obwohl ich hardwareseitig nichts ändere, und auch die DS per Quickconnect erreichbar ist. Alles kein Problem, bis auf Plex.

Jemand eine Idee?

 

[Frogman]

Nö, warum auch - Plex ist seit Urzeiten als Störenfried bekannt.

 

[Skyless]

Ok, war mir nicht bekannt. Einzige Grund warum ich Plex nutze ist, weil die Videostation bei der Transcodierung kein DTS Ton wiedergibt. Ich würde auch gern die Videostation nutzen, hat jemand eine Idee dort den Ton in den Griff zu bekommen?

 

[MMD*]

http://packages.mdevries.org/

 

[McGurk]

Hi Contra,

ja klar, kein Problem. Das Skript hilft dir aber nur wenn der Logeintrag "fan gpio detect thread exit" den Wakeup auslöst!

Anbei das Skript und die Anleitung. Heute Nacht hatte ich keinen einzigen Wakup der Platten.

1. Die angehängte Datei scemd_syslog_filter_DSM5_1.zip herunterladen und entpacken. Dann auf die DS hochladen z.B. in den Gemeinsamen Ordner „public“.
Falls ein anderer Ordner verwendet wird, muss dieser in den Befehlen verwendet werden.
2. Telnet oder SSH aktiveren
3. Als User Root auf die Konsole verbinden
4. mv /volume1/public/S99set_scemd_syslog_filter.sh /usr/syno/etc/rc.d/
5. chown root:root /usr/syno/etc/rc.d/S99set_scemd_syslog_filter.sh
6. chmod 755 /usr/syno/etc/rc.d/S99set_scemd_syslog_filter.sh
7. exit
8. Telnet oder SSH deaktivieren
9. Reboot

Das Skript arbeitet als Startupscript und erweitert den Syslog Filter für die Scemd Messages, d.h. der Syslog schreibt die Meldungen mit dem Keyword "gpio" nicht mehr auf die Platte. Somit sind die dadurch ausgelösten Wakeups bei mir weg. Die Lösung ist nicht schön, habe aber keine Zeit das noch besser oder komfortabler zu lösen.

Falls du alles wieder rückgängig machen willst, dann einfach auf der Konsole folgende Befehle absetzen:

1. /usr/syno/etc/rc.d/S99set_scemd_syslog_filter.sh stop
2. rm /usr/syno/etc/rc.d/S99set_scemd_syslog_filter.sh
3. reboot

Anhang anzeigen 21737

Gruß Dave

Hallo,

habe mir eine gebrauchte DS414 zugelegt und wollte nur mal vermelden, dass das Skrpit unter der aktuellen DSM immernoch perfekt funktioniert. EInbindung des Skripts über die Oberfläche als ausgelöstes Ereignis! Keine unnötigen Wakeups mehr! Vielen Dank dafür!