Skip to content

Linux Schlafstörungen

Mein PC zu Hause hat einen (von mir) kontrollierten Schlaf. Drücke ich den Ein/Aus Knopf oder bin eine Stunde nicht am Rechner geht er in den Schlaf, sprich Standby-Modus/Ruhezustand oder auch ACPI-Zustand S3.
Will ich etwas von ihm wecke ich ihn über den Knopf wieder auf oder schicke über die Fritzbox oder meinem Raspberry Pi den magischen Befehl zum aufwachen übers Netzwerk.

Ist praktisch, funktioniert gut. Oder besser gesagt: funktionierte.

Denn vor gefühlt einer Ewigkeit hörte der Rechner nicht mehr auf die Aufwachkomandos aus dem Netzwerk. Das benötige ich zum Glück nicht mehr so häufig, seit ich den Raspberry Pi habe, aber es ärgerte mich schon aus Prinzip. Aber dann doch nicht genug, um da längere Zeit in die Fehlersuche zu investieren.
Nach irgendeinem Update vor ein oder anderthalb Wochen wollte der Rechner allerdings auch nicht mehr in den Ruhezustand gehen. Zwar ging er in den Ruhezustand, wachte aber sofort wieder auf. Das nervte mich schon sehr viel mehr. Denn ich habe mich daran gewöhnt, den Rechner schnell schlafen zu legen und später dann einfach an gleicher Stelle weiter zu arbeiten.

Nach einiger Suche mit journalctl -f beim Versuch denn Standbymodus zu aktivieren und Kontrolle, was /proc/acpi/wakeup als zum Aufwachen erlaubte Geräte ausgibt kam ich darauf, den NetworkManager zu kontrollieren. Sah eigentlich gut aus, “Vorgabe” klingt nach Standardwerten und die funktionierten jahrelang.
Aber etwas probiert und siehe da: Vorgabe ist falsch. Explizit das Aufwachen auf nur die Magic Packets konfigurieren bewirkt das gewünschte Verhalten:NetworkManager LAN Verbindung

Offenbar hatte vor ewigen Zeiten ein Update dafür gesorgt, daß die Einstellung Vorgabe nicht mehr auf die Magic Packets des WOL Standards reagiert. Dafür mag es Gründe geben, ich würde es eigentlich für mich aber nicht abschalten.
Ein weiteres Update vor ein bis zwei Wochen muss das Verhalten dann noch einmal verändert haben, so daß jetzt aber standardmässig auf andere Signale reagiert wird, die ich hier im Netzwerk rumfliegen habe. Die Fritzbox ist ein UPnP AV-Server, der Raspberry Pi serviert bei NFS und CIFS und was der Blu-Ray Player und das FireTV so im Netzwerk bekannt geben habe ich jetzt nicht nachgesehen. Irgendetwas wurde aber von der Einstellung “Vorgabe” erfasst und hat den Rechner sofort wieder aufgeweckt.

Also habe ich nun zu Hause das getan, was ich bei meinem vorigen Arbeitgeber immer gepredigt habe: das gewünschte Verhalten explizit konfigurieren! Industrieanlagen sind meist auch wichtiger als mein informationstechnisches Wohlbefinden zu Hause, aber es gilt genauso. Also den NetworkManager explizit so konfiguriert, daß er bzw. die Netzwerkkarte nur auf die Magic Packets reagieren soll und schon läuft alles wie es immer war und soll. Er geht wieder brav schlafen und wacht auf Kommando wieder auf. So soll es sein!

Merke: egal ob Industrieanlage oder Daddelkiste: Wenn Du etwas bestimmtes willst, dann stell es auch explizit ein und verlass dich nicht auf die Standardwerte. Denn die können sich ändern. Lesson learned.

Interessanterweise zeigte mein zur Kontrolle herangezogenes Windows (8 · 8.1 · 10) immer bei beiden Problemen das gleiche Verhalten wie mein Linux. Es scheint die Einstellung der Netzwerkkarte also von Haus aus gar nicht anzufassen. Grundsätzlich finde ich das gut, aber ich muss bei Gelegenheit trotzdem mal nachsehen, ob und wo man das tun könnte wenn man es wollte. Denn bei Problemen ist es immer gut ein zweites System zur Kontrolle zu haben und es ist doppelt gut, wenn es ein ganz anderes System ist. Also bei [Hardware]Problemen mit Windows ein Linux zur Kontrolle nehmen und umgekehrt.

