Hibernate geht nicht?

[itari]

Das Programm /usr/syno/bin/synocfgen ist für die Konsistenz aller Disk Station Systemdateien verantwortlich. Das ist dann auch das Programm, welches sich mit der /etc.defaults/crontab herumschlägt, die ursprüngliche /etc/crontab (wird temporär umbenannt: /etc/crontab.tmp) einliest, die /etc.defaults/crontab auf die /etc/crontab kopiert und die Differenzen auf Unverträglichkeit hin analysiert. Und hier ist (zumindest bislang) auch das Problem der TABs angesiedelt.

Sinn der Geschichte: Sollte in der crontab ein Fehler enthalten sein, weigert sich normalerweise der crond sie auszuführen. Wenn der Disk Station Manager nun cron-Aufträge einfach hintendran schreiben würde, würden sie wegen des Fehlers ja nicht ausgeführt werden ...

itari

 

[baeumer]

Habe folgenden Befehl in der Konsole probiert:

syno_poweroff_task

Ergebnis aus message:

Sep 11 21:16:20 scheduler: scheduler.c (1315) rTorrent is killed.
Sep 11 21:37:07 scemd: SCEMD: disk 1 wake up from hibernation 
Sep 11 21:55:52 kernel: synobios: power button pressed, ret = 0
Sep 11 21:55:53 scemd: SCEMD: Shutdown the system.

Um 21:16:20 Befehl eingegeben, um 21:55:53 neu gebootet. Warum wacht die Platte trotzdem um 21:37:07 auf? War sie überhaupt eingeschlafen?
Der ominöse Fehler

kernel: svc: bad direction 268435456, dropping request

erscheint jedenfalls nicht mehr. Und wie jetzt weiter?

 

[itari]

Du weißt jetzt, dass es ein Dienst ist, der in der /usr/syno/etc/rc.d gestartet wurde, der die Message erzeugt hat. Schau jetzt mit 2 Telnet-Fenstern auf die DS: das eine Fenster machst auf die /var/log/messages, mit dem anderen versuchst jeden Dienst in der /usr/syno/etc/rc.d manuell zu restarten (oder stop / start, wenn restart nicht geht). Irgend wann wird beim restart/start die Fehlermeldung erzeugt werden (99% Chance) und dann weißt endlich wer der Verursacher ist.

Auch wenn es etwas mühsam erscheint, ich würde es trotzdem machen.

itari

 

[baeumer]

Ich kann die Datei /usr/syno/etc/rc.d nicht öffnen. Mit vi werden nur Zeilen mit ~ angezeigt, alle leer. In ftp wird eine Datei mit 27 bytes angezeigt, chmod ist auf 777 gestellt. BNei Öffnen über ftp kommt die Meldung, die Datei ist nicht vorhanden. Und jetzt?

 

[Trolli]

/usr/syno/etc/rc.d ist ein Verzeichnis und keine Datei...

 

[itari]

Wie Trolli schon feststellt: die /usr/syno/etc/rc.d ist ein Verzeichnis, in dem dann die einzelnen Startdateien für die Dienste stehen. Um diese geht es dann. z.B. S99ftpd.sh. Diese Dateien kann man auch öffnen/anschauen und da sieht man dann auch, wie sie sich starten lassen. Beispiel S99ftpd.sh sieht so aus:

#!/bin/sh
# Copyright (c) 2000-2008 Synology Inc. All rights reserved.

SynoStop=/usr/bin/killall
STARTFTP="/var/tmp/startftp"

case $1 in
start)
        if [ -f "$STARTFTP" ]; then
                exit 0;
        fi
        Run=`/bin/grep -s ^runftpd /etc/synoinfo.conf | awk -F \" '{print $2}'`
        if [ "yes" = "$Run" ]; then
                echo "Starting ftpd ..."
                /bin/sh /usr/syno/etc.defaults/rc.ftpd > /dev/null 2>&1 &
        fi
        ;;
stop)
        $SynoStop ftpd > /dev/null 2>&1
        ;;
restart)
        $0 stop
        $0 start
        ;;
*)
        echo "Usages: $0 [start|stop|restart]"
        ;;
esac

Da sieht man das es start, stop und restart als Parameter-Auswertung gibt. Man kann also eingeben: /usr/syno/etc/rc.d/S99ftpd.sh restart

Wenn der Dienst startet, dann versucht er seine Ressourcen zu benutzen. Dabei könnte es zu der Fehlereintragung in der /var/log/messages kommen, wenn er dabei Probleme hat. Das wäre meine Vorgehensweise. Wenn ich mir nach jedem Start einer rc.d-Datei die /var/log/messages anschaue, dann müsste ich irgendwann (99%) nach einem restart/start die Fehlermeldung sehen und dann hab ich den Verursacher.

Ist mein Gedankengang verständlich?

itari

 

[baeumer]

Vielen Dank, werde ich heute abend testen. Danke schon mal bis dahin für die immer gute und schnelle Unterstützung.

 

[baeumer]

Warum wird in FTP denn das Verzeichnis /usr/syno/etc/rc.d als Datei angezeigt? Ich kann den Ordner nur über telnet öffnen. Muß das so?

 

