Wieso weckt die Audio Station die HDDs stündlich auf?

[hvorragend]

Hardware: DS 211
Software: DSM 5.0 - 4493 Update 1
Konfiguration:
- Ruhestand der Festplatte: nach 30 Minuten
- Protokolle für Ruhezustand: aktiviert

---

Guten Tag,

ich frage mich, warum meine Diskstation exakt stündlich aus dem Schlaf geweckt wird. Und das über den ganzen Tag verteilt. Ich habe das Problem schon auf das "Audio Station"-Paket einschränken können. Ist dieses Paket "gestoppt", so habe ich Ruhe und alle schlafen durch.
Also muss ich mich eigentlich eher fragen: Warum weckt die Audio Station die HDDs stündlich auf?
Die Suche nach DLNA-Geräte habe ich in der Audio Station deaktiviert und ein Diagnose-Protokoll wird auch nicht mitgeschrieben.

Nun habe ich versucht, die Ursache einzugrenzen und bin mit dem Hibernate-Debug-Tool rangegangen.

Ich habe das Debug-Tool von folgendermaßen gestartet:

syno_hibernate_debug_tool --enable 10

Hinweis am Rande: Die Diskstation wurde um 13:12 Uhr neu gestartet.

/var/log/messages

Jun 23 10:49:54 DiskStation syno_hibernate_debug_tool: (115): Start Hibernation Debug with second [10]
...
Jun 23 13:12:26 DiskStation ddnsd: IsDDNSEnable(ddnsd.c:2999): All Config are Disable, Stop daemon
Jun 23 13:12:27 DiskStation synorelayd[5073]: synorelayd.cpp:1342 stoped
Jun 23 13:12:34 DiskStation kernel: [   74.350000] usbip_common_mod: module is from the staging directory, the quality is unknown, you have been warned.
Jun 23 13:12:34 DiskStation kernel: [   74.400000] usbip: module is from the staging directory, the quality is unknown, you have been warned.
Jun 23 13:12:35 DiskStation usbipd: syno_usbipd_func.c:3144(Success) failed get status in /usr/syno/etc/usbdev.conf.1d6b:0002:orion-ehci.0, skip
Jun 23 13:12:59 DiskStation pulseaudio[8624]: [pulseaudio] shm.c: Failed to read /dev/shm/: No such file or directory
Jun 23 13:12:59 DiskStation pulseaudio[8624]: [pulseaudio] bluetooth-util.c: org.bluez.Manager.ListAdapters() failed: org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program /usr/syno/libexec/dbus-daemon-launch-helper: No such file or directory
Jun 23 15:13:39 DiskStation syno_hibernate_debug_tool: (140): End Hibernation Debug

/var/log/scemd.log

Jun 23 13:12:11 DiskStation scemd: modules/disk_hibernation.c:2068 Force hibernation enable, idle minutes 30
Jun 23 13:12:11 DiskStation scemd: modules/disk_hibernation.c:2098 Eunit Deep sleep timer 0
Jun 23 13:12:16 DiskStation scemd: scemd.c:173 fan_type=7, raid_type=1, led_type=1, thermal_type=2, diskled_ctrl_type=1, auto_poweron_type=1, dual_power_type=1, usbcopy_type=1, fan_number=1, eunit_pwron_type=2, pis_type=1, rtc_type=2, lcm_type=2, wifi_wps_type=254
Jun 23 13:12:16 DiskStation scemd: modules/fan_speed_adjust_common.c:120 Type: INTERNAL Fan Mode: LOW_STOP
Jun 23 13:12:17 DiskStation scemd: modules/raid_sys_volume_check.c:144 MD0 active disks 2, designed disks 2
Jun 23 13:12:17 DiskStation scemd: modules/raid_sys_volume_check.c:144 MD1 active disks 2, designed disks 2
Jun 23 13:12:17 DiskStation scemd: modules/scemd_connector.c:103 scemd connector thread start.
Jun 23 13:12:17 DiskStation scemd: scemd.c:173 fan_type=7, raid_type=1, led_type=1, thermal_type=2, diskled_ctrl_type=1, auto_poweron_type=1, dual_power_type=1, usbcopy_type=1, fan_number=1, eunit_pwron_type=2, pis_type=1, rtc_type=2, lcm_type=2, wifi_wps_type=254
Jun 23 13:12:17 DiskStation scemd: scemd.c:394 WIFI/WPS button is not support on this model.
Jun 23 13:14:17 DiskStation scemd: scemd.c:451 stop manutild.
Jun 23 14:55:04 DiskStation scemd: modules/disk_hibernation.c:2338 The internal disks wake up from hibernation.

Ich kann den Logs leider absolut gar nichts entnehmen. Um 14:55 Uhr wurden die Festplatten geweckt. Aber das war es auch schon. Keine PIDs oder ähnliches. Oder übersehe ich etwas?

Kann mir jemand helfen? Vielen vielen Dank.

 

[TiloSurfer]

Hallo,

ich hole diesen Thread noch einmal hoch, weil es nun mich auch bzw. meine Diskstation (DS213+) mit dem "plötzlich" ausbleibenden Ruhezustand "erwischt" hat...

