Leap 16.0: Loop beim Deaktivieren der Swap-Partition

Hinweis: In dem Thema Leap 16.0: Loop beim Deaktivieren der Swap-Partition gibt es 4 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.

    Nachdem mein System (Laptop, OpenSuse Leap 16.0) sporadisch beim Herunterfahren immer mal wieder hängen blieb, konnte ich nun (endlich) das Problem einkreisen:

    Immer wenn swap space benutzt ist, ist eine saubere Deaktivierung der (swap) Partition nicht mehr möglich.

    Code
    rhea:~ # swapon --show
NAME           TYPE      SIZE USED PRIO
/dev/nvme0n1p8 partition   8G 4,6M   -2 
rhea:~ # swapoff /dev/nvme0n1p8


    Der swapoff endet nicht. Die Lüfter laufen auf Hochtouren. System ist 99% busy

    Code
    rhea:~ # ps aux | grep swapoff
root        5406 99.7  0.0   7112  4740 pts/0    R+   11:57   4:21 swapoff /dev/nvme0n1p8


    Im Journal ist nichts verdächtiges was auf einen IO Fehler hinweisen würde. Es wird keine LUKS/Verschlüsselung für die swap Partition benutzt. Aktuelle Patches sind eingespielt.

    Habe das Problem auch noch auf einem weitere Rechner.


    Ist das ein Kernel-Bug oder was könnte es sonst noch sein?

    So etwas kann passieren, wenn der zu beendende swap-Prozess seine Daten nicht los werden kann, z.B. weil das RAM voll ist. Das kannst du ja überprüfen.


    Manche benutzen anstatt einer swap-Partition lieber zram und einen größeren Speicher.

    Für den Inhalt des Beitrages 326656 haftet ausdrücklich der jeweilige Autor: luigi

    Zitat

    weil das RAM voll ist.

    nee. Ist es ja nicht (mehr). In der Situation (siehe swapon --show) waren 4 MB von 8 GB swap belegt. Von dem 32 GB RAM waren nur ~5 GB belegt. Die 4 MB wurden so ca bei 90% RAM Auslastung genutzt. An den 32 GB war ich nie dran..

    Bei 32 GB RAM ist es jedenfalls sinnvoller, auf eine swap-Partition zu verzichten und stattdessen auf zram zu setzen. Dabei wird Arbeitsspeicher als komprimierte Auslagerungsdatei genutzt. Das ist dann deutlich schneller als die langsamen Zugriffe auf Festplatte oder SSD.


    Ich glaube, dazu muss systemd-zram-service installiert werden.

    Für den Inhalt des Beitrages 326661 haftet ausdrücklich der jeweilige Autor: luigi

    Danke für den Hinweis. Ich werde dies sicherlich in Betracht ziehen, wenn es da nach einigen Tagen/Wochen keine Lösung gibt. Aber für die nächsten Tage/Wochen will ich noch nicht glauben, dass dies beim SLES-Kernel wirklich 'works as designed' sein soll ... (es kann/darf nicht sein, dass man im laufenden Betrieb kein swap device mehr inaktiv schalten kann... Sonst bricht gerade eine Welt für mich zusammen :/ )