DSM 7.1 DS215j mit DSM DSM 7.1.1-42962 Update 5 kein Ruhemodus

[Soldier]

Hallo zusammen,

meine Syno DS215j mit DSM 7.1.1-42962 Update 5 geht nicht mehr in den Ruhemodus beide Ruhemodus sind auf 15 min. eingestellt
aktiv sind nur die Standardapps (habe alles angehalten was geht) ich bin von DSM 6 (letzte Version) auf die DSM 7.1.1-42962 vor ein paar tage umgestiegen noch ein paar Fotos.

 

[ottosykora]

mach dir keine Sorgen, es gibt endlos Gründe warum der Ruhemodus nicht funktioniert.
https://kb.synology.com/de-de/DSM/t...Synology_NAS_from_entering_System_Hibernation

ich habe das schon vor Jahren abgestellt, das schont die Platten und Nerven

 

[Soldier]

Danke für deine Antwort. Ja es kann doch nicht sein das eine Funktion nicht funktioniert. Klar spart es nerven aber auch Strom.

 

[mayo007]

Dann zieh den Stecker. Das spart noch mehr Strom

 

[Soldier]

Nicht wirklich sinnvoll deine Antwort.
Es geht nicht direkt indem Strom sondern um eine Funktion

 

[mayo007]

Deine Antwort zu dem Link oben ist genau so sinnvoll;-)

 

[Benares]

@Soldier , lass dich nicht verunsichern. Auch ich lege Wert auf einen funktionierenden Ruhe der Platten. Und der funktioniert i.d.R. sehr gut, auch mit den neueren Versionen.

Ich schau in solchen Fällen immer über die Konsole z.B. mit

find /volume1 -cmin -5

welche Dateien innerhalb der letzten 5 Minuten auf /volume1 geändert wurden. Das liefert Hinweise auf den Störenfried. Natürlich muss man die Ausgabe etwas zu lesen wissen. Meist sind es aber nur die Log-Einstellungen einiger Pakete, die das verursachen.

 

[himitsu]

Das findet aber nur Schreibzugriffe.

Was ist mit Lesezugriffen? Auch im Systemvolume.



Und natürlich löst dein Suchen auch wieder Zugriffe aus, die das Schlafen somit unterdrücken.





Ich hatte mir mal überlegt, dass es cool wäre, wenn es ein "Schläft die Fesplatte, bzw. das Volume grade?" gäbe,
bzw. ein "Wann gab es die letzte Aktivität?"

und man dann könnte man gewisse Aktionen aussetzen, bzw. umleiten.

* z.B. muß kein Snapshot erstellt werden, wenn es keine Änderung gab (wenn das Volume schläft, kann sich nichts geändert haben)

* wenn ein SSD-Cache vorhanden ist, dann kleinere Änderungen verzögert schreiben, sowie jetzt noch nicht, wenn die Platte grade schläft.

* und Logs auf einen FlashSpeicher umleiten,
aber da dieser als MountPoint im System hängt, gibt es dann eventuell dennoch einen Zugriff auf die Systempartition und schon kann die Platte dennoch nicht schlafen.

...

 

[Benares]

Das findet aber nur Schreibzugriffe.
Was ist mit Lesezugriffen? Auch im Systemvolume.

Um Schreibzugriffe geht es, denn die müssen letztendlich auf die Platte - und dazu müssen sie aufwachen. Lesezugriffe werden oft aus dem Cache bedient und wecken nicht unbedingt die Platten. Eine Webstation mit simpler Struktur kann durchaus auch viele Clients bedienen, ohne die Platten zu wecken.

Klar, die Schreibzugriffe könnten auch die anderen Filesysteme wie / betreffen, aber dann schiebt man halt auch noch ein

find / -mount -cmin -5

nach. Hauptsache, man findest den Störenfried.

Edit: Wenn die Platten eh nicht schlafen gehen, muss man sich auch keine Gedanken darüber mach, dass eine solche Suche die Platten wecken würden, wenn sie denn schlafen würden.

 

[himitsu]

Vermutlich müsste man doch auch über die Prozessliste gehen können, ohne die ganze Platte durchsuchen zu müssen.

Änderungen der Menge an Schreibzugriffen der Prozesse.

 

[Benares]

Vermutlich müsste man doch auch über die Prozessliste gehen können, ohne die ganze Platte durchsuchen zu müssen

Klar, kann man auch. Darüber findet man aber eher Prozesse, die permanent schreiben, nicht die, die es nur ab und zu tun.

 

[Soldier]

@Soldier , lass dich nicht verunsichern. Auch ich lege Wert auf einen funktionierenden Ruhe der Platten. Und der funktioniert i.d.R. sehr gut, auch mit den neueren Versionen.

Ich schau in solchen Fällen immer über die Konsole z.B. mit

find /volume1 -cmin -5

welche Dateien innerhalb der letzten 5 Minuten auf /volume1 geändert wurden. Das liefert Hinweise auf den Störenfried. Natürlich muss man die Ausgabe etwas zu lesen wissen. Meist sind es aber nur die Log-Einstellungen einiger Pakete, die das verursachen.