Wusch!

so klingt es wenn die Technik an einem vorbeirauscht.
Heute morgen wollte ich auf meinem Firmenrechner nur Wake on Lan aktivieren um ggf. von irgendwo etwas darauf gespeichertes im Zugriff zu haben oder ihn morgens schon von zu Haus starten zu können. Der braucht nämlich manchmal länger zum starten als ich mir meinen Kaffee zu holen…

Blafasel, genug Vorgeschichte. Ich also rein ins BIOS, Funktion gesucht und gestaunt:

WAKE on WLAN?!?!?
Aufwecken über Netzwerk ohne Schnur?! Das habe ich bisher zwar für technisch machbar aber arg unwahrscheinlich und eher nicht wünschenswert gehalten. Und Geheuer ist mir das immer noch nicht, habs erstmal auf das Netzwerk mit Schnur beschränkt.

Aber wenn das mittlerweile üblich ist bau ich mir zu Haus ein Script das morgens systematisch Magic-Packets für alle denkbaren MAC-Adressen erzeugt und rausschickt, die Rechner in der Nachbarschaft sind bestimmt eh alle zu viel (lies: überhaupt) ausgeschaltet wink

Wake on LAN unter Gentoo repariert

Linux

Wake on LAN, also das starten eines Rechners per Befehl aus dem Netzwerk, ist eine sehr praktische Sache, ich benutze es sehr oft um von weiter Weg was nachzusehen.
Ich bin zu Haus per DSL-Router immer im Internet und eben jener DSL-Router (Linksys WRT54GL mit DD-WRT als Firmware) kann bei Bedarf auch den Rechner starten. Ne Minute warten und ich kann auf den Rechner zugreifen. Sehr praktisch und auch Strom sparend, man muss den Rechner nicht auf Verdacht eingeschaltet lassen nur weil man evtl. etwas vom Rechner braucht.
So weit, so gut, doch so kaputt seit einiger Zeit bei meinem Rechner.
WOL funktionierte zuverlässig bei mir, aber nachdem ich ich nach dem Unfall wieder zu Haus war hat eines der anstehenden Updates etwas zerschossen. Was genau es war weiss ich nicht, ein Indiz war aber die Option “RC_DOWN_INTERFACE“ die es mittlerweile unter Gentoo in der /etc/conf.d/rc gibt und per Default auf yes steht und die Funktion in der Netzwerkkarte explizit ausschaltet. Dumm gelaufen. Zu meiner Verteidigung sei gesagt, dass nach meiner Auszeit einfach zu viele Updates anstanden und ich von daher nicht alle Changelogs durchgearbeitet habe. Ein Ändern auf no brachte aber auch keinen Erfolg, also war diese Option nicht Schuld. Da mich das jetzt aber nervte hab ich mich mal drangesetzt und nach kurzem googeln eine Anleitung im Gentoo-Wiki gefunden für WOL.
Neben erwähntem Parameter wird dort noch beschrieben wie man mit ethtool prüft, ob die Funktion in der Netzwerkkarte eingeschaltet ist und, für mich wichtiger, erwähnt, dass ethtool mit 3Com-Karten das nicht kann. Ich hab nun aber ne 3Com im Rechner stecken. Grmpf. Also den auch im Wiki-Eintrag erwähnten Treiber-Parameter gesetzt, dafür vorher den Treiber aus dem Kernel geworfen und als Modul gebaut, und voila: es funktioniert wieder. smile
Da war wohl bei den Updates diese Funktion in der Karte deaktiviert worden. Vermutlich klappte das Abschalten der Funktion gemäss der neuen Direktive in der rc noch, aber die Karte merkt sich das und schaltet es per Default nicht ein und den Parameter auf no zu setzen schaltet es nicht explizit ein sondern verhindert nur das Ausschalten. Wenn dem so ist funktioniert diese Logik aber nur bei Karten, die die Funktion per Default immer wieder Einschalten. Dumm das, werd ich bei Gelegenheit mal prüfen ob dem wirklich so ist und ggf. nen Patch und/oder Bugreport schreiben.


Und die Moral von der Geschichte: Auch wenn etwas lange funktioniert hat kann es im Fehlerfalle helfen einfach so zu tun als wenn es noch nie ging und die Anleitung zu lesen bzw. durchzuarbeiten.

Viellleicht hilft dieser Eintrag dem ein oder anderen – so google will. wink