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

[dave82]

Hi dave,

Ich habe dasselbe Problem mit meiner DS414, und dabei ist mir folgendes aufgefallen:
Bei mir stellt sich der fan-check manchmal von selbst ab, das sieht dann in so in den logs aus

Jan 28 12:39:31 susuwatari scemd: modules/fan_check_common.c:664 skip fan fail detect since operation temperature too low

und ab diesem Zeitpunkt (bis zum nächsten Reboot) tritt das Problem

Feb 10 20:42:49 susuwatari scemd: modules/fan_check_common.c:650 Start fan full speed to avoid fan fail
Feb 10 20:42:55 susuwatari scemd: modules/fan_check_common.c:654 Stop fan full speed to avoid fan fail

dann nicht mehr auf.

Ich würde in deinem Fall also einmal überprüfen, ob es wirklich der Log-Filter ist, der Besserung bringt. Bei mir habe ich (als ich damit herumgespielt habe — kann ich mich natürlich auch verbastelt haben) die fan_check-Nachrichten des scemd dann in /var/log/messages gefunden (anstatt sie komplett unterdrückt zu haben).

Weiterhin meldet mir syslog-ng einen Hinweis auf einen ungeschickt formulierten Filter; ich habe /usr/syno/etc/rc.d/S21set_scemd_syslog_filter.sh wie folgt angepasst:

#!/bin/sh
sed -i -e 2c'filter f_scemd { level(err..emerg) and program(scemd) and not match ("fan_check_common" value(MESSAGE)); };' /usr/syno/etc/synosyslog/syslog.d/scemd.conf

Ich habe vom Synology-Support einen Austauschlüfter zugesandt bekommen, vielleicht tausche ich die im Wechsel einmal aus, aber viel Hoffnung mache ich mir da nicht...

Hi y__y,

bei mir stellte sich der fan_check nicht von selbst ab. Ich habe damit seit meinem Kauf im Januar nur Ärger gehabt. Selbst der Austausch der kompletten DS hat nichts gebracht. Einzig meine Lösung den Logfilter zu setzten hat mir geholfen.
An der Lösung die ein paar Seiten vorher gepostet habe inkl. Zip-File musst du nichts "herumbasteln". Bitte poste mal den Hinweis den dir der Syslog meldet. Auch wäre die Filtereinstellung interessant mit der du "gespielt" hattest.

Gruß Dave

 

[dave82]

Hi Dave,

danke für die Tipps, die Einstellung im Router gibts bei mir zwar nicht, aber ich hab zwei Ports geöffnet, gut möglich das da mal gelauscht wird...
Dann werd ich wohl VPN einrichten müssen. Aber erst mach ich mich mal kundig wies genau funktioniert...
Ansonsten alles ok mit dem neuen Patch?

Gruß
Contra

Hi Contra,

bis heute läuft alles bestens. So hätte das von Anfang an sein sollen!
Wegen dem VPN gibt es echt eine Menge Threads hier, vielleicht hängst du dich lieber dort dran. Hier würde es nur unübersichtlicht werden.

Gruß Dave

 

[dave82]

@dave82,

das hast Du sehr schön gelöst, vielen Dank für diesen Patch.

Da jetzt diese Variante das Lüfterproblem löst, kann ich nur jedem abraten den Wert "....hibernation_speed="UNKNOWN" zu ändern.
Der Grund ist die damit verbunden Abschaltung der Temperaturreglung. Ich habe die DS mit eine Fön im Standby erwärmt und es erfolgte KEINE Reaktion.