wo kann ich das eingeben ? ( ich habe noch nie irgendwie befehle eingegeben bei der Syno )

 

[Soldier]

ich habe vergessen zu erwähnen das sie auch nicht schläft ohne Netzwerkkabel. und alle Lampen ( Disk 1 und Disk2 ) stehen still. ich höre auch keine HDD arbeiten ( Schreiben usw )

 

[ottosykora]

aus der Anleitung in #2 kannst du sehen dass es zwar funktionieren kann, aber es gibt sehr viele Gründe warum es trotzdem nicht geht weil sich alles gegenseitig beeinflusst. Da kannst du mit der Liste der 'vielleicht' Gründe anfangen.
Es ist nicht so dass es eine Funktion ist die nicht verwendbar ist, aber es braucht zu viele Voraussetzungen dazu.
Bei mir hat es zuerst mal einige Jahre funktioniert, dann immer weniger und dann hat es genervt weil wenn ich dann drauf zugreifen wollte musste ich lange warten bis was kam. Habe es dann auch abgestellt, damit müssen die Platten nicht dauernd hochfahren und leben länger. Ob mit dem laufen lassen der Platten oder öfter wechseln der Platten mehr Energie verbraucht wird kann ich nicht sagen, aber wenn die Platten wie hier 80kh laufen, dann spart man sicher auch so.

 

[Benares]

wo kann ich das eingeben ?

über die Konsole (ssh-Session). Lies mal hier.

 

[himitsu]

Schlafen?

