Hibernate geht nicht?

[baeumer]

Hallo,
hab die DS 207+ neu und gleich die Beta 702 aufgespielt. Bei mir ging Hibernate noch nie (oder weiß ich nur nicht, wie ich Hibernate erkenne??) Jedenfalls läuft der Ventilator mit voller Dröhnung, die blaue Lampe leuchtet. Wenn ich an der Box (3 Sekunden On-Schalter drücken) oder im Manager ("Aus") versuche, die Box auszuschalten, startet sie gleich neu.
Muß das so? Liegt das an der Beta? Den Download-Manager habe ich bereits deaktiviert, 3rd partys laufen noch nicht wirklich.

Danke

Matthias

 

[itari]

Hallo,
hab die DS 207+ neu und gleich die Beta 702 aufgespielt. Bei mir ging Hibernate noch nie (oder weiß ich nur nicht, wie ich Hibernate erkenne??)

Da gibt es zwei Methoden: einmal über die /var/log/messages und einmal über smartctl. Da du ja jetzt smartctl in der FW hast, schreib dir einfach die Werte für folgenden Zeile auf: Start_Stop_Count und Power_Cycle_Count. Die Differenz ist die Anzahl der 'Spin-Downs' (=hibernates).

Jedenfalls läuft der Ventilator mit voller Dröhnung, die blaue Lampe leuchtet. Wenn ich an der Box (3 Sekunden On-Schalter drücken) oder im Manager ("Aus") versuche, die Box auszuschalten, startet sie gleich neu.

Ja das ist ein Bug in der FW

Muß das so? Liegt das an der Beta? Den Download-Manager habe ich bereits deaktiviert, 3rd partys laufen noch nicht wirklich.

Danke

Matthias

Habe dir inline geantwortet.

itari

 

[baeumer]

Dank für die rasche Antwort, werde ich zuhause testen.
Großes Lob an das Board, Ihr scheint nie zu schlafen. Rund um die Uhr bekomme ich rasche Antwort und noch meckert keiner über meine Fragen, die als Neuling vielleicht manchmal etwas schlicht scheinen können... Hab halt noch keine Ahnung von Linux.

 

[itari]

und noch meckert keiner über meine Fragen, die als Neuling vielleicht manchmal etwas schlicht scheinen können... Hab halt noch keine Ahnung von Linux.

Warum sollten wir den meckern? Wir haben doch alle mal klein angefangen. Und jeder von uns kennt doch auch die Situation, dass man an irgendwas 'Kleinem' mal hängen bleibt und dann freut man sich doch, wenn man ungezwungen Fragen stellen kann ...

itari

 

[baeumer]

Hibernate geht nicht

Bei mir geht Hibernate nicht (DS 207+, Beta 716).
Ich habe einen Leistungswächter angeschlossen, der Verbrauch ist konstant bei ca 25W. Download-Service habe ich abgestellt.
Kann es eigentlich sei, daß durch dyndns regelmäßige Abfrage auf neue IP gemacht werden, und deshalb die Box durch "wake on lan" immer an bleibt?

 

[_TokTok_]

Bei mir geht Hibernate nicht (DS 207+, Beta 716).
Ich habe einen Leistungswächter angeschlossen, der Verbrauch ist konstant bei ca 25W. Download-Service habe ich abgestellt.
Kann es eigentlich sei, daß durch dyndns regelmäßige Abfrage auf neue IP gemacht werden, und deshalb die Box durch "wake on lan" immer an bleibt?

Eventuell unterstützen Deine Festplatten keinen Spin-Down.
WOL unterstütz die DS nicht. Sie telefoniert allerdings in regelmäßigen Abständen nach Taiwan, wie hier zu lesen.

 

[baeumer]

Kann ich denn irgendwie erkennen, ob DS im Hybernate ist (LEDs oder so?). Der Gehäuselüfter bleibt gleich laut.
Außerdem ist mir noch eingefallen, daß ich zwei Einträge in crontab habe (5 Min und 15 Min). Verhindern diese Einträge Hybernate oder würde dann dieser Dienst gestoppt?

 

[Trolli]

Wahrscheinlich sind die Einträge in der crontab dafür verantwortlich, dass Deine DS nicht in den Ruhezustand geht. Was für Einträge hast Du denn da drin?

 

[_TokTok_]

Kann ich denn irgendwie erkennen, ob DS im Hybernate ist (LEDs oder so?)