Ich habe gelesen das die Stufen der Lüfterreglung erweitert werden kann und nicht auf maximal 10 Einträge begrenzt ist - weiß das jemand genau?

	<fan_config period="20" threshold="6" type="DUAL_MODE_LOW" hibernation_speed="UNKNOWN">
		<disk_temperature fan_speed="00%40hz"    action="NONE">30</disk_temperature>
		<disk_temperature fan_speed="11%40hz"    action="NONE">35</disk_temperature>
		<disk_temperature fan_speed="22%40hz"    action="NONE">40</disk_temperature>
		<disk_temperature fan_speed="33%40hz"    action="NONE">45</disk_temperature>
		<disk_temperature fan_speed="55%40hz"    action="NONE">50</disk_temperature>
		<disk_temperature fan_speed="77%40hz"    action="NONE">55</disk_temperature>
		<disk_temperature fan_speed="99%40hz"    action="NONE">59</disk_temperature>
		<disk_temperature fan_speed="99%40hz"    action="SHUTDOWN">61</disk_temperature>
		<cpu_temperature fan_speed="00%40hz"     action="NONE">40</cpu_temperature>
		<cpu_temperature fan_speed="11%40hz"     action="NONE">45</cpu_temperature>
		<cpu_temperature fan_speed="22%40hz"     action="NONE">50</cpu_temperature>
		<cpu_temperature fan_speed="33%40hz"     action="NONE">55</cpu_temperature>
		<cpu_temperature fan_speed="55%40hz"     action="NONE">65</cpu_temperature>
		<cpu_temperature fan_speed="77%40hz"     action="NONE">75</cpu_temperature>
		<cpu_temperature fan_speed="99%40hz"     action="NONE">85</cpu_temperature>
		<cpu_temperature fan_speed="99%40hz"     action="SHUTDOWN">95</cpu_temperature>
	</fan_config>

Damit schaltet sich der Lüfter nach Bedarf zu und wieder ab - auch im Standby.
Ich habe gerade den Prozessor einige Zeit zu 100% ausgelastet ohne das seine Temperatur über 40°C gestiegen ist bei 11% Lüfteransteuerung.
Somit könnten einige Stufen bei der "cpu_temperature..." entfallen - sollte die Anzahl der Aktionen auf <16 limitiert sein. Momentan läuft aber alles unauffällig und scheinbar perfekt.

MfG
IPMan

Hi IPMan,

danke für die Info. Deine Settings sehen sehr interessant aus, werde diese nächste Woche mal testen. Sind die Lüfter bei dir bis 30°C im Hibernate aus? Du betreibst die DS glaub ich im Keller oder?

Gruß Dave

 

[y__y]

Bitte poste mal den Hinweis den dir der Syslog meldet.

Die Warnung die syslog-ng ausspuckt (in /var/log/syslog.log) ist folgende:

Feb 22 22:42:29 susuwatari syslog-ng[1036]: WARNING: the match() filter without the use of the value() option is deprecated and hinders performance, please update your configuration;

Auch wäre die Filtereinstellung interessant mit der du "gespielt" hattest.

Das Einzige, was ich an deinem Filter verändert habe ist (wie in meinem Post geschrieben) das Hinzufügen der "value(MESSAGE)" Direktive in den Filter. Trotzdem wurde bei mir die fan_check_common Meldung in /var/log/messages geposted. Was ich mir nicht erklären kann, ist warum das bei dir nicht auftritt.

Ich vermute, es passiert folgendes:

• syslog-ng.conf wird gelesen
• Dort wird ein Filter "filter f_scemd { program(scemd); };" definiert, der wiederum von f_synology genutzt wird: filter f_synology { filter(f_scemd); };
• Dieser wird nun gebraucht, um zu beschreiben, was nicht in /var/log/messages geschrieben werden soll: filter f_messages { level(warn..emerg) and not facility(auth, authpriv, mail, news, cron) and not program(syslog-ng) and not filter(f_local) and not filter(f_synology); };
• Momentaner Stand von /var/log/messages: Alles was nicht von scemd kommt, geht hier rein.
• Nun werden die Unterkonfigurationen eingebunden: "include "/etc/syslog-ng/patterndb.d/";", also u.a. /etc/syslog-ng/patterndb.d/scemd.conf
• Jetzt wird der f_scemd filter überschrieben mit: filter f_scemd { level(err..emerg) and program(scemd) and not match ("fan_check_common" value(MESSAGE)); };
• Die Krux ist: Dieser Filter wird jetzt auch benutzt, um zu bestimmen, was in /var/log/messages kommt. Und das ist alles vom Program scemd was NICHT fan_check_common enthält. Folglich landet die fan_check_common-Meldung nun hier.

