Schlagwort: Suspend

Script beim Resume in Ubuntu Xenial (16.05)

Raptor 2101Leave a comment

Die Xenial Server Distribution deployed standardmäßig keine pm-utils mehr. Selbst wenn man diese nachinstalliert ziehen die Script-Hooks nur wenn man direkt die Kommandos aufruft. Bei Calls über d-bus werden die nicht ausgelöst. Will man systemweit scriptes bei einem Suspend oder Resume aufrufen muss man ein skript (service) in den systemd einhängen.

Die Service Datei muss unter /etc/systemd/system liegen und auf .service enden. Der Inhalt muss ungefähr so aussehen um nach jedem „aufwachen“ einen Skript auszuführen.

[Unit]
Description=Run start_my_connection
After=suspend.target
After=hibernate.target
After=hybrid-sleep.target

[Service]
ExecStart=/path/to/script/file

[Install]
WantedBy=suspend.target
WantedBy=hibernate.target
WantedBy=hybrid-sleep.target

HTPC mit Ubuntu 14.04

Raptor 21011 Comment

In den letzten zwei Wochen hab ich alle meine Rechner auf Ubuntu 14.04 umgestellt. Eine richtige Bruchlandung hab ich dabei nur bei meinem HTPC (auf Basis XBMC) erlebt. Hier eine kurze Zusammenfassung.

Da mein HTPC minimal aufgesetzt ist und keine unnötigen Dienste enthält hab ich erst mal versucht ein einfaches Upgrade aus dem System heraus zu machen. Die hätte den Vorteil gehabt, dass ich mir die folgenden 4 Stunden sparen hätte können. Das nvidia-337 Package hat das „zunichte“ gemacht. In den Trusty Sources zieht das gleich eine ganze Gnome Installation nach sich, die mir dann mein NoDM-Setup zerschossen hat und gleichzeitig die Platte gesprengt hat.

Danach folgte eine Neuinstallation. Eine stunde ging für ein fehlerhaft erstelltes USB-Image drauf, geschenkt, das ist Murphey, aber danach wurde es haarig. Unter Trusty fehlen einigen Paketen schlicht Abhängigkeiten. Ich hab 30 Minuten rumgefriemelt bis ich gemerkt habe, dass ein nodm kein xserver mehr mitinstalliert. Fehlende libraries werden auch nicht im Log erwähnt. Wozu auch ?

Hier meine manuell installierten Pakete:

  • xinit – wird von nodm benötigt
  • alsa-base/alsa-utils – für den sound
  • consolekit, pm-utils – für den shutdwon/suspend aus xbmc herraus.

Nachdem ich XBMC am laufen hatte, hat mich dann noch der „Shutdown/Suspend“ geärgert. Zum einen sind die oben erwähnten Pakete nicht installiert zum anderen wurde etwas an der Struktut geändert, so dass die Beispiele auf xbmc.org einfach nicht mehr passen.

Die korrekte polickit file sieht wie folgt aus:

[Actions for some-user]
Identity=unix-user:some-user
Action=org.freedesktop.upower.*;org.freedesktop.consolekit.system.*;org.freedesktop.udisks.*;org.freedesktop.login1.*
ResultAny=yes
ResultInactive=no
ResultActive=yes

Wichtig ist die Angabe org.freedesktop.login1.*. Die kann auf Suspend udn Hibernate auch eingeschränkt werden.

Danach lief mein HTPC wieder wie vor der Migration.

Ubuntu – Suspend to Disk nach SWAP-Wechsel

Raptor 21011 Comment

Wer bei seinem Ubuntu-System in die Verlegenheit kommt die SWAP-Partition zu wechseln (z.B. Vergrößerung, Wechsel der HDD gesamt) wird Feststellen, dass danach kein Suspend to Disk (Hibernate/Ruhezustand) mehr funktioniert. Das System wird zwar in den S4 Zustand versetzt, beim booten meckert der Kernel aber irgendwas von „das eine IntiRam-Signatur gefunden wurde aber nicht genutzt werden konnte“. Danach wird das System normal gestartet…

um das Problem zu lösen muss man unter /etc/initramfs-tools/conf.d/resume die UUID der neuen SWAP angeben und ein dpkg-reconfigure hinterher schicken.

sudo dpkg-reconfigure initramfs-tools

Danach will der Hibernate-Modus auch wieder 😉

Server Suspend – a long tail

Raptor 2101Leave a comment

Einleitung

Was braucht man sinnigerweise für einen Server den man Schlafen legen will?

  1. Eine CPU/Board – Kombo die das unterstützt…
  2. Eine Netzwerkkarte die WakeUp-on-LAN unterstützt
  3. Alle Periferiere muss Suspend unterstützen (RAID Controler, etc…)

Primär spielt es keine Rolle welchen Suspend man anstrebt. Ob „Suspend to Ram“ (Suspend) oder „Suspend to Disk“(Hibernate) unterscheidet sich im Administrativen, wie man den Server dazu bekommt, nicht. Es muss einfach ein anderer Wert (Zahl) in /proc/acpi/sleep geschrieben werden…

In meinen Versuchen hat sich Suspend to RAM aber als sinnvoller erwiesen. Das Aufwachen nach einem Suspend ging (erwartungsgemäß) schneller. Aus einem Suspend kam der Server innerhalb von unter 2 Sek wieder zum laufen (laut Kernel – Syslog, zu messen war das kaum sinnvoll…) beim Hibernate benötigte es einen kompletten Boot… das dauerte bei mir ganze 5-7 Sekunden.