Ich denke, fast alles hier im Forum zum Ruhestand geschriebene mittlerweile zumindest gelesen und vieles auch ausprobiert zu haben. Schlussendlich konnte/kann ich prinzipiell die Problematik auch bei mir auf die "Audio Station" eingrenzen. Ob sie denn wirklich (allein) schuld ist, sei erst mal dahin gestellt - dazu gleich mehr.

Deshalb kurz zu den bestehenden Fakten:

Die DiskStation verrichtet praktisch seit etwas mehr als einem Jahr ohne Änderungen bezüglich laufender Pakete und angeschlossener Geräte ihre Dienste. Nachts wird sie planmäßig abgeschaltet und wenn am Tage nichts zu tun war, ging sie zuverlässig in den Ruhezustand (nicht Deep Sleep, wegen angeschlossener USB Platte). Einzig die aktuellen DSM Versionen und Paket-Updates wurden und werden eingespielt.

Seit ca. Mitte September weigert sich nun die Diskstation, in den Ruhezustand zu gehen. Was ist passiert? Zum besagten Zeitpunkt wurde die DSM Version 5.0 - 4493 Update 5 eingespielt und ziemlich zeitnah allerdings auch die Fritz!Box (hinter der die Diskstation hängt) einem Frimware-Update unterzogen. Letzteres muss ich fairerweise erwähnen, da es mit in das Zeitfenster fällt, seitdem der Ruhezustand nicht mehr funktioniert und ich nicht wirklich den "Verlust" des Ruhezustandes einer der beiden Aktionen eindeutig zuordnen kann.

An dieser Stelle will ich die Suche nach den Ursachen abkürzen und nur den Effekt beschreiben:

1. Diskstation, angeschlossen am Netz (LAN Kabel steckt) läuft unverändert im Betriebszustand mit allen Paketen - kein Ruhezustand.
2. Diskstation wird vom Netz genommen (LAN Kabel gezogen) - Diskstation geht nach der exakt definierten Zeit in den Ruhezustand und wacht auch nicht ungewollt auf.
3. Diskstation wird wieder ins Netz gehangen (LAN Kabel steckt), die Audio Station gestoppt(!) - Diskstation geht nach der exakt definierten Zeit in den Ruhezustand und wacht auch nicht ungewollt auf.

Weitere Beobachtungen bezüglich Zustand 1:

In der Prozessübersicht des DSM ist periodisch (ca. alle 3-5s) der Prozess "synoaudiod" aktiv. Entsprechend periodisch blinkt auch die LAN LED an der Diskstation. Alle Clients im Netzwerk sind nach besten Wissen und Gewissen aus, bzw. haben keinen aktiven Zugriff auf die Audio Station.
Von ganz außen - Internet - gibt es keinen Zugriff auf die Diskstation - keinerlei Portweiterleitungen in der Fritz!Box gesetzt. Auch kein Quickconnect. Wenn überhaupt von außen, dann nur über VPN der Fritz!Box.

Meine logische Schlussfolgerung ist nun, dass "irgend jemand" im (internen) Netzwerk versucht, die Audio Station zu erreichen bzw., was wohl wahrscheinlicher ist, diese ihrerseits versucht, mit "irgend jemand" im Netzwerk Kontakt aufzunehmen.

Meine Frage nun ist: Kann man irgendwie verlässlich feststellen (Wireshark?, etc.), mit wem die Audio Station "sprechen", also Kontakt aufnehmen will? Denn diese Tatsache scheint ja den Ruhezustand zu blockieren.

Ansonsten bin auch ich mit meinem Latein am Ende...

Vielen Dank im Voraus für etwaige Hilfe,
Tilo

PS 1: Das war meiner erster Beitrag nach langem lesen...so ist er auch lang geworden;-)
PS 2: Zweiter Versuch, der Original Post oben ging zu früh raus und ich durfte ihn nicht ergänzen - sorry!

 

[hvorragend]

Endlich! Ich bin nicht alleine.
Ich stimme dir auf voller Linie zu. Bei mir ist das EXAKT genauso.

Ich hatte bereits den Verdacht, dass der MedienServer die AudioStation per DLNA & Co. triggert und dadurch die Box aufgeweckt wird.

 

[TiloSurfer]

Endlich! Ich bin nicht alleine.

Willkommen! ;-) Eigentlich ja wohl eher umgekehrt, denn bisher lief es bei mir ja problemlos.

Ich hatte bereits den Verdacht, dass der MedienServer die AudioStation per DLNA & Co. triggert und dadurch die Box aufgeweckt wird.

Dagegen spricht, zumindest in meinem Fall, dass mit gezogenen LAN Kabel die Station zuverlässig schlafen geht. Ich gehe mal davon aus, dass der MedienServer, wenn er denn triggert, nicht den Umweg über den Router macht.

Wie gesagt, ich verdächtige den Prozess "synoaudiod" - so wie ich hier irgendwo gelesen habe, ein (der) Daemon der Audio Station. Dieser wiederum wird offensichtlich von irgend jemanden/irgendwas zum (kurzzeitigen) starten verführt. Aus den Logs ist allerdings (zumindest für mich) kein Kandidat hierfür zu ermitteln.