staging.inyokaproject.org

Grundsätzlich funktioniert bei mir

systemctl hibernate

auch mit Userrechten, also ohne sudo.

Habe ich jedoch zahlreiche Tabs im Firefox (142.0 aus dem Mozilla DEB-Repository) gelingt kein hibernate mehr. Schließe ich alle oder wenigstens einige der Tabs geht es wieder. An fehlendem Swap kann es eigentlich nicht liegen. top zeigt:

MiB Swap:  10908,0 total,  10908,0 free,      0,0 used

Dabei handelt es sich um eine Swap-Partition und an RAM sind nur 8GB installiert. Also sollte dessen Inhalt doch locker in den Swap passen.

Was könnte ich zur Ursachenforschung noch tun?

coraggioso schrieb:

[…] Habe ich jedoch zahlreiche Tabs im Firefox (142.0 aus dem Mozilla DEB-Repository) gelingt kein hibernate mehr. Schließe ich alle oder wenigstens einige der Tabs geht es wieder.

Da Firefox wesentlich mehr Arbeitsspeicher für sich reserviert, als physisch (RAM) und virtuell (Swap) verfügbar ist, ist schon plausibel, dass unter ungünstigen Umständen so etwas auftreten kann. Ich selber habe es allerdings noch nie beobachtet.

Zur Abhilfe kann man es mit 2 Swap-Partitionen versuchen: Die erste (ca. 2 GiB) verwendet man nur für das Pageing, die zweite (ca. ½ RAM- bis RAM-Größe) nur für den Ruhezustand.

Moin kB,

mit deinem Hinweis auf 2 Swap-Partitionen komme ich nicht weiter. In Ruhezustand steht:

Wenn man mehr als einen Swap-Bereich aktiviert hat, kann automatisch der falsche ausgewählt werden. In diesen Fällen kann man den vorgesehenen als Gerätedatei in die Datei /sys/power/resume schreiben. In der vorhandenen /sys/power/resume steht derzeit:

252:1

Was müsste man denn da nun als Gerätedatei in die Datei /sys/power/resume schreiben? Etwa /dev/dm-1 wegen

coraggioso@coraggioso:~$ swapon --show
NAME      TYPE       SIZE USED PRIO
/dev/dm-1 partition 10,7G   0B   -2
coraggioso@coraggioso:~$

Aber käme dieses /dev/dm-1 dann vor oder nach dem 252:1?

Am einfachsten wäre es vermutlich neben der vorhandenen Swap-Partition noch eine Swap-Datei anzulegen.

Was mir dann aber auch nicht eindeutig klar ist, ist wie ich dann dafür sorgen kann, dass für das Paging diese neu angelegte Swap-Datei statt der Swap-Partition genutzt wird. Evtl. über PRIO aus swapon --show? Aber wie setzt man diese PRIO?

Wenn ich Swap (Abschnitt „swapon“) richtig interpretiere, dann kann ich die Prio auch über die Reihenfolge der Swap-Partitionen/-Dateien in der /etc/fstab bestimmen. Meine Interpretation: würde die neu anzulegende Swap-Datei der /etc/fstab in einer Zeile oberhalb der bisher verwendeten Swap-Partition stehen, dann würde diese auch fürs Paging verwendet werden und nicht mehr die Swap-Partition. Aber ich bin mir halt unsicher ob ich das so richtig interpretiere.

Leider ist das Problem noch immer nicht gelöst. Ich habe aber weitere Beobachtungen gemacht.

Also Firefox verhindert nicht nur ein

systemctl hibernate

sondern auch ein Aufwachen aus

systemctl suspend

Ist ein hibernate nicht möglich und ich nutze dann stattdessen ein suspend, wacht das Notebook nicht aus dem suspend auf, sondern startet stattdessen neu.

Noch etwas habe ich lange beobachtet: es ist NICHT erforderlich dass bereits swap genutzt wird. Selbst wenn top

MiB Swap:  10908,0 total,  10908,0 free,      0,0 used.

(bei 8 GB Arbeitsspeicher im Notebook) anzeigt, also der gesamte Inhalt des Ram selbst unkomprimiert in den Swap passen sollte, klappt kein hibernate wenn mehr als 7 oder 8 FF-Fenster offen sind.

Doch genau dann benötige ich ja den hibernate. Wenn man umfangreichere Recherchen hat und dann z.B. Mittagspause machen will, will man ja deswegen nicht alle FF-Fenster schließen und nach der Pause wieder neu mit der Recherche beginnen müssen.