"Ruhezustand der Festplatten" (die DS reagiert noch, aber weil grade nicht genutzt, werden so lange die Festplatten vom Drehen befreit)
oder kompletter Standby (DS fährt runter und schaltet sich ganz ab ... alternativ bleibt die Netzwerkkarte für's Wake-on-LAN noch aktiv)

 

[Soldier]

@Soldier , lass dich nicht verunsichern. Auch ich lege Wert auf einen funktionierenden Ruhe der Platten. Und der funktioniert i.d.R. sehr gut, auch mit den neueren Versionen.

Ich schau in solchen Fällen immer über die Konsole z.B. mit

find /volume1 -cmin -5

welche Dateien innerhalb der letzten 5 Minuten auf /volume1 geändert wurden. Das liefert Hinweise auf den Störenfried. Natürlich muss man die Ausgabe etwas zu lesen wissen. Meist sind es aber nur die Log-Einstellungen einiger Pakete, die das verursachen.

root@clkdwdcd:~# find /volume1 -cmin -15
/volume1/@database/synolog
/volume1/@tmp/nginx/ready
/volume1/@appdata/CodecPack/log/synoame.log
/volume1/@SynoFinder-log/appindex.log
/volume1/@SynoFinder-log/fileindexd.log
/volume1/@SynoFinder-log/synoelasticd.log
/volume1/@userpreference/admin
/volume1/@userpreference/admin/appnotify
/volume1/@userpreference/Chris
/volume1/@userpreference/Chris/usersettings
/volume1/@userpreference/Chris/appnotify
/volume1/@userpreference/Chris/bkgtask
/volume1/@userpreference/Chris/activities

 

[Soldier]

Um Schreibzugriffe geht es, denn die müssen letztendlich auf die Platte - und dazu müssen sie aufwachen. Lesezugriffe werden oft aus dem Cache bedient und wecken nicht unbedingt die Platten. Eine Webstation mit simpler Struktur kann durchaus auch viele Clients bedienen, ohne die Platten zu wecken.

Klar, die Schreibzugriffe könnten auch die anderen Filesysteme wie / betreffen, aber dann schiebt man halt auch noch ein

find / -mount -cmin -5

nach. Hauptsache, man findest den Störenfried.

Edit: Wenn die Platten eh nicht schlafen gehen, muss man sich auch keine Gedanken darüber mach, dass eine solche Suche die Platten wecken würden, wenn sie denn schlafen würden.

root@dcscdd:~# find / -mount -cmin -5
/run
/var/lib
/var/lib/logrotate.status
/var/lib/diskutil
/var/lib/diskutil/diskutil.conn
/var/cache/samba/smbXsrv_session_global.tdb
/var/log
/var/log/partition.log
/var/log/router.log
/var/log/systemd/nginx.service.log
/var/log/iscsi.log
/var/log/kern.log
/var/log/synopkg.log
/var/log/bash_err.log
/var/log/synocrond.log
/var/log/synoscheduled.log
/var/log/synocontentextractd.log
/var/log/synoplugin.log.1.xz
/var/log/datascrubbing.log
/var/log/rm.log
/var/log/synoinstall.log
/var/log/auth.log
/var/log/synosnmpcd.log
/var/log/messages
/var/log/scemd.log
/var/log/disk.log
/var/log/synosystemd.log
/var/log/synoplugin.log
/var/log/boot-time-detail.log
/var/log/space_operation.log
/var/log/postgresql.log
/var/log/systemd.log
/var/log/apparmor.log
/var/log/synoschedmulti.log
/var/log/synolog
/var/log/synolog/.SYNOCONNDB
/var/log/synoscheduler.log
/var/log/nginx/error_default.log
/var/log/synoscgi.log
/var/log/synorelayd.log
/var/log/bash_history.log
/var/log/synoplugin.log.3.xz
/var/log/synoplugin.log.2.xz
/var/log/syslog.log
/var/tmp/nginx
/var/tmp/nginx/test
/var/tmp/nginx/test/main
/var/tmp/nginx/test/main/scgi_params
/var/tmp/nginx/test/main/nginx.conf.default
/var/tmp/nginx/test/main/fastcgi.conf
/var/tmp/nginx/test/main/koi-win
/var/tmp/nginx/test/main/fastcgi_params
/var/tmp/nginx/test/main/mime.types
/var/tmp/nginx/test/main/proxy.conf
/var/tmp/nginx/test/main/win-utf
/var/tmp/nginx/test/main/koi-utf
/var/tmp/nginx/test/main/uwsgi_params
/var/tmp/nginx/html/redirect.html
/usr/local/packages/@appdata/SMBService/log/synowstransfer.log
/usr/syno/share/certificate.d
/usr/syno/etc/security-profile/tls-profile
/usr/syno/etc/security-profile/tls-profile/datastore.json
/usr/syno/etc/security-profile/tls-profile/config
/usr/syno/etc/security-profile/tls-profile/config/dsm.conf
/usr/syno/etc/security-profile/tls-profile/config/system_quickconnect.conf
/usr/syno/etc/security-profile/tls-profile/services
/usr/syno/etc/security-profile/tls-profile/services/system_quickconnect.conf
/usr/syno/etc/security-profile/tls-profile/mustache
/usr/syno/etc/security-profile/tls-profile/mustache/system_quickconnect.mustache
/usr/syno/etc/private/credentials.sqlite
/usr/syno/etc/services.d
/usr/syno/etc/services.d/synow3.sc
/usr/syno/etc/synorelayd
/usr/syno/etc/synorelayd/services.conf
/usr/syno/etc/synorelayd/synorelayd.conf
/usr/syno/etc/certificate/_archive
/usr/syno/etc/certificate/_archive/SERVICES
/usr/syno/etc/certificate/_archive/INFO
/usr/syno/etc/certificate/system
/usr/syno/etc/certificate/system/quickconnect
/usr/syno/etc/certificate/system/quickconnect/ECC-fullchain.pem
/usr/syno/etc/certificate/system/quickconnect/ECC-cert.pem
/usr/syno/etc/certificate/system/quickconnect/RSA-fullchain.pem
/usr/syno/etc/certificate/system/quickconnect/ECC-privkey.pem
/usr/syno/etc/certificate/system/quickconnect/info
/usr/syno/etc/certificate/system/quickconnect/RSA-cert.pem
/usr/syno/etc/certificate/system/quickconnect/RSA-privkey.pem
/usr/syno/etc/www
/usr/syno/etc/www/nginx_config.json
/usr/syno/etc/www/DSM.json
/usr/syno/etc/firewall.d
/usr/syno/etc/firewall.d/2.json
/usr/syno/etc/firewall.d/1.json
/etc/nginx
/etc/nginx/nginx.conf
/tmp
root@kdkc:~#

 

[Soldier]

Gibt es ein Befehlt, um die Dienste anzuhalten? Wenn ja, wäre es super, wenn ihr mir die zeigen könnt. Natürlich wäre es dann auch sinnvoll die befehle zum Haben wegen aktivieren. in DSM 6 gib es über den Webinterface

 

[Benares]

Gibt es ein Befehlt, um die Dienste anzuhalten?

Du kannst Pakete über das Paket-Zentrum anhalten, die du nicht brauchst, leider nicht alle.

In deinem Fall tippe ich auf das Paket "Universal Search" (SynoFinder) als Störenfried, das auf volume1 rumrödelt (#17).
Leider kann man es (ohne kleinen Hack) nicht stoppen, aber über Umwege deinstallieren (s. hier)
Wenn du es über dessen Einstellungen nicht ruhiger bekommst und du es nicht brauchst, wirf es runter. Bei mir stört es den Ruhezustand aber nicht.

Führ die Befehle, insbesondere "find /volume1 -cmin -5" aber ruhig öfter mal aus, insbesondere, wenn du der Meinung bist, "die Platten müssten jetzt schlafen, ich mach ja nix mit dem NAS". Sie liefern halt immer nur eine Momentaufnahme. Und dazwischen natürlich nicht im DSM oder der Konsole eingeloggt bleiben.

Edit: Der Hack besteht darin, ctl_stop="no" in /var/packages/SynoFinder/INFO auf "yes" zu ändern. Dann lässt er sich auch über das Paket-Zentrum stoppen.