Ruhezustand, Standby und Swap

[FragendesMysterium]

Guten Abend,

ich würde gerne unter Jessie den Ruhe- bzw. Standby-Zustand meines Systems vernünftig verwenden.
Leider geht der Ruhezustand unter MATE nur für ein paar mal, ab einer nicht näher definitierten Anzahl von Starts fährt sich das System beim erneuten Versuch fest und ich muss es kalt ausschalten.
Mit KDE geht hier gleich gar nichts, es fährt sich höchstens fest und bringt mich irgendwann zur Passworteingabe des Bildschirmschoners zurück.

Daher die Frage, was hängt da und wie lässt sich das prüfen und beheben?

Leider ist mein StartpageFu ohne genaueres Wissen eher mangelhaft, was sich bisher herausfinden ließ, war, dass diese Modi Gebrauch von der Swap-Partition wohl machen, welche bei mir mit dem gesamten Betriebssystem (abgesehen von $HOME) auf einer SSD liegen, welche 64G groß ist und auch gerade mal um die zwei bis zweieinhalb Gigabyte noch frei hat, vielleicht etwas freimachen und wenn ja, was genau, abseits vom apt-cache?

Ich hab mir gestern auch eine weitere SSD mit 240G eingebaut, sollte ich vielleicht eine 16G große Swap-Partiton darauf anlegen?
Alternativ soll es auch mit einem Swap-File in meinem Home-Verzeichnis gehen, beides muss soweit mir bekannt in die /etc/fstab eingetragen werden.
Was bietet sich eher an und falls möglich, geht das aus dem laufenden Betrieb heraus?

Ich verzeihe die vielen Fragen, doch erscheint mir diese Funktion als durchaus nützlich, weshalb ich sie gerne nutzen würde.


Mit freundlichen Grüßen
Mysterium

[NAB]

Das Thema ist etwas komplex. Erstens muss man unterscheiden zwischen Suspend-to-Disk:
https://de.wikipedia.org/wiki/Ruhezustand
und Suspend-to-RAM:
https://de.wikipedia.org/wiki/Bereitsch ... b#Computer

Nur bei Suspend-to-Disk wird Swap genutzt.

Zweitens haben wir seit Jessie die Wahl zwischen den pm-utils und der eigenen Funktion von Systemd.

Man müsste also erst mal wissen, was du willst und was du nutzt.

[FragendesMysterium]

Guten Abend NAB,

ich schicke meinen Desktop immer per su -c 'systemctl suspend' in den Ruhezustand, also laut Wiki S3, welcher Modus alles in den Arbeitsspeicher schreiben sollte.
Was ich nun festgestellt habe, war, dass sobald syncthing läuft, das ganze sich aufhängt und ich die Kiste neu starten darf, andere male verlaufen wenn, wie im Eingangsposting beschrieben.

Alle Details hab ich noch nicht verinnerlichen können, doch würde ich gern den RAM so weiter verwenden, ohne dass mir das System dabei abschmiert.
Heute hab ich mir erst einmal damit abgeholfen, syncthing wieder per killall abzuschießen und nur aufzurufen, wenn ich etwas abgleichen muss.
Solange ich mein - in einem andern Thema erwähntes - Problem mit Owncloud habe, muss ich so weiterhin verfahren.

Leider ist nicht immer garantiert, dass es auch funktioniert, oft genug hängt sich der Rechner eben auch daran auf, den Ruhezustand vorzubereiten, ohne, dass ich dieses Programm überhaupt gestartet hab
Insbesondere wenn viele Anwendungen geladen sind, passiert das leicht, besonders Sachen wie Iceweasel, Mumble oder Steam.
Daher hab ich mir auch gedacht, im Zweifel wäre die Hybrid-Variante nützlich.


Mit freundlichen Grüßen
Mysterium

[icebear1981]

Ich habe ein ähnliches Problem. Bei mir fährt der PC bei Suspend-to-Disk einwandfrei herunter und braucht beim aufwachen ewig, und bei Suspend-to-Ram ist er schnell im Standby,
aber kommt nicht mehr hoch. Der CPU-Lüfter fängt dann nur an auf Hochtouren zu laufen und der Bildschirm bleibt schwarz.

Mir würde es schon helfen, wenn der PC nur noch in den Suspend-to-Disk machen würde, aber das läßt sich in den Energieeinstlleungen ja leider nicht einstellen.

Hat jemand eine Idee wie man das Problem behebt, oder zumindest das Suspend-To-Ram vermeidet ?

[mludwig]