Die Einsparung an Energie gegenüber einem Suspend hielt sich in grenzen:

  • Server (Boot): 75 Watt
  • Server (Working): 20 Watt
  • Server (Idle): 15 Watt
  • Server (Suspend): 3 Watt
  • Server (Hibernate): <1 Watt

Der geringe „Gewinn“ war es mir nicht wert meine Sicherheit und die Response-Zeit zu opfern… Man sollte immer bedenken, dass der Memory auf die Festplatte geschrieben wird…. und selbst wenn man den verschlüsselt, ein Angreifer den Server bewegen kann (da er keinen Strom braucht) und in seiner umgebung booten kann… Hat man hingegen ein verschlüsselte Boot-Partition (TrueCrypt etc) nutzt einem der Hibernate nicht viel, da der Server nicht „unbeobachtet“ wieder hoch kommt…

Vorbereitungen

Als erstes muss man die Netzwerkkarte testen bzw fit für WakeUp on Lan (WOL) machen. Wie das geht wird sehr gut hier beschrieben. Zu den einzelnen WOL-Modi:

  • WOL-Packet: Das eigentlich aufwecken über ein WOL/Magic-Packet ist weniger Sinnvoll und erlaubt nur einen Betrieb eines File/Domain-Servers. Beim Booten müssen alle Clientes automatisiert das WOL-Packet lostrehten und der Server darf über die dauer der Session nicht runter Fahren.
  • u/m/b/a: Das Aufwachen des Servers bei Broad/Multi/Uni-Cast ist die (imho) interessanteste Variante. Der Server wird in jedem Fall geweckt wenn er gebraucht wird. Fast alle heute verwendeten Protokolle arbeiten über IP. Dabei impliziert ist das beziehen einer Adresse (DHCP) und das Auflösen einer Adresse (ARP). Beide Protokolle beginnen den initialen Request über Broadcast. So kann man fast alles betreiben: DHCP, DNS, Webserver. Warum im Standart nochmals ein WakeUp on ARP(a) ausgewiesen wird, erschließt sich mir nicht…
  • WakeUp on physikal activity: diesen Modus hab ich bei meinen getesteten Karten nicht zum laufen bekommen. Oder nicht so wie ich das wollte. Entweder wurde der Rechner sofort nach seinem suspend wieder geweckt oder er reagierte überhaupt nicht… wer denn Sinn dahinter versteht, möge es posten…

Shutdown

Ich habe lange gesucht (ok, nicht wirklich lange, aber schon länger… ;)) bis ich eine geeignete Methode gefunden hatte, bzw zu meiner ersten Idee zurück kam. Ich machs kurz: Sleepd und andere Methoden Interupts abzufragen (oder besser deren nichterscheinen) funktionierten nicht oder nur eingeschränkt… Die interessanten Interrupts ließen sich nicht abhören und so was wie Maus und Tastatur nutzt bei einem Server ohne selbige nichts.

Deswegen verwende ich einen Script der alle 5 Minuten via Cron ausgeführt wird. Dieser ist in seiner „Urform“ hier zu finden. Der Script als solches funktioniert prima, musste nur um zwei Funktionalitäten an meine Bedürfnisse angepasst werden.

  • Wenn man den Server als zentralen FileServer für die Home-Dirs nutzt, sollte dieser tunlichst nicht runterfahren, solange ein User angemeldet ist. Das CIFS/Samba Protokoll und deren Implementierungen können das zwar ab, die Programme (KDE, OpenOffice, …) jedoch nicht. Stalled Lockfiles und andere „interessante“ Probleme sind die Folge… Aus diesem Grund habe ich den Script um eine Überprüfung erweitert, ob SMB-User angemeldet sind. Dies erfolgt über „smbstatus“.
  • Des weiteren kam es immer wieder dazu, dass der Server nicht „richtig“ in den Suspend ging, oder nicht ordentlich aufwachte.Dies häufte sich besonders bei häufigen Suspends (ich hatte Testhalber die Überprüfung auf minütlich gesetzt). Nach einer weile /var/syslog-Studium fand ich den Übeltäter. Cron kann zuschlagen, während der Kernel noch am „aufwachen“ ist und im somit abermals einen Schlafbefehl verpassen. Das bringt den Kernel ein wenig aus dem Trab. Um das zu unterbinden hab ich zwei weitere Prüfungen eingebaut. Zum einen wird ein Lockfile angelegt, das erst nach dem beenden von des „echo“-Befehls gelöscht wird, eine Semaphore. Zum zweiten muss zwischen „Aufwachen“ und erneutem Suspend mindestens 30 Minuten liegen. Dies wird mit einem Datei geprüft die mittels „touch“ aktualisiert wird, bevor das Lockfile gelöscht wird. Danach einfach das Datediff abfragen…

Die von mir verwendete Version ist hier zu finden.

Fazit

Der Server steht mir nunmehr 24/7 zur Verfügung, spart sich jedoch Strom da nicht immer an… Zudem zühlt die Uptime auch hoch, obwohl der Server am „Schlafen“ ist, nennt man das cheaten? *G*

Einziges Manko: Aus Sicht der Festplatten handelt es sich um einen „Shutdown“. Zu mindestens wird der Motor komplett stromlos geschaltet. Das Wiederanfahren sowie justieren der Köpfe reduziert die Lebensdauer der Platten entsprechend. Bei guten (verlässlichen) RAIDs sollte das aber kein Problem darstellen.

Links