DSM 4.0 Beta - Hibernation funktionert nicht wegen Mediaserver

[lpop]

Hallo,
mit der 4.0 Beta auf meiner DS212+ wachen die Platten nach 5 Minuten Ruhemodus wieder auf. Hibernation ist auf 10 Minuten gesetzt. Habe mal das syno_hibernate_debug_tool laufen lassen.
Der Mediaserver scheint alle 15 Min auf die Platte zuzugreifen, wenn ich das Logfile richtig interpretiere.
Habe diese Problem auch schon an Synology gemeldet.

Hier ein Auszug:

Jan 26 21:22:07 syno_hibernate_debug_tool: (115): Start Hibernation Debug with second [10]
Jan 26 21:22:07 kernel: [  391.630000] [/etc/passwd] opened by pid 8837 [u:(-ash), comm:(ash)]
Jan 26 21:23:18 kernel: [  463.110000] [/usr/syno/synoman/webman/modules/ThumbConvertProgress/ThumbConvertProgress.cgi] opened by pid 8787 [u:(/usr/syno/apache/bin/httpd), comm:(httpd)]
Jan 26 21:23:28 kernel: [  473.350000] [/usr/syno/synoman/webman/modules/DSMNotify/dsmnotify.cgi] opened by pid 8122 [u:(/usr/syno/apache/bin/httpd), comm:(httpd)]
Jan 26 21:32:15 kernel: [ 1000.000000] [/etc/localtime] opened by pid 8490 [u:(/var/packages/MediaServer/targe), comm:(dms)]
Jan 26 21:42:54 kernel: [ 1638.850000] [/etc/localtime] opened by pid 5261 [u:(/usr/syno/bin/scemd), comm:(scemd)]
Jan 26 21:43:05 kernel: [ 1650.180000] [/etc/localtime] opened by pid 2521 [u:(/sbin/klogd), comm:(klogd)]
Jan 26 21:43:11 kernel: [ 1656.000000] drivers/scsi/sd.c[443]:syno_hibernation_timer_update(), sda: cmd 0x0 spin up by pid=4, comm=events/0
Jan 26 21:43:18 scemd: SCEMD: disk 1 wake up from hibernation
Jan 26 21:47:35 kernel: [ 1920.000000] [/etc/localtime] opened by pid 8490 [u:(/var/packages/MediaServer/targe), comm:(dms)]
Jan 26 21:58:15 kernel: [ 2559.380000] [/etc/localtime] opened by pid 5261 [u:(/usr/syno/bin/scemd), comm:(scemd)]
Jan 26 21:58:26 kernel: [ 2570.740000] [/etc/localtime] opened by pid 2521 [u:(/sbin/klogd), comm:(klogd)]
Jan 26 21:58:31 kernel: [ 2576.000000] drivers/scsi/sd.c[443]:syno_hibernation_timer_update(), sda: cmd 0x0 spin up by pid=4, comm=events/0
Jan 26 21:58:38 scemd: SCEMD: disk 1 wake up from hibernation
Jan 26 22:02:55 kernel: [ 2839.680000] [/etc/localtime] opened by pid 8490 [u:(/var/packages/MediaServer/targe), comm:(dms)]
Jan 26 22:13:35 kernel: [ 3479.400000] [/etc/localtime] opened by pid 5261 [u:(/usr/syno/bin/scemd), comm:(scemd)]
Jan 26 22:13:46 kernel: [ 3490.740000] [/etc/localtime] opened by pid 2521 [u:(/sbin/klogd), comm:(klogd)]
Jan 26 22:13:51 kernel: [ 3496.000000] drivers/scsi/sd.c[443]:syno_hibernation_timer_update(), sda: cmd 0x0 spin up by pid=4, comm=events/0
Jan 26 22:13:58 scemd: SCEMD: disk 1 wake up from hibernation
Jan 26 22:18:15 kernel: [ 3759.680000] [/etc/localtime] opened by pid 8490 [u:(/var/packages/MediaServer/targe), comm:(dms)]
Jan 26 22:28:55 kernel: [ 4399.320000] [/etc/localtime] opened by pid 5261 [u:(/usr/syno/bin/scemd), comm:(scemd)]
Jan 26 22:29:06 kernel: [ 4410.650000] [/etc/localtime] opened by pid 2521 [u:(/sbin/klogd), comm:(klogd)]
Jan 26 22:29:11 kernel: [ 4416.000000] drivers/scsi/sd.c[443]:syno_hibernation_timer_update(), sda: cmd 0x0 spin up by pid=4, comm=events/0
Jan 26 22:29:18 scemd: SCEMD: disk 1 wake up from hibernation
Jan 26 22:33:35 kernel: [ 4679.680000] [/etc/localtime] opened by pid 8490 [u:(/var/packages/MediaServer/targe), comm:(dms)]
Jan 26 22:44:15 kernel: [ 5319.380000] [/etc/localtime] opened by pid 5261 [u:(/usr/syno/bin/scemd), comm:(scemd)]
Jan 26 22:44:26 kernel: [ 5330.720000] [/etc/localtime] opened by pid 2521 [u:(/sbin/klogd), comm:(klogd)]
Jan 26 22:44:31 kernel: [ 5336.000000] drivers/scsi/sd.c[443]:syno_hibernation_timer_update(), sda: cmd 0x0 spin up by pid=4, comm=events/0

 