Ich konnte das bei mir umgehen, indem ich den Filter in /etc/syslog-ng/patterndb.d/scemd.conf umbenannt habe, damit er den originalen Filter nicht überschreibt:

destination d_scemd { file("/var/log/scemd.log"); };
filter f_scemd2 { level(err..emerg) and program(scemd) and not match ("fan_check_common" value(MESSAGE)); };
log { source(src); filter(f_scemd2); destination(d_scemd); };

Und dies verhindert bei mir nun das sofortige Wiedererwachen aus dem Schlafmodus durch das Hochdrehen der Lüfter.

 

[dave82]

Die Warnung die syslog-ng ausspuckt (in /var/log/syslog.log) ist folgende:

Feb 22 22:42:29 susuwatari syslog-ng[1036]: WARNING: the match() filter without the use of the value() option is deprecated and hinders performance, please update your configuration;

Das Einzige, was ich an deinem Filter verändert habe ist (wie in meinem Post geschrieben) das Hinzufügen der "value(MESSAGE)" Direktive in den Filter. Trotzdem wurde bei mir die fan_check_common Meldung in /var/log/messages geposted. Was ich mir nicht erklären kann, ist warum das bei dir nicht auftritt.

Ich vermute, es passiert folgendes:

• syslog-ng.conf wird gelesen
• Dort wird ein Filter "filter f_scemd { program(scemd); };" definiert, der wiederum von f_synology genutzt wird: filter f_synology { filter(f_scemd); };
• Dieser wird nun gebraucht, um zu beschreiben, was nicht in /var/log/messages geschrieben werden soll: filter f_messages { level(warn..emerg) and not facility(auth, authpriv, mail, news, cron) and not program(syslog-ng) and not filter(f_local) and not filter(f_synology); };
• Momentaner Stand von /var/log/messages: Alles was nicht von scemd kommt, geht hier rein.
• Nun werden die Unterkonfigurationen eingebunden: "include "/etc/syslog-ng/patterndb.d/";", also u.a. /etc/syslog-ng/patterndb.d/scemd.conf
• Jetzt wird der f_scemd filter überschrieben mit: filter f_scemd { level(err..emerg) and program(scemd) and not match ("fan_check_common" value(MESSAGE)); };
• Die Krux ist: Dieser Filter wird jetzt auch benutzt, um zu bestimmen, was in /var/log/messages kommt. Und das ist alles vom Program scemd was NICHT fan_check_common enthält. Folglich landet die fan_check_common-Meldung nun hier.

Ich konnte das bei mir umgehen, indem ich den Filter in /etc/syslog-ng/patterndb.d/scemd.conf umbenannt habe, damit er den originalen Filter nicht überschreibt:

destination d_scemd { file("/var/log/scemd.log"); };
filter f_scemd2 { level(err..emerg) and program(scemd) and not match ("fan_check_common" value(MESSAGE)); };
log { source(src); filter(f_scemd2); destination(d_scemd); };

Und dies verhindert bei mir nun das sofortige Wiedererwachen aus dem Schlafmodus durch das Hochdrehen der Lüfter.

Hi y__y,

danke für die ausführliche Beschreibung. Ich werde das die Woche mal überprüfen. Fürs erste kann ich bestätigen das ich die Meldung

WARNING: the match() filter without the use of the value() option is deprecated and hinders performance, please update your configuration;

auch im Syslog habe. Scheinbar nur wenn der Daemon gestartet wird, also bei einem Neustart. Die fan_check-Meldung allerdings ist bei mir weder im scemd.log noch in messages zu finden. Mir hat bisher auch etwas Zeit gefehlt das komplette Logging der DS tiefer zu analysieren.

Eigentlich hatte ich gehofft das ich eine akzeptable Lösung vom Support erhalte.

Gruß Dave

 

[Contra]

Hi Dave

