Folgendes Problem:
Auf nem (Linux)rechner mit eingebauten Platten sda und sdb hatte ich per usb eine weitere Platte angeschlossen (sdc).
Auf der sdc war eine swap-partition, die ich per swapon /dev/sdc2 verwendet hatte.
Nun gabs ein kleines Kabeloopsie am USB-Stecker, sdc war weg.
Die und andere Platten werden seither (hab' noch nicht rebootet) nur noch als sdd,sde, etc. "erkannt", weil ja diese olle Swappartition noch "an" ist. (swapon listet die noch auf, mit swapoff /dev/sdc2 kommt natuerlich nur "swapoff: /dev/sdc2: swapoff failed: No such file or directory")
Zusaetzlich sind natuerlich im kernellog jede Menge Meldungen "Write-error on swap-device (8:32:xyzblafasel)".
Ich bin mir ziemlich sicher, dass das nach einem reboot alles wieder gut sein wird.
Nur frag' ich mich/euch - gibt's fuer diese Situation einen Weg, ohne reboot den Kernel davon zu ueberzeugen, den swap auf /dev/sdc2 "loszulassen"? (Der wird eh' grad nicht gebraucht ;-))
und zu erwarten, daß der das unbeschadet übersteht.
Ich hab' nicht erwartet, dass der das unbeschadet uebersteht, es hat mich auch erstaunt, dass so garnix "schlimmes" passiert ist. Ich hab' das mit dem swap eher nur zufaellig deutlich spaeter entdeckt, wollte im kernellog eigentlich was ganz anderes gucken...
Die Frage ist eher, was läuft auf dem Rechner?
Wenn nur der Browsercache in den Swap gewandert ist, wird wohl nicht viel passieren.
Bei einer DB kann das schon übler sein.
Ansonsten vm.swappiness=1 setzen, damit er nach Möglichkeit keinen Swap benutzt, in der fstab die UUIDs der Partitionen angeben, statt /dev/sda etc.
Ich hab' nicht gefragt, was ich in Zukunft machen kann (und ich glaube nicht, dass uuids bei dieser Konstellation auch nur einen Furz besser gewesen waeren)
und - ja - tataechlich weiss ich auch, fuer was swap gut ist. Das ist alles nicht der springende Punkt.
Ich hab' gefragt, ob jemand was weiss, was ich momentan machen kann (ausser Reboot).
Und ja, ein reboot ist auf dem Rechner kein Problem. Aber es gibt Rechner, auf denen waere das ein Problem. Und weil ich gerne auch mal was dazulerne, waere es interessant gewesen, wenn da wer "einen Trick17" kennt...
Aber es gibt
Rechner, auf denen waere das ein Problem. Und weil ich gerne auch mal
was dazulerne, waere es interessant gewesen, wenn da wer "einen Trick17"
kennt...
Rechnern das Swap wegzunehmen ist vergleichbar mit dem Ausbau von RAM im Betrieb.
Da ist der einzige Trick ein Reboot, und beten, daß nichts wichtiges im Swap stand.
Es gibt SW, die will/muss unbedingt was auslagern, andere nicht. Im Prinzip ist man hinterher nur klüger. Mit etwas Glück war der RAM noch groß genug und es wurde wenig ausgelagert.
Mannn könnte natürlich die jetzt ausgebaute Swap-Platte lesend genauer ansehen/vergleichen?
3.> gibt's fuer diese Situation einen Weg, ohne reboot den Kernel davon zu ueberzeugen
Ob das gut geht, weiß ich nicht.
"swapoff: /dev/sdc2: swapoff failed: No such file or directory"
"Write-error on swap-device (8:32:xyzblafasel)"
und nicht "No such device or address". Wenn man das wörtlich nimmt...
1
cd /dev
2
mknod sdc b 8 32
3
mknod sdc2 b 8 34
4
swapoff /dev/sdc2
So richtig gute Vorsichtsmaßnahmen fallen mir jetzt keine ein, vielleicht vorher die meisten Programme beenden und remount,ro oder sync machen? Oder gerade das nicht? Aber beim normalen Runterfahren passiert genau das.
Ein interessanter Fall; wie robust ist der kernel bei einem Fehler-der-eigentlich-nicht-passieren-kann?
Ein interessanter Fall; wie robust ist der kernel bei einem
Fehler-der-eigentlich-nicht-passieren-kann?
In so einem Fall kann er nichts tun. Sobald etwas vom jetzt fehlenden Swap-Device gebraucht wird, dürfte mindestens der entsprechende Prozess abschmieren, auch eine Kernel Panic wäre denkbar.
Mit Swap auf einem RAID-Array ist das entspannter.
Ja, viel Hoffnung hatte ich nicht. Mach' einen besseren Vorschlag!
Jede swap Partition hat natürlich eine eigenständige, einmalige UUID.
So leicht lässt der Kernel sich nun auch wieder nicht verarsc… ;-)
Was habt ihr immer mit dieser UUID? Der Kernel kennt sowas nicht¹. Das ist eine Notlösung für Distributionen damit die Installation einfacher wird. Vor allem ist die UUID für diese Aufgabe hier mehrere Ebenen zu weit oben angesiedelt.
Wenn auf dem Rest nicht zu viel ausgelagert ist, könntest du schauen, ob er bei "swapoff -a" nicht bloß dumm in /etc/fstab guckt (und dann wieder "No such file or directory" sagt), sondern stattdessen eine interne Liste durchgeht. Viel Hoffnung hätte ich aber da nicht.
Ansonsten ist das Device zwar halt intern noch geöffnet jedoch nicht mehr zugreifbar, und es kommt natürlich auch durch erneutes Anstecken nicht wieder herbei, da das erneute Anstecken natürlich ein neues Device produziert, denn das vorige ist ja noch belegt, und irgendeine persistente Kennung in Form eines "Fingerabdrucks", die dem Kernel sagt, dass das Gerät jetzt das gleiche ist wie das zuvor, gibt es (sehr wahrscheinlich) nicht.
Wenn auf dem Rest nicht zu viel ausgelagert ist, könntest du schauen, ob
er bei "swapoff -a" nicht bloß dumm in /etc/fstab guckt (und dann wieder
"No such file or directory" sagt), sondern stattdessen eine interne
Liste durchgeht. Viel Hoffnung hätte ich aber da nicht.
Aehm - doch.
Ich erwarte ja nicht, dass jeder Vorschlag gleich ootb funktioniert. Aber er passt wenigstens zu meiner Problemstellung.
Ich brauch' niemanden, der mir erklaert, was ein swap ist, oder dass es nicht so toefte ist, den im laufenden Betrieb zu entfernen, oder mir aus der wikipedia vorliest (Wenigstes ist mir hier ChatGPT noch erspart geblieben). Sonst haett' ich das angefragt.
Insofern danke ich explizit fuer diesen Beitrag, wie auch fuer die anderen fachlich fundierten Beitraege.
Beim rebooten ist nix unerwartetes/aussergewoehnliches passiert.