[Trolli]

Wie kommst Du darauf, dass das mit dem Mediaserver zu tun hat? Das scheint für mich von den Zeiten her nicht zu passen...

 

[lpop]

Na ja . Ich habe nach dem wake-up Eintrag den Mediaserver Eintrag gesehen. Ich kenn mich da ja nicht aus. Auf was würdest du tippen was es ist ?
Evtl. habe ich auch was falsch gemacht mit diesem 'DebugHiberKernel' File.

Da stand man muss mit ...debug=1 hinter dem Link auf die DS und das File downloaden.
...
4.Press "Enter", and then the Kernel Log can be downloaded.
5.Please rename the Kernel Log to DebugHiberKernel before sending it.

Da konnte man aber nichts downloaden.
Da habe ich dann die normale message Datei unter /var/log/messages genommen per telnet.

 

[Trolli]

Die /var/log/messages ist schon ok...

spin up by pid=4​

Was ist pid=4? Schau mal mit 'ps' bei Dir nach.

Funktioniert der Hibernation-Modus, wenn die DS vom Netzwerk getrennt ist (LAN-Stecker ziehen)?

 

[lpop]

Ah ok. Jetzt wird es klarer. Nach der pid schaue ich heute abend.

Bzgl. Netzwerk getrennt ... Das Hibernation funktioniert auch mit gezogenem LAN Stecker nicht. Das habe ich schon ausprobiert. Es scheint also von 'innen' zu kommen.

 

[lpop]

So, ich habe den Mediaserver jetzt abgestellt. hat nicht geholfen

Hier wieder die Einträge:

Jan 27 19:06:43 kernel: [45384.000000] drivers/scsi/sd.c[443]:syno_hibernation_timer_update(), sda: cmd 0x0 spin up by pid=4, comm=events/0
Jan 27 19:06:50 scemd: SCEMD: disk 1 wake up from hibernation

PID No 4 ist events. Na toll. Und nun ?

DS212> ps
  PID USER       VSZ STAT COMMAND
    1 root      3020 S    init
    2 root         0 SW   [kthreadd]
    3 root         0 SW   [ksoftirqd/0]
    4 root         0 SW   [events/0]
    5 root         0 SW   [khelper]
    8 root         0 SW   [async/mgr]
   89 root         0 SW   [sync_supers]
   91 root         0 SW   [bdi-default]
   92 root         0 SW   [kblockd/0]
   98 root         0 SW   [ata/0]
   99 root         0 SW   [ata_aux]

 