itari hat Dir ja schon geschrieben, dass man das z.B. in der /var/log/messages sieht. Diese Datei einfach mal auf einen share kopieren und öffnen. Da müsste dann drinstehen ob und wann die DS schlafen geht, bzw. geweckt wird

 

[baeumer]

Mir fällt auf, daß in message immer wieder zu Zeiten, an dem die DS nicht benutzt wurde folgender Eintrag steht:

Sep  5 23:07:51 kernel: svc: bad direction 268435456, dropping request
Sep  5 23:09:54 kernel: svc: bad direction 268435456, dropping request
Sep  6 00:18:18 kernel: svc: bad direction 268435456, dropping request
Sep  6 00:24:45 kernel: svc: bad direction 268435456, dropping request
Sep  6 00:38:01 kernel: svc: bad direction 268435456, dropping request
Sep  6 01:05:25 kernel: svc: bad direction 268435456, dropping request
Sep  6 01:22:23 kernel: svc: bad direction 268435456, dropping request
Sep  6 02:15:35 kernel: svc: bad direction 268435456, dropping request
Sep  6 02:39:24 kernel: svc: bad direction 268435456, dropping request
Sep  6 02:51:55 kernel: svc: bad direction 268435456, dropping request
Sep  6 03:56:01 kernel: svc: bad direction 268435456, dropping request
Sep  6 05:29:05 kernel: svc: bad direction 268435456, dropping request
Sep  6 06:39:20 kernel: svc: bad direction 268435456, dropping request
Sep  6 07:15:35 kernel: svc: bad direction 268435456, dropping request
Sep  6 07:36:14 kernel: svc: bad direction 268435456, dropping request
Sep  6 08:31:51 kernel: svc: bad direction 268435456, dropping request
Sep  6 08:33:44 kernel: svc: bad direction 268435456, dropping request
Sep  6 08:44:46 kernel: svc: bad direction 268435456, dropping request
Sep  6 08:45:12 kernel: svc: bad direction 268435456, dropping request

Einen Eintrag wie Hibernate oder Standby kann ich nicht finden.

 

[baeumer]

Ich habe doch noch hibernates gefunden:

Sep  7 14:56:48 scemd: SCEMD: disk 1 wake up from hibernation 
Sep  7 15:19:48 scemd: SCEMD: disk 1 wake up from hibernation 
Sep  7 15:27:14 kernel: svc: bad direction 268435456, dropping request
Sep  7 15:28:49 kernel: svc: bad direction 268435456, dropping request
Sep  7 15:41:31 kernel: svc: bad direction 268435456, dropping request
Sep  7 15:53:10 kernel: svc: bad direction 268435456, dropping request
Sep  7 16:19:25 kernel: svc: bad direction 268435456, dropping request
Sep  7 16:19:36 scemd: SCEMD: disk 1 wake up from hibernation 
Sep  7 17:03:57 kernel: svc: bad direction 268435456, dropping request
Sep  7 17:18:00 kernel: svc: bad direction 268435456, dropping request
Sep  7 17:59:13 kernel: svc: bad direction 268435456, dropping request
Sep  7 18:11:04 sshd[6988]: fatal: Timeout before authentication for 89.119.11.58
Sep  7 18:16:24 kernel: svc: bad direction 268435456, dropping request
Sep  7 18:43:47 kernel: svc: bad direction 268435456, dropping request
Sep  7 18:54:26 kernel: svc: bad direction 268435456, dropping request
Sep  7 19:02:04 kernel: svc: bad direction 268435456, dropping request
Sep  7 19:09:49 kernel: svc: bad direction 268435456, dropping request
Sep  7 19:27:39 kernel: svc: bad direction 268435456, dropping request
Sep  7 19:42:44 kernel: svc: bad direction 268435456, dropping request
Sep  7 20:02:35 kernel: svc: bad direction 268435456, dropping request
Sep  7 20:07:04 kernel: svc: bad direction 268435456, dropping request

Aber offensichtlich scheint die "bad direction" fehler Hibernate zu verhindern. Aber was ist das für ein Fehler?

 

[baeumer]

Auch im Netz keine Lösung

Ich habe man ein bischen gegooled und einige Anfragen in anderen Foren gefunden, die in Linux-Distributionen den gleichen Fehler hatten, aber bei keiner Anfrage wurde geantwortet. Zwei Post sind:

#1

"This 268435456 value is "0x10000000" hexadecimal. The code expects the value
zero, and we have a stray bit being set in there, bit 28 to be exact."