Suspend to DIsk geht nur, wenn das System eine Swap-Partition hat, die mindestens so groß ist wie der Arbeitsspeicher (denn der Inhalt des Arbeitsspeichers wird ja darin abgelegt.) Gibt es bei dir so etwas?

mludwig

[icebear1981]

Ja mein Swap ist sogar doppelt so groß. Wie gesagt bei mir funbktioniert suspend-to-disk aber suspend-to-ram macht Probleme, das er nicht mehr schafft aufzuwachen. Entweder schick ich ihn immer über Suspend-To-Disk in den Schalfmodus wenn zu lange nix dran gemacht wurde (da weis ich aber nicht welche scripte ich anpassen muss) oder ich bekomme das suspend-to-ram irgendweier zu funktionieren. beides ist gerade gleich kompliziert

[wanne]

Suspend to DIsk geht nur, wenn das System eine Swap-Partition hat, die mindestens so groß ist wie der Arbeitsspeicher

Ne. Das braucht es bei weitem nicht. Zuerstmal Sind da die Programme. Die sind zur Laufzeit im RAM liegen aber nochmal auf der HDD. Brauchen also nicht nochmal gespeichert werden. Das nächste ist Dateisystem Cache der im RAM gehalten wird, damit Zugriffe schneller laufen. Den auf die Festplatte zu schreibe ist auch quatsch da liegt er ja schon. Und zuletzt wrid das ganze vor dem Schreiben komprimiert – Und so Programmstacks bestehen ganz gerne mal praktisch nur aus nullen.
Wenn du jetzt nicht irgend eine ganz krasse Anwendung, wie ein dummes Videobearbeitungsprogramm, dass einen ganzen Film im RAM modifiziert, am laufen hast sollten dir 700MiB in mehr oder weniger jeder Situation ausreichen nimm ein, zwei GiB und du bist auf der sicheren Seite.
Ein bisschen SWAP auf einer SSD schadet aber auch nie. Auch unter den größeren Linux Desktops hat sich eine gewisser Bloat eingeschlichen. ~200MiB werden einfach vor dem Runterfahren nie wieder angefasst. Dei kann man getrost wegswappen und den RAM für etwas sinnvolles nutzen. Und hin und wieder kommt doch mal eine Anwendung, die etwas mehr braucht. Und dann ist man ganz froh, wenn nicht gleich der OOM killer zuschlägt und randomisiert Prozesse killt. Bei heutigen RAM größen aber mehr und mehr irrelevant. Bei 16GiB kannst du bald dein gesamtes System in den RAM stopfen und hast immer noch platz.

[DeletedUserReAsG]

… was nichts an der Tatsache ändert, dass das Problem woanders liegt: s2disk scheint ja zu tun, bei s2ram gibt es Probleme.

Um da allerdings Genaueres zu sagen, oder gar helfen zu können, würden erstmal Informationen benötigt: möglichst genaue Beschreibungen und Bezeichnungen der verwendeten Hardware (um zu schauen, ob da irgendwo Probleme bekannt sind), relevante Logauszüge, sofern vorhanden, und wenn der Kasten nur seine Grafik nicht mehr initialisiert bekommt, aber noch via z.B. ssh zugegriffen werden kann, auch die relevanten Ausgaben von dmesg. Überhaupt wär’s vielleicht nicht zu verkehrt, einen eigenen Thread aufzumachen.

[icebear1981]

Ich denke das ist schon im Sinne des Forums, das wenn es schon einen Beitrag gibt, der eigentlich im groben das Thema in der Überschrift mit angreift, nicht jeder doppelt und dreifach ein Thema aufmacht. ... das wär so wie mit der judäische volksfront und der volksfront von judea ... Niemandem ist geholfen ist, wenn man zum Schluß zig Splitterthemen zu ein und dem selben Gedöns hat und sich jeder später die Infos mühsam zusammensammeln darf, weil keiner bock hat in jedem Beitrag einzeln die selben Antworten zu posten ...
... sorry wenn das jetzt nach Meckern klingt. ich bin gerade etwas kränklich, auf Nachtschicht und versuche auch nur eine möglichst unkomplizierte Lösung für mein Problem zu finden....

... wenn ich wüsste was genau für Informationen weiterhelfen, hätte ich die auch schon gepostet. Der Rechner steht derzeit nur 12Km von mir entfernt, so kann ich erst wenn ich wieder davor sitze nähere Sachen auslesen, dmesg sollte nicht das Problem sein, ansonsten weiß ich aus dem Hut gerade das es ein Dell Rechner mit eine Nvidia Grafikkarte verbaut ist und ich die Propietären Treiber verwende. Was sonst noch an Informationen Wichtig ist wäre für mich gut zu wissen, dann trage ich die Informationen gerne zusammen.