[Trolli]

...zumindest hast Du doch einen prima Logeintrag, mit dem Du mal bei Synology nachfragen kannst, was das sein könnte, oder?

 

[sbob]

Also wenn ich hier so mitlese und meine eigenen Erfahrungen mit einbringe...
ich will nicht zu weit ausholen, ich hatte das Problem auch mit dem Ruhemodus der Festplatte...
Ich konnte machen was ich wollte... Dienste stoppen, Pakete anhalten, neustarten, deinstallieren... alles ohne Erfolg.
Auch das ziehen des LAN-Steckers brachte keinen Erfolg.
Meine Lösun: DSM deinstallieren und neu aufspielen (im Betrieb reset drücken bis Piiiep, loslassen und nochmal drücken bis Pieep... jetzt wird die Systempartition gelöscht, Daten bleiben erhalten...).
Alles wieder eingerichtet und die Kiste legt sich pennen...
Mit dem Update scheint so einiges aus dem Gleichgewicht gebracht worden zu sein... einige können den Schreibcache der Platte nicht mehr aktivieren usw...
Bin jetzt seit einigen Jahre Synologier ;-) und hatte auch schon einige dieser Dinger im Einsatz... nach wie vor Spitze, keine Frage. Aber so einen Murks nach einer Beta hatte ich noch nicht erlebt...
Beim nächsten mal warte ich bis zum Release...

 

[placebofan86]

du erwähnst den schreibach.... bei mir ist das auch der fall... gibt es dazu informationen im forum? ich finde nichts ? was hat es zur folge wenn der cache deaktiviert ist?

 

[itari]

Aber so einen Murks nach einer Beta hatte ich noch nicht erlebt...
Beim nächsten mal warte ich bis zum Release...

Wenn du schon einige Jahre dabei bist, dann hast bestimmt schon öfters meine Beitrage gelesen, die vor einer Beta immer schreibe. Da steht regelmäßig drinnen, dass die Beta alte und neue Probleme hat und man auch mit der ersten 'fertigen' Version noch regelmäßig Kummer hat (weil da neue Probleme durch die Beseitigung der Beta-Probleme entstehen). Es ist also alles völlig erwartungsgemäß und damit im grünen Bereich. Mehr als vorwarnen kann ich halt auch nicht: eine Beta hat halt Fehler zu haben *gg*

Itari

 

[lpop]

Ja, ich werde es bei Synology melden.

Ich hatte dieses Problem schon mit 3.2 . Da ich es auch da nicht beheben konnte, habe ich die 4.0 beta installiert. Ich weiss leider nicht ob es bei der 3.2 auch dieser Events Prozess war. ich vermute aber mal.

Ich kann es ja mal probieren mit dem Neueinspielen. Da muss ich mich nochmal einlesen. Wenn die Daten nicht verloren gehen ist es ja nicht so schlimm. Denn wieder die tausende Bilder hochladen wäre doof.

 

[itari]

du erwähnst den schreibach.... bei mir ist das auch der fall... gibt es dazu informationen im forum? ich finde nichts ? was hat es zur folge wenn der cache deaktiviert ist?

Infos zum Schreibcache gibt es seit mehr als 2 Jahren in verschiedenen Posts ... es gibt Platten, die haben ein Problem damit und Synology hat bei einer Reihe von Modellen seit ein paar Firmware-Versionen den Schreibchace automatisch aus geschaltet, damit keine Datenverluste entstehen können. Es kann also sein, dass weitere Modelle, die bislang außen vor waren, in diese Ausnahmeregelung aufgenommen wurden. Das folgende Tool mit der wird dabei verwendet:

ds2411> /usr/syno/bin/syno_disk_ctl
Copyright (c) 2003-2012 Synology Inc. All rights reserved.