[itari]

Weil es ein symbolischer Link auf /usr/syno/etc.defaults/rc.d ist.
Sorry, hätte ich dir früher sagen sollen. Fällt mir im Telnet halt nicht auf.

itari

 

[baeumer]

Fehlerhaften Dienst nicht gefunden

Also, ich habe sämtliche Dienste gestop und gestartet, der Eintrag in der message taucht so nicht auf. Folgende Dienste sind in rc.d:

S66synoindexd.sh     S95sshd.sh           S86synodms.sh
S03bootup.sh         S79RCPower.sh        S04crond.sh
S78JumboFrame.sh     S97apache-sys.sh     S85synonetbkpd.sh
S97apache-user.sh    S98findhostd.sh      S83nfsd.sh
S84rsyncd.sh         S96synorcd.sh        S21mysql.sh
S20pgsql.sh          S99mDNS.sh           S02hotplugd.sh
S99ftpd.sh           S99zbootok.sh        S03inetd.sh
S55lpd.sh            S77synomkthumbd.sh   S80samba.sh
S99iTunes.sh         S81atalk.sh          S88synomkflvd.sh
S82surveillance.sh   S09DDNS.sh           S25download.sh

Und jetzt?

 

[itari]

Gute Frage. Dann sind es nicht die Dienste.

Fahr deine DS nochmal neu hoch und dann schau mal, wann die erste Eintragung in der /var/log/messages wieder erscheint. Dann müssen wir zeitlich mal schauen, ob wir den Fehler eingrenzen können. Also was hast gemacht, kurz bevor die Fehlermeldung wieder erscheint.

Viel mehr fällt mir nun auch nicht ein.

itari

 

[baeumer]

Ich glaube, ich werde diese Aktion erstmal beenden.
Ich hatte gelesen, daß meine Platte (Samsung 500G) wahrscheinlich sowieso ein Hibernate-Problem hat. Ich werde mit wohl mal eine andere Platte zulegen und melde mich dann, ob sich das Problem dadurch lösen ließ.
Nebenbei: Wäre es nicht hilfreich, wenn bei einem nächsten Update ein optischer Hinweis auf Hibernate eingeführt würde (blinkende HDD-LED oder so...)?

 

[itari]

Nebenbei: Wäre es nicht hilfreich, wenn bei einem nächsten Update ein optischer Hinweis auf Hibernate eingeführt würde (blinkende HDD-LED oder so...)?

Ja darüber habe ich mir auch schon Gedanken gemacht. Der Spin-down (lassen wir mal das Unwort Hibernate, weil es ja wirklich nicht stimmt, dass da etwas auf die Platte ausgelagert wird) ist eine Einstellung des Plattencontrollers (auf der Platte). Man sagt dem Minibetriebssystem auf der Platte: "hey, stell mal Untätigkeit nach xx Minuten fest und mach einen 'spin-down'". Und dann macht das die Platte autonom.

Ich hab mal probiert, ob man mit sdparm den Plattenstatus abfragen kann, leider ohne Erfolg (hdparm geht leider mit SATA nicht). Ich habe es auch nicht geschafft, mit den sg3-Tools eine ATA-Code-Abfrage durchzuführen; irgendwie verschließt sich die Materie vor mir. Aber vielleicht hat ja jemand Zeit, Lust und Interesse, dass mal zu testen. Bei Seagate gibt es recht gute technische Doku dazu.

Daran denken, dass die Platten bei falschen Parametern auch ins Nirwana verschwinden können, also ne alte Platten als Übungsobjekt nutzen.

itari

 

[caesar65]

Hatte vor ca. einem Monat Mail-Kontakt mit dem Synology Support. Ich habe eine CS407 mit bis zu dem Zeitpunkt 2 Samsung HD501LJ. Spin down hat wunderbar funktioniert. Dann habe ich - unter gewissen Schmerzen - aus dem Raid 1 ein Raid 5 gemacht, indem ich eine weitere Samsung HD501IJ (glaube ich) dazugesetzt habe. Mit dieser funktioniert der Spin down nun nicht, mit den anderen beiden Platten aber weiterhin.
Antwort des Supports sinngemäß:
Mit den (eher minderwertigen) Samsung-Platten gibt es Probleme. Man arbeitet mit Samsung dran, diese zu lösen. Es gebe bereits eine Lösung für den Spin Down, die dann in der nächsten Firmware enthalten sein wird. Diese Firmware sollte laut Aussage im September (dieser Monat) erscheinen.
Ich hab's nicht weiter verfolgt, eine kurze Recherche hat aber keinen Erfolg gebracht.
Vielleicht hat jemand anders was gelesen oder gehört?

 

[Trolli]

Also bei meinen HD501LJ im Raid-5 hatte ich noch kein Hibernation-Problem. Möglicherweise liegt es an der weiteren Platte, die Du hinzugefügt hast...

 

[caesar65]

Wie geschrieben gibt es auch im Raid 5 kein Problem mit den HD501LJ Platten. Die neue "IJ" fährt nur nicht herunter, die beiden LJ tun das auch weiterhin.
Ich denke, es ist so wie der Support gesagt hat. Es gibt ein Problem mit Samsung HDs.