So muss ich mich nun leider mit temporären Bookmarks behelfen, die ich dann nach Ende der Recherche alle oder teilweise wieder löschen oder umsortieren muss.

Die /dev/dm- Nummern sind zufällig. Dahinter kann LVM oder LUKS oder sonst was anderes stecken.

Beim Resume sollte Swap eigentlich optimalerweise auch als erstes geöffnet werden, wäre dann aber /dev/dm-0. Es sei denn es ist verschlüsseltes LVM, dann wäre dm-0 die LUKS Verschlüsselung und dm-1 das Swap LV darauf.

Aber das ist Zufall, die dm- Nummern werden je nachdem verteilt was zuerst aufgemacht wird im Device Mapper.

Welche Fehlermeldung gibt es denn eigentlich, oder wie macht sich das bemerkbar, daß es nicht funktioniert?

Wenn das System weiterläuft mal sudo journalctl reinschauen bzw. dmesg.

Das ganze Hibernate Zeug war leider immer schon etwas wackelig.

Moin frostschutz, ja es ist LUKS verschlüsseltes LVM.

In der /etc/crypttab steht entsprechend:

dm_crypt-0 UUID=ce054910-abcd-efgh-ijkl-dff78fc7d499 none luks

In der /etc/fstab wird dann auch die Swap als erstes gemountet und zwar als /dev/disk/by-id/dm-uuid-LVM-....

ein sudo journalctl -r zeigt mir nach dem systemctl hibernate mit vielen offenen FF-Tabs folgendes (Auszug)

Sep 04 09:41:03 coraggioso systemd[1]: Starting grub-common.service - Record successful boot for GRUB...
Sep 04 09:41:03 coraggioso systemd-logind[1096]: Operation 'hibernate' finished.
Sep 04 09:41:03 coraggioso systemd[1]: Stopped target sleep.target - Sleep.
Sep 04 09:41:03 coraggioso systemd[1]: systemd-hibernate.service: Consumed 1.602s CPU time.
Sep 04 09:41:03 coraggioso systemd[1]: hibernate.target: Job hibernate.target/start failed with result 'dependency'.
Sep 04 09:41:03 coraggioso systemd[1]: Dependency failed for hibernate.target - System Hibernation.
Sep 04 09:41:03 coraggioso systemd[1]: Failed to start systemd-hibernate.service - System Hibernate.
Sep 04 09:41:03 coraggioso systemd[1]: systemd-hibernate.service: Failed with result 'exit-code'.
Sep 04 09:41:03 coraggioso systemd[1]: systemd-hibernate.service: Main process exited, code=exited, status=1/FAILURE
Sep 04 09:41:03 coraggioso bluetoothd[1071]: Controller resume with wake event 0x0
Sep 04 09:41:03 coraggioso systemd-sleep[42561]: Failed to put system to sleep. System resumed again: Cannot allocate memory
Sep 04 09:41:03 coraggioso kernel: thermal thermal_zone7: failed to read out thermal zone (-61)
Sep 04 09:41:03 coraggioso kernel: PM: hibernation: hibernation exit
Sep 04 09:41:03 coraggioso kernel: Restarting tasks ... done.
Sep 04 09:41:03 coraggioso kernel: OOM killer enabled.
Sep 04 09:41:03 coraggioso kernel: PM: hibernation: Basic memory bitmaps freed
Sep 04 09:41:03 coraggioso kernel: PM: hibernation: Image allocation is 137496 pages short
Sep 04 09:41:03 coraggioso kernel: PM: hibernation: Preallocating image memory
Sep 04 09:41:03 coraggioso kernel: PM: hibernation: Basic memory bitmaps created
Sep 04 09:41:03 coraggioso kernel: PM: hibernation: Marking nosave pages: [mem 0x8d000000-0xffffffff]
Sep 04 09:41:03 coraggioso kernel: PM: hibernation: Marking nosave pages: [mem 0x8bd4f000-0x8cffefff]
Sep 04 09:41:03 coraggioso kernel: PM: hibernation: Marking nosave pages: [mem 0x7c46d000-0x7c480fff]
Sep 04 09:41:03 coraggioso kernel: PM: hibernation: Marking nosave pages: [mem 0x7420e000-0x7420ffff]
Sep 04 09:41:03 coraggioso kernel: PM: hibernation: Marking nosave pages: [mem 0x71db7000-0x71db7fff]
Sep 04 09:41:03 coraggioso kernel: PM: hibernation: Marking nosave pages: [mem 0x71da7000-0x71da7fff]
Sep 04 09:41:03 coraggioso kernel: PM: hibernation: Marking nosave pages: [mem 0x0009e000-0x000fffff]
Sep 04 09:41:03 coraggioso kernel: PM: hibernation: Marking nosave pages: [mem 0x00058000-0x00058fff]
Sep 04 09:41:03 coraggioso kernel: PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]
Sep 04 09:41:03 coraggioso kernel: OOM killer disabled.
Sep 04 09:41:03 coraggioso kernel: Freezing user space processes completed (elapsed 0.004 seconds)
Sep 04 09:41:03 coraggioso kernel: Freezing user space processes
Sep 04 09:41:03 coraggioso kernel: Filesystems sync: 0.014 seconds
Sep 04 09:41:02 coraggioso kernel: PM: hibernation: hibernation entry
Sep 04 09:41:02 coraggioso systemd-sleep[42561]: Performing sleep operation 'hibernate'...
Sep 04 09:41:01 coraggioso systemd[1]: Starting systemd-hibernate.service - System Hibernate...
Sep 04 09:41:01 coraggioso systemd[1]: Reached target sleep.target - Sleep