[mludwig]

Suspend to DIsk geht nur, wenn das System eine Swap-Partition hat, die mindestens so groß ist wie der Arbeitsspeicher

...
Ein bisschen SWAP auf einer SSD schadet aber auch nie. Auch unter den größeren Linux Desktops hat sich eine gewisser Bloat eingeschlichen. ~200MiB werden einfach vor dem Runterfahren nie wieder angefasst. Dei kann man getrost wegswappen und den RAM für etwas sinnvolles nutzen. Und hin und wieder kommt doch mal eine Anwendung, die etwas mehr braucht. Und dann ist man ganz froh, wenn nicht gleich der OOM killer zuschlägt und randomisiert Prozesse killt. Bei heutigen RAM größen aber mehr und mehr irrelevant. Bei 16GiB kannst du bald dein gesamtes System in den RAM stopfen und hast immer noch platz.

Das ist zwar alles richtig, aber mir ging es um die Größe des Swap für die Suspend to Disk Funktion. Bei 16GB RAM kann das mit einer 8 GB Swap-Partition funktionieren (wird es vermutlich auch), aber eben nicht immer, abhängig von den geöffneten Programmen. Soll ich vor jedem Suspend ein free -m machen und den Taschenrechner rausholen, ob es reicht oder ob ich besser noch ein paar Firefox-Tabs zumache? Es ist eben schwer das allgemeingültig für jede RAM-Größe und Anwendungsfall zu sagen, aber bei RAM = Swap passt es eben.

mludwig

[outis]

Ja, bei heutigen Speichergrößen passt das wohl in der Regel. Solange der Rechner nicht schon angefangen hat nach swap auszulagern. Früher (heute auch noch?) hieß daher die Regel, swap doppelt so groß wie den RAM anzulegen.

[reuniger]

Ist dieser Thread ein Negativbeispiel für "um den heißen Brei reden"?

Ich meine hier geht es um die Energiesparmodi von Debian und nicht um die Größe von Swap-Partitionen...
Wie kann es sein, dass andere Distributionen (CentOS, Mint, SuSE) mit Energiesparmodi und Bluetooth kein Problem haben und Debian hier anscheinend kläglich versagt - ist doch eigentlich eine Kernelsache???

Gibt es eine sinnvolle und machbare Lösung für die Problematik, oder diskutiert man lieber das "Beigemüse", das einen auch nicht weiter bringt?

[DeletedUserReAsG]

Gibt es eine sinnvolle und machbare Lösung für die Problematik, oder diskutiert man lieber das "Beigemüse", das einen auch nicht weiter bringt?

Man wartet immer noch auf Informationen, welche die Fehler-/Lösungssuche weiterbringen können. Hast du solche, oder ist dieser Beitrag nur ‘n Negativbeispiel für „ich hab’ zwar nichts zum Thema zu sagen, will aber gesehen werden“?

[BenutzerGa4gooPh]

Ist dieser Thread ein Negativbeispiel für "um den heißen Brei reden"?

Code: Alles auswählen

journalctl -b

ACPI-Fehler?
amd- oder intel-microcode installieren, evtl ACPI-Verbesserungen

Des weiteren eine mir unerklärliche Erfahrung:
Laptop, mit Hybridgrafik/Nvidia-Prime, vor FUNKTIONSFÄHIGER Installation von Bumblebee Blackscreen nach Suspend to RAM. Oder eben diskrete GPU per BIOS aus. Danach funktioniert Suspend to RAM.

Wie kann es sein, dass andere Distributionen (CentOS, Mint, SuSE) mit Energiesparmodi und Bluetooth kein Problem haben und Debian hier anscheinend kläglich versagt - ist doch eigentlich eine Kernelsache???

Wegen Fehlern in der ACPI-Implementierung vieler Hardwarekomponenten muss das Betriebssystem dieses undokumentierte Verhalten mit verschiedenen Methoden korrigieren. Das Betriebssystem Linux gibt sich dem BIOS gegenüber als Windows aus, um den besser getesteten Windows-Modus zu erhalten.

https://de.wikipedia.org/wiki/Advanced_ ... _Interface

Also den Ball schön flach halten.

Suspend to DISK funktioniert auf meinem Laptop mit Jessie XFCE nicht. Auch nicht bei einem Test von OpenSUSE 13.2 KDE vor 1 Monat. Auch nicht mit Mint 17.3 vor etwa 1 Jahr. Und Jessie ist sinnvoll "abgehangen". Aber mit Windows 8.1 und 10 funktioniert beides. Begründung in Wikipedia.