I do not know what to do with the second bit of information. Also, people seem
to think it is something to do with ports and possibly UDP trying different ports.

I am running testing with 2.6.18 kernel. My Linux machine is connected via
Ethernet to a Netgear DG834GT modem/router/wifi base. My other machine is
running Widows XP and is connected over Wifi . The problem occurs even when the
XP machine is off.

#2

i've recently set up a local nfs server for my disfiles; to keep the WAN
out i have:

iptables -A INPUT -p TCP -i ! ${LAN} -d 0/0 --dport nfs -j DROP
iptables -A INPUT -p UDP -i ! ${LAN} -d 0/0 --dport nfs -j DROP

everthing is working fine so far; however, my logs are full with these
messages:

svc: bad direction 268435456, dropping request

Hat jemand von Euch eine Idee? Hat das überhaupt eine Relevanz für das Hibernate-Problem?

Meine Einträge in crontab:

#minute	hour	mday	month	wday	who	command
0	0	*	*	*	root	/usr/sbin/ntpdate -b time.windows.com 
*/5 * * * * root sh /opt/bin/tps
*/15    *       *       *       *       root    sh /opt/bin/vnstat -i eth0 -u

 

[juergen@net]

Wenn ich das recht interpretiere, weckt der Crond das System alle 5 min für tps und alle 15 min für vnstat
So kann der wohl kaum hibernaten. Kommentier die Zeilen mal aus.
Ausserdem muessen die Felder mit Tab getrennt sein, nicht mit Blanks.
Gruss, Juergen

 

[baeumer]

Ich habe in crontab alles auskommentiert, die DS fährt aber immer nich nicht in Hibernate. Hat denn schon jemand eine Idee bzgl. der Meldung:

Sep 11 07:53:29 kernel: svc: bad direction 268435456, dropping request

 

[Trolli]

Hast Du auch den cron-Dienst bzw. die DS danach neu gestartet?

 

[itari]

svc = service; wahrscheinlich ein Netzwerk-Service, der einen falschen Konfigurationsparameter hat. Kommen diese Meldung immer noch? Wenn ja, und du ein wenig Zeit hast, mach mal folgendes:

Auf der Telnet-Konsole gibt ein: syno_poweroff_task

Dadurch werden alle deine Netzwerk-und Anwendungs-Dienste heruntergefahren. Jetzt kannst mit der DS erstmal nichts mehr wirklich tun. Warte ca. 30-60 Minuten und starte dann die DS neu und schau dir die /var/log/messages an, ob nun die Meldungen noch kommen. Wenn ja, ist es ein falsch konfigurierter Kernel-Dienst (Raid oder so), wenn nein, ist es ein falsch konfigurierter Netzwerk- oder Anwendungsdienst, welcher aus der /usr/syno/etc/rc.d gestartet wird. Das engt die Fehlerquelle auf diese Dienste ein ...

itari

 

[jahlives]

Ausserdem muessen die Felder mit Tab getrennt sein, nicht mit Blanks.

A crontab file consists of lines of six fields each.The fields are separated by spaces or tabs. The first five are integers that specify the following

Habe bei mir zu Hause Leerzeichen und keine Tabs drin und es funzt wunderbar.

Gruss

tobi

 

[Trolli]

Ja, das funktioniert auch. Bis man die DS neu startet. Dann wird die crontab einfach durch die default-crontab ersetzt. Es sei denn, Synology hätte daran in einer der letzten Firmware-Versionen etwas geändert.

Trolli

 

[jahlives]

Ja, das funktioniert auch. Bis man die DS neu startet. Dann wird die crontab einfach durch die default-crontab ersetzt. Es sei denn, Synology hätte daran in einer der letzten Firmware-Versionen etwas geändert.
Trolli

Meinst du den Default crond? Habe vergessen zu schreiben, dass ich cron via ipkg installiert habe und da wird sich Synology wohl hüten mir einfach Files unter /opt/etc zu überschreiben
Heisst das mit dem Default Cron brauch man Tabs und keine Leerzeichen?

Gruss

tobi

 

[Trolli]

Ja. Wie ich schon geschrieben habe: Nach dem Neustart des normalen Synology cron-Dienstes funktioniert die crontab auch mit Leerzeichen. Beim Neustart der DS wird diese aber durch eine default-Version ersetzt. Ähnliches gilt für die Zeilenumbrüche...