Ich hoffe, ich habe den relevanten Auszug korrekt erkannt. Ich habe der besseren Auffindbarkeit journalctl -r genutzt. Man muss also von unten nach oben lesen.

coraggioso schrieb:

Leider ist das Problem noch immer nicht gelöst. Ich habe aber weitere Beobachtungen gemacht.

Also Firefox verhindert nicht nur ein ...

BTW: Mit z. B.:

smem -t -p

kannst Du schauen, wie viel Speicher (auch swap-Speicher) der FF benutzt.
Schau mal in deinem FF nach (mit about:config) wie dort die Einstellung für:

browser.tabs.unloadOnLowMemory

ist (true oder false). true ist standard. Wenn true, dann teste mal mit false.

Benutzt Du evtl. ein add-on (oder gleichwertig) für den Tabschlafmodus des FF? Wenn ja, dann deaktivieren.

Moin lubux,

smem habe ich soeben nachinstalliert und werde das mal beobachten.

browser.tabs.unloadOnLowMemory

stand bei mir auf false. Kann mich aber nicht erinnern, dass jemals geändert zu haben. Habe es nun testweise auf true geändert.

add-ons benutze ich derzeit gar keine, nicht einmal einen Werbeblocker o.ä. Lediglich das OpenH264-Videocodec Plugin ist bei mir installiert und aktiv. Aber Tabs mit Videoinhalten sind bei mir so gut wie nie aktiv. Es geht vornehmlich um Seiten mit Texten und evtl. einigen Fotos.

Der Knackpunkt wird dann wohl das hier sein

PM: hibernation: Image allocation is 137496 pages short

Demnach wäre der Swap zu klein.

Es ist aber sehr ungewöhnlich. Das Image das in den Swap geschrieben wird, das ist ja nicht 1:1 der RAM sondern wird auch noch komprimiert. Normalerweise braucht man da nur einen Teil vom tatsächlich belegten RAM für.

Und dann findet man Leute die 48GB RAM und 128GB Swap haben und angeblich ists immer noch zu klein. ( https://github.com/openzfs/zfs/issues/16978#issuecomment-2831990153 )

(Benutzt du zfs?)

Hier https://wiki.clerie.de/notiz/pm-hibernation-image-allocation-is-97054-pages-short die theorie daß es mit swappiness=0 zusammen hängt, falls du das gesetzt hast.

frostschutz schrieb:

die theorie daß es mit swappiness=0 zusammen hängt, falls du das gesetzt hast.

Moin frostschutz, ich danke dir sehr für diesen Hinweis, denn ich hatte swappiness=0 dauerhaft per Eintrag in eine /etc/sysctl.d/vm.swappiness.conf gesetzt gehabt und soeben auf swappiness=10 geändert. Ich werde das jetzt ein oder zwei Tage beobachten und dann hoffentlich den Beitrag auf gelöst setzen können.

PS: und nein ich benutze kein ZFS

Nach einem Tag Beobachtung setze ich das Thema auf gelöst.

Die Lösung war in der Tat der Hinweis von frostschutz auf swappiness=0

Vielen Dank dafür !!!