Usage: synology disk control
device: something like /dev/hda or /dev/sda
options:
        ?: print this message
        --ncq-off: turn off ncq
                ex: syno_disk_ctl  --ncq-off /dev/sda
        --wcache-off: turn off write cache and tell kernel don't allow open it anymore
                ex: syno_disk_ctl --wcache-off /dev/sda
        --wd-idle: Read, Set or disable the idle3 timer of Western Digital drives
                -d: disable wd idle3 timer ex: syno_disk_ctl --wd-idle -d /dev/sda
                -g: get wd disk idle3 timer ex: syno_disk_ctl --wd-idle -g /dev/sda
                -s<value>: set wd disk idle3 timer ex: syno_disk_ctl --wd-idle -s80 /dev/sda

Itari

 

[placebofan86]

Danke für die info, kann man sehen welche modelle dies sind?

 

[itari]

Danke für die info, kann man sehen welche modelle dies sind?

ich vermute, dass es in dem Start-Skript /usr/syno/etc/rc.d/S99zbootok.sh mittels folgender Funktion veranlasst wird:

syno_disable_HD204UI()
{
        for hdd in /sys/block/sd*/device/model; do
                if [ x`cat $hdd` = "xHD204UI" -a -f ${hdd//model/syno_disk_serial} ]; then
                        if cat ${hdd//model/syno_disk_serial} | cut -c8-9 | egrep -q "Z[0-9AB]"; then
                                tmp=${hdd#/sys/block/}
                                dev=${tmp%/device/model}
                                /usr/syno/bin/hdparm -W 0 /dev/$dev
                        fi
                fi
        done
}

Es können aber weitere solcher Geschichten noch irgendwo stehen, die ich auf die Schnelle jetzt nicht finde.

Itari

 

[placebofan86]

und nun? sollte man das synology melden oder ist es gewollt, weil wie du schreibst es ja zu problemen gekommen ist ...

 

[itari]

und nun? sollte man das synology melden oder ist es gewollt, weil wie du schreibst es ja zu problemen gekommen ist ...

melden ... es sollte schon ein Hinweistext erscheinen, wenn das 'gewollt' ist ... soviel Info sollte schon sein

Itari

 

[Ap0phis]

Lösungsvorschlag zum Hibernation-Problem:

Ist zwar etwas versteckt, aber mit etwas Geduld findet man diesen - wie ich finde - sehr interessanten Beitrag: http://www.synology-forum.de/showth...-Probleme-Bugs&p=214818&viewfull=1#post214818

Sollte man mal testen!

 

[sbob]

Mehr als vorwarnen kann ich halt auch nicht: eine Beta hat halt Fehler zu haben *gg*
Itari

gebe ich Dir völlig recht und weiss ich ja auch... die Beta habe ich ja auch nur aus Neugier installiert und habe meine Daten auch entsprechet gesichert gehabt...
Ich meinte auch nur, dass ich in den vergangenen Jahren schon öfters Betas installiert hatte und noch nie solche Probleme hatte... ist natürlich ziemlich individuell aber ich hatte schon immer so einiges an Anwendungen und Diensten auf meiner Kiste laufen.
Ich habe das auch nur geschrieben, weil ich mich durch die vielen Beiträge zur 4er Beta in meiner Annahme bestätigt gesehen habe...
Ich muss allerdings auch einräumen, dass Synology diesmal einem Menge tolle Sachen zusätzlich mit an Bord gepackt hat, was ein solches Verhalten durchaus legitimiert...

 

[sbob]

Lösungsvorschlag zum Hibernation-Problem:

Ist zwar etwas versteckt, aber mit etwas Geduld findet man diesen - wie ich finde - sehr interessanten Beitrag: http://www.synology-forum.de/showth...-Probleme-Bugs&p=214818&viewfull=1#post214818

Sollte man mal testen!

hey, das ist doch mein Beitrag

 

[Ap0phis]

So ein Zufall.