Unitymedia 6490 (lgi) - Magic Paket / Synology DS214Play

[johnripper]

Start/Stop-Zyklen (ungleich Lade-/Entladezyklen) werden leider bei den WD Reds (und vielen anderen Platten) nicht mehr angegeben. Entweder habe ich es selbst mal in einem Datenblatt gelesen oder in einem Beitrag, dass früher Werte von durschnittlich 20k Start/Stop-Zyklen angebenen waren. Beweisen kann ich das leider nicht und inwiefern sich diese Zahl nach unten oder oben verschoben hat, kann ich nur vermuten.
Bei NAS Festplatten gehe ich mal davon aus, dass diese höhere Start/Stop-Zyklen abkönnen als bspw. reine Server Festplatte (wie bspw. Seagate Enterprise Serie).

5000 Zyklen pro Jahr erscheint wir aber ein wenig viel. Dies sind 13,7 Pro Tag. Das heißt, dass im Durchschnitt alle 3,5 Stunden das System einmal hoch und wieder runterfährt.

 

[mcxpert]

Danke für die Info, habe nämlich auch schon vergeblich nach solchen Angaben gesucht.

5000 Zyklen pro Jahr erscheint wir aber ein wenig viel. Dies sind 13,7 Pro Tag. Das heißt, dass im Durchschnitt alle 3,5 Stunden das System einmal hoch und wieder runterfährt.

Das ist ja genau mein Problem. Ich habe stündliches aufwachen und weiss nicht woher. Der Rest ist dann Einsatzzeit.

 

[johnripper]

Bist du dir eigentlich sicher, dass es die FB ist? Wenn nein hilft wirklich nur, erstmal alle Geräte abzuziehen und zu schauen was passiert. Dann Geräte nach und nach wieder ans Netzwerk und schauen wo der Fehler auftritt.

Kannst du bei Synology (ähnlich wie bei QNAP) auf dem Gerät eine Firewall konfigurieren. Kann aber sein, dass die auch erst nach dem Interface greift.

 

[mcxpert]

sicher bin ich mir soweit, dass wenn ich die nas von netzwerk trenne sie nicht aufwacht (also ist es ja kein dienst oder ähnliches).
wenn ich dann meine switche trenne, wlan abschalte und nur noch die syno an der FB habe dann tritt es schon auf. Von daher ist meine anlaufstelle die FB.

Firewall gibt es auf der syno, das könnte ich noch versuchen. Was wäre dann zu blockieren? UDP9 denke ich oder?

 

[diegutefrauwaas]

Vielleicht sollten erst einmal etwas detailiertere Informationen gesammelt werden, warum die Syno letztendlich wirklich aufwacht:

http://www.synology-forum.de/showthread.html?85792-DSM6-syno_hibernation_debug

Ich habe früher immer das vorherige syno_hibernation_debug_tool benutzt, um das entsprechende Logging einzuschalten; leider hat sich die Vorgehensweise geändert, wie der obige Thread zeigt. Evtl. kommt dann raus, an welcher Datei jede Stunde rumgefingert wird und damit auch, welches Paket/welcher Service dafür verantwortlich ist.

 

[johnripper]

Versuch doch erstmal alles von der IP deiner FB.

 

[mcxpert]

Vielleicht sollten erst einmal etwas detailiertere Informationen gesammelt werden, warum die Syno letztendlich wirklich aufwacht:

http://www.synology-forum.de/showthread.html?85792-DSM6-syno_hibernation_debug

Ich habe früher immer das vorherige syno_hibernation_debug_tool benutzt, um das entsprechende Logging einzuschalten; leider hat sich die Vorgehensweise geändert, wie der obige Thread zeigt. Evtl. kommt dann raus, an welcher Datei jede Stunde rumgefingert wird und damit auch, welches Paket/welcher Service dafür verantwortlich ist.

Alles klar, das habe ich noch gar nicht gesehen erklärt aber warum bei mir das debug log so komplett null aussagekräftig war. Werde ich auf jeden fall testen :super:

Versuch doch erstmal alles von der IP deiner FB.

Das könnte ich dann als nächsten Ansatz wählen wobei alles blocken ja dann bedeuten würde, dass die funktion der syno für das wesentliche nicht mehr zur verfügung stehen wird

 

[mcxpert]

Vielleicht sollten erst einmal etwas detailiertere Informationen gesammelt werden, warum die Syno letztendlich wirklich aufwacht:

http://www.synology-forum.de/showthread.html?85792-DSM6-syno_hibernation_debug

Ich habe früher immer das vorherige syno_hibernation_debug_tool benutzt, um das entsprechende Logging einzuschalten; leider hat sich die Vorgehensweise geändert, wie der obige Thread zeigt. Evtl. kommt dann raus, an welcher Datei jede Stunde rumgefingert wird und damit auch, welches Paket/welcher Service dafür verantwortlich ist.

Hab das Debug heute Nacht laufen lassen aber auch dieses Mal steig ich nicht wirklich durch. Laut Protokoll war hier wakeup

Information,System,2017/11/28 08:29:20,SYSTEM,Internal disks woke up from hibernation.
Information,System,2017/11/28 07:29:20,SYSTEM,Internal disks woke up from hibernation.
Information,System,2017/11/28 06:30:08,SYSTEM,Internal disks woke up from hibernation.
Information,System,2017/11/28 05:30:08,SYSTEM,Internal disks woke up from hibernation.
Information,System,2017/11/28 04:30:08,SYSTEM,Internal disks woke up from hibernation.
Information,System,2017/11/28 03:27:29,SYSTEM,Internal disks woke up from hibernation.
Information,System,2017/11/28 02:30:08,SYSTEM,Internal disks woke up from hibernation.
Information,System,2017/11/28 01:29:20,SYSTEM,Internal disks woke up from hibernation.
Information,System,2017/11/28 00:29:21,SYSTEM,Internal disks woke up from hibernation.

Das entsprechende Log hier verlinkt
https://gist.github.com/anonymous/f765342b1383027ecbcb152e11b38637

Kann man daraus was erkennen?

 

[diegutefrauwaas]

Das hibernationFull.log zeigt max. 20-25 Sekunden idle-Zeit. Es finden permanent/alle paar Sekunden nfs-Zugriffe statt.
Dieses log scheint aber nicht mit den von dir gezeigten Daten darüber zusammen zu passen.

 

[mcxpert]

oje sehr viel aufwand für eigentlich nix. soweit ich das jetzt beurteilen kann sendet die fb keine mps
habe den Übeltäter jetzt gefunden. über

find / -mmin -5 | grep -v /proc | grep -v /sys | grep -v /run | grep -v /tmp | grep -v /dev

habe ich alle Dateien die innerhalb der letzten 5 Minuten geändert wurden angeschaut (klar man muss auf der lauer liegen aber zumindest ist sie ja pünktlich nach einer stunde aufgewacht und so konnte ich es "einplanen").
Hier war es dann das JDownloader Plugin welches alle 60 Minuten eine Verbindung zu Updateserver aufbaut (was dann in der log stand).

Hab das teil jetzt deinstalliert und seit dem ist endlich Ruhe.