hast ja recht, das mit dem VPN ist ne eigene Sache, wenns da Probleme gibt werde ich nen eigenen Thread aufmachen. Mir ist aber jetzt aufgefallen, das ich die Funktion oder Option "Diesen Computer starten..." in der Fritzbox doch hatte. Das hab ich jetzt mal ausgestellt und werde testen, ob sie immer noch ohne Grund aufwacht.

Freut mich ja, das es so gut mit dem Patch läuft, und das sich noch andere Leuts damit auskennen und notfalls etwas berichtigen können.

Gruß
Contra

 

[Contra]

Hallo,

nur nochmal zur Info, ich hab die Ports an der Fritzbox deaktiviert und siehe da, kein ungewolltes WOL mehr. Scheint wohl wirklich so, das da jemand die Ports scannt und dann MagicPackets verschickt. Nun, ich hab ja noch die Möglichkeit des VPN...

Der Support hat sich auch gemeldet und bietet mir an, einen neuen Lüfter zu schicken. Ich hab sofort zurückgeschrieben, das er gleich zwei neue versenden soll, weil ich ja nicht weiß, welcher denn jetzt den Streß macht. Viel Hoffnung setze ich in diese Lösung nicht, aber versuchen werd ichs. Wünscht mir Glück^^

Gruß
Contra

 

[dave82]

Hallo,

nur nochmal zur Info, ich hab die Ports an der Fritzbox deaktiviert und siehe da, kein ungewolltes WOL mehr. Scheint wohl wirklich so, das da jemand die Ports scannt und dann MagicPackets verschickt. Nun, ich hab ja noch die Möglichkeit des VPN...

Der Support hat sich auch gemeldet und bietet mir an, einen neuen Lüfter zu schicken. Ich hab sofort zurückgeschrieben, das er gleich zwei neue versenden soll, weil ich ja nicht weiß, welcher denn jetzt den Streß macht. Viel Hoffnung setze ich in diese Lösung nicht, aber versuchen werd ichs. Wünscht mir Glück^^

Gruß
Contra

Hi Contra,

welche Ports für welche Dienste hattest du eigentlich offen bzw. geforwardet? Dann mal viel Glück mit den Lüftern Halte uns auf dem Laufenden!

Gruß Dave

 

[EtiYeti]

Hallo zusammen,

auf meine Anfrage vom Support habe ich die übliche Antwort erhalten. DS ohne Netzwerk testen. Hatte ich ja schon gemacht. Aber zur Info nochmal die grundsätzlichen Vorraussetzungen für Hibernation:

http://www.synology.com/de-de/support/faq/568

Mal schauen was Sie mir weiterhin vorschlagen.

Gruß

 

[IPMan]

Sind die Lüfter bei dir bis 30°C im Hibernate aus? Du betreibst die DS glaub ich im Keller oder?

Hi dave82,

nein meine 2 DS stehen nicht im Keller. Eine im Arbeitszimmer und eine in einem Schrank im Wohnzimmer zusammen mit Sat+AV-Receiver. Die Lüfter gehen im Ruhezustand aus, wobei der Kühlungsintervall logischerweise von der Umgebungstemperatur abhängig ist. Die Festplattentemperatur spielen - so denke ich - im Hibernate keine Rolle. Glaube auch nicht das man sie auslesen kann ohne die Platten zu wecken. Entscheidend wird die Systemtemperatur sein weil nur an der CPU eine merkliche Wärmentwicklung erkennbar ist - aber selbst vorher mit Lüfter aus war sie nie so hoch das es besorgniserregend war. Nun ist es aber dank Dir sicherer weil man eine unkontrollierte Wärmeentwicklung auf Grund der Prozessorlast oder Umgebungstemperatur nie ganz ausschließen konnte.

Allerdings hat der Patch (zip-File) nicht bzw. nur kurz funktioniert. Er hat nur die "/usr/syno/etc/synosyslog/syslog.d/scemd.conf" geändert und die /etc.defaults/syslog-ng/patterndb.d/scemd.conf" nicht. Beide Dateien waren unterschiedlich und so versagte irgendwann dein Filter und mein Postfach war voll mit Meldungen "Lüfter 1 steht, ....).

Ich habe dann die Startdatei "S21set_scemd_syslog_filter.sh" sowie die "/usr/syno/etc/synosyslog/syslog.d/scemd.conf" gelöscht und nur "/etc.defaults/syslog-ng/patterndb.d/scemd.conf" geändert. Nach einem Neustart der DS waren beide Dateien mit dem aktualisiertem Filter vorhanden. Vermutlich reicht es auch zu beide Dateien gleichzeitig zu ändern. Zusätzlich hatte ich noch in der Datei "check_fan" den Wert auf 0 gesetzt (lt. Wiki). Durch den Filter findet ohnehin keine Lüfterkontrolle statt und man weiß ja nie ob der Wert 1 irgendwann zum Nachteil wird und die DS tagelang die Platten aus und einschaltet. Man ist ja nicht immer vor Ort und kann sofort reagieren.
Diese Konfiguration lief jetzt mehrere Tage ohne Probleme durch.

Heute habe ich die "var/log/upstart/syslog-ng.log" überprüft und auch die Warnung gesehen. Die Änderung von @y__y "fan_check_common" value(MESSAGE) "habe ich auf den Filter übernommen - ohne eine neuen Filter zu kreieren - und die Warnung war nach einem Neustart weg.

Mal sehen ob die DS weiterhin so schön schläft wie die letzten Tage.

MfG
IPMan

 

[dave82]

Hi dave82,

nein meine 2 DS stehen nicht im Keller. Eine im Arbeitszimmer und eine in einem Schrank im Wohnzimmer zusammen mit Sat+AV-Receiver. Die Lüfter gehen im Ruhezustand aus, wobei der Kühlungsintervall logischerweise von der Umgebungstemperatur abhängig ist. Die Festplattentemperatur spielen - so denke ich - im Hibernate keine Rolle. Glaube auch nicht das man sie auslesen kann ohne die Platten zu wecken. Entscheidend wird die Systemtemperatur sein weil nur an der CPU eine merkliche Wärmentwicklung erkennbar ist - aber selbst vorher mit Lüfter aus war sie nie so hoch das es besorgniserregend war. Nun ist es aber dank Dir sicherer weil man eine unkontrollierte Wärmeentwicklung auf Grund der Prozessorlast oder Umgebungstemperatur nie ganz ausschließen konnte.

Allerdings hat der Patch (zip-File) nicht bzw. nur kurz funktioniert. Er hat nur die "/usr/syno/etc/synosyslog/syslog.d/scemd.conf" geändert und die /etc.defaults/syslog-ng/patterndb.d/scemd.conf" nicht. Beide Dateien waren unterschiedlich und so versagte irgendwann dein Filter und mein Postfach war voll mit Meldungen "Lüfter 1 steht, ....).

Ich habe dann die Startdatei "S21set_scemd_syslog_filter.sh" sowie die "/usr/syno/etc/synosyslog/syslog.d/scemd.conf" gelöscht und nur "/etc.defaults/syslog-ng/patterndb.d/scemd.conf" geändert. Nach einem Neustart der DS waren beide Dateien mit dem aktualisiertem Filter vorhanden. Vermutlich reicht es auch zu beide Dateien gleichzeitig zu ändern. Zusätzlich hatte ich noch in der Datei "check_fan" den Wert auf 0 gesetzt (lt. Wiki). Durch den Filter findet ohnehin keine Lüfterkontrolle statt und man weiß ja nie ob der Wert 1 irgendwann zum Nachteil wird und die DS tagelang die Platten aus und einschaltet. Man ist ja nicht immer vor Ort und kann sofort reagieren.
Diese Konfiguration lief jetzt mehrere Tage ohne Probleme durch.

Heute habe ich die "var/log/upstart/syslog-ng.log" überprüft und auch die Warnung gesehen. Die Änderung von @y__y "fan_check_common" value(MESSAGE) "habe ich auf den Filter übernommen - ohne eine neuen Filter zu kreieren - und die Warnung war nach einem Neustart weg.

Mal sehen ob die DS weiterhin so schön schläft wie die letzten Tage.

MfG
IPMan

Hi IPMan,

danke für die Info! Sorry hatte deinen Standort verwechselt. Die DS von EtiYeti steht im Keller
Ich hatte eigentlich bewusst die Änderung unter /etc statt /etc.default gemacht, um nicht an der Default Konfig zu basteln, und im Fehlerfall ein Backup habe. Deshalb habe ich das über ein Startup-Skript gemacht anstatt die Defaults zu verändern.
Interessant wäre die Meldung aus dem Logfile wenn der Lüfter steht (auch fan_check_common?). Ich schalte meinen Lüfter momentan nicht aus und der Patch läuft bestens. Am Wochenende war die DS mal kurz wach weil ich was kopiert habe.

Übrigens kann die Fehlermeldung aus dem /var/log/syslog durch die Lösung von @y__y oder einfach durch den Tausch von match() durch message() behoben werden. Scheinbar löst message() seit Syslog-NG Version 2.1 die Funktion match() ab und ist nur noch für eine Abwärtskompatiblität vorhanden. Also quasi so:

filter f_scemd { level(err..emerg) and program(scemd) and not message("fan_check_common"); };"

y__y hatte übrigens mit seiner Vermutung recht. Wenn ich fan_check_common aus dem Logging durch die Filtererweiterung exkludiere landet es in der /var/log/messages, aber bei mir nur wenn die DS nicht im Ruhezustand ist. Ist die DS im Ruhezustand wird die fan_check_common Meldung nicht geloggt und die Disks bleiben aus. Allerdings führt er beim mir selten bis garnicht den Fancheck durch wenn die Platten laufen (sehr kurios)

Ich habe den Filter jetzt erweitert und schicke die fan_check_common Meldung nach /dev/null. Somit taucht die Meldung nirgends auf. Nur ist mir nach deinem Post nicht mehr klar wo ich die Änderung am Besten platziere. Es gibt:
- /usr/syno/etc/synosyslog/syslog.d welches auf /etc/syslog-ng/patterndb.d verlinkt ist
- /usr/syno/etc.defaults/synosyslog/client welches auf /etc/syslog-ng/patterndb.d verlinkt ist
- /etc.defaults/syslog-ng/patterndb.d

Bin etwas verwirrt

Gruß Dave

 

[Contra]

Hi Dave,

ich hatte die Ports 80 und 5001 offen. VPN funktioniert bei mir nicht so richtig, hab schon ein Thread erstellt; vielleicht übersehe ich etwas, oder hab etwas falsch verstanden und konfiguriert, aber mit meinem Handy bekomme ich keine Verbindung. Abgesehen davon muß man bei VPN auch Ports freischalten... Ich weiß nicht, das entwickelt sich hier alles zu einer Art von Arbeit, die ich mit dem NAS ja eigentlich unterbinden wollte... Im Moment bin ich schon etwas gefrustet...

Gruß
Contra

 

[IPMan]

Bin etwas verwirrt

Hi Dave,

wie ich schon schrieb - mache dir eine Sicherheitskopie der "/etc.defaults/syslog-ng/patterndb.d/scemd.conf". Ändere im Original den Filter und lösche die "/usr/syno/etc/synosyslog/syslog.d/scemd.conf". Nach einem Neustart entpricht die "/usr/syno/etc/synosyslog/syslog.d/scemd.conf" der "/etc.defaults/syslog-ng/patterndb.d/scemd.conf". So hat es bei mir funktioniert. Drüberkopieren funktioniert sicher auch. Die Startdatei brauchst du dann nicht mehr.

Einträge über stehende Lüfter oder andere Lüfterprobleme (fan_check_common...) habe ich in keiner Logdatei - wäre auch fatal denn mein Lüfter steht im Ruhezustand mehr als er läuft.

Mit der Änderung von @y__y schläft die DS auch. Deine neue Erkenntnis bezüglich der Filteroptimierung kann man sicher auch verwenden, die Frage ist ob das relevant ist. Selbst mit der Warnung beim Systemstart hätte ich keine Probleme - hauptsache die DS bleib im Ruhezustand und wacht nicht andauernd auf.

MfG
IPMan

 

[dave82]

Hi Dave,

ich hatte die Ports 80 und 5001 offen. VPN funktioniert bei mir nicht so richtig, hab schon ein Thread erstellt; vielleicht übersehe ich etwas, oder hab etwas falsch verstanden und konfiguriert, aber mit meinem Handy bekomme ich keine Verbindung. Abgesehen davon muß man bei VPN auch Ports freischalten... Ich weiß nicht, das entwickelt sich hier alles zu einer Art von Arbeit, die ich mit dem NAS ja eigentlich unterbinden wollte... Im Moment bin ich schon etwas gefrustet...

Gruß
Contra

Hi Contra,

ich nutze als VPN-Gateway meine Fritzbox, Einrichtung hat wenige Minuten gedauert dank der Anleitung von AVM. Der Vorteil ist, dass du keine Ports weiterleiten musst, und wenn der VPN-Tunnel steht, alle Geräte im LAN erreichbar sind. So kann ich Unterwegs auch auf meinen PC, Sat-Receiver etc. zugreifen. Geht zwar auch über den VPN-Server vom Nas, denke aber da ist etwas mehr Aufwand nötig.

Gruß Dave

 

[dave82]

Hi Dave,

wie ich schon schrieb - mache dir eine Sicherheitskopie der "/etc.defaults/syslog-ng/patterndb.d/scemd.conf". Ändere im Original den Filter und lösche die "/usr/syno/etc/synosyslog/syslog.d/scemd.conf". Nach einem Neustart entpricht die "/usr/syno/etc/synosyslog/syslog.d/scemd.conf" der "/etc.defaults/syslog-ng/patterndb.d/scemd.conf". So hat es bei mir funktioniert. Drüberkopieren funktioniert sicher auch. Die Startdatei brauchst du dann nicht mehr.

Einträge über stehende Lüfter oder andere Lüfterprobleme (fan_check_common...) habe ich in keiner Logdatei - wäre auch fatal denn mein Lüfter steht im Ruhezustand mehr als er läuft.

Mit der Änderung von @y__y schläft die DS auch. Deine neue Erkenntnis bezüglich der Filteroptimierung kann man sicher auch verwenden, die Frage ist ob das relevant ist. Selbst mit der Warnung beim Systemstart hätte ich keine Probleme - hauptsache die DS bleib im Ruhezustand und wacht nicht andauernd auf.

MfG
IPMan

Hi IPMan,

ich sehe das auch so, da meine DS schläft kann ich damit leben. Mich hat es nur gefuchst, dass y__y damit Probleme hat. Es ist halt schwierig eine Lösung zu finden die bei jedem System, bzw. dessen Konfig passt. Kann sein das die Filtereinstellung bei uns klappt, und bei anderen nicht. Es gibt zu viele Faktoren um eine einheitliche Lösung zu finden. Bei mir klappt das mit dem Startup-Skript bestens. Weiß nicht in wie fern es zu Problemen bei Firmware-Upgrades kommen kann, wenn die default Konfigs geändert werden.

Hier mal meine aktuelle Filtereinstellung in der scemd.conf:

destination d_scemd { file(/var/log/scemd.log); };
destination d_fantest { file(/dev/null); };
filter f_scemd { level(err..emerg) and program(scemd); };
filter f_scemd2 { filter(f_scemd) and not filter(f_fantest); };
filter f_fantest { message(fan_check_common); };
log { source(src); filter(f_scemd2); destination(d_scemd); };
log { source(src); filter(f_fantest); destination(d_fantest); };

Gruß Dave

 

[Contra]

Hi Dave,

das ist mal ne Idee, hatte mich schon gefragt, ob das funktionieren würde... Werde es gleich mal ausprobieren... Danke für den Tip!

 

[IPMan]

Weiß nicht in wie fern es zu Problemen bei Firmware-Upgrades kommen kann, wenn die default Konfigs geändert werden.

Hi dave,

ich gehe davon aus das alles gelöscht und neu installiert wird.
Bestes Beispiel ist die Lüftersteuerung scemd.xml. Die geänderte Datei in /usr/syno/etc.default wird bei einem DSM-Update überschrieben und ist wieder im aktuellen Originalzustand vorhanden.
Ein weiteres Beispiel ist die Löschung von fremden Dateien. Ich habe das Programm etherwake nach /usr/sbin kopiert und nutze es in einem Cronjob - angelegt in der DSM Software (Aufgabenplaner glaube ich). Diese Datei etherwake war weg, die angelegte Aufgabe aber nicht.

Vermutlich übersteht keine systemnahe Änderung ein Update.

MfG
IPMan

 

[Contra]

Nur nochmal zur Info:
Ich hab echt die Schnauze voll mittlerweile. Entweder bin ich echt zu blöde ein VPN auzubauen oder irgendwas stimmt hier ganz und gar nicht. Über die Fritzbox kann ich das zwar einstellen, aber eine Verbindung ist damit auch nicht aufzubauen. Was mich am meißten freut: ich hab versucht auf mein Handy eine neue Firmware aufzuspielen, was früher kein Problem war, nur dieses mal hab ichs gebrickt, einfach tot das Dingen. Mit meinem Netbook krieg ich auch keine Verbindung zum VPN... Den Thread den ich erstellt habe wegen VPN ist auch noch ohne Antwort... Im moment läufts hier völlig unrund...

 

[dave82]

Der Support hat sich auch gemeldet und bietet mir an, einen neuen Lüfter zu schicken. Ich hab sofort zurückgeschrieben, das er gleich zwei neue versenden soll, weil ich ja nicht weiß, welcher denn jetzt den Streß macht. Viel Hoffnung setze ich in diese Lösung nicht, aber versuchen werd ichs. Wünscht mir Glück^^

Hi Contra,

und hast du die Lüfter schon verbaut bzw. dein Problem gelöst?

Gruß Dave

 

[Contra]

Hi Dave,

Lüfter sind heute grade angekommen und eben verbaut worden. Jetzt wird getestet!! Allerdings bezweifle ich stark, das es was bringt - es sind exakt die gleichen Lüfter, die schon verbaut waren...

Naja, mal sehen, ich probiers erst mal aus, dann wird gemeckert

PS: Übrigens hab ich es nicht von Hand hinbekommen ein VPN über die Fritzbox von einem anderen Rechner aus aufzubauen. Auch mit der Anleitung gings nicht. Hab dann die beiden Programme von AVM (VPN einrichten oder so ähnlich) benutzt, damit gings dann, nach ein paar Anfangsschwierigkeiten. Find ich aber persönlich nicht so gut, das das Ganze nicht manuell einzurichten ist und man eben auf die Programme zurückgreifen muß. Vor allem stört es mich, das man mit den Config-files hin und her rennen muß, um die jeweils in die Fritzbox und den VPN-Client einzufügen.

PPS: So, jetzt kann gemeckert werden. Der Lüftertausch hat wohl nichts gebracht. Die DS ist eben nach ein paar Sekunden direkt wieder aus dem Hibernate aufgewacht. Ich werds nochmal weiter durchlaufen lassen, aber ich denke, das das alte Spiel - DS schläft dreimal ein und wacht dann dreimal sofort wieder auf, um dann endgültig in den Hibernatemodus zu gehen - von vorne anfängt. Ob ich den Support nochmal anschreiben soll? Schätze mal der Herr Lüdke wird mir raten, den Kasten wieder an den Händler zurückzuschicken und ein Austauschmodell zu nehmen. Wobei ich dann wohl auch keine Garantie habe, das das neue Gerät reibungslos funktioniert...
Ach es ist echt ein Kreuz... Wenn dieses lächerliche Problem nicht wäre...

Gruß
Contra

Nachtrag: Es ist so, die DS hat ihr altes Spielchen begonnen. Also keine Besserung durch Lüftertausch, wär ja auch zu schön gewesen...