USB-Mountrechte zerstört

[hermann72pb]

Wegen RAM-Überlaufs kann man es ja leicht simulieren. Ich starte mal ein Update und schon ist im SWAP mit Sicherheit mehr drin, als mein RAM verträgt (7170). Mal sehen, wie sich die Box verhält. Wenn deine Vermutung mit dem Reboot stimmt, kann man da evtl. eine Überprüfung und einen Warnhinweis einbauen.
Zu deiner Idee mounted.cgi nicht nach Freigaben sondern nach Partitionen zu sortieren (wenn ich dich richtig verstehe) bin ich auch schon mal gekommen. Ich hatte es aber zunächst so gelassen, wie es früher realisiert war. Man könnte sicherlich da etwas einbauen, dass die Anzeige der Partitionen tatsächlich nach Laufwerken sortiert wird. Und dann pro Laufwerk einen Knopf "Laufwerk abtrennen" und zusätzlich einen optionalen Bereich für SWAP-Partition.
Dadurch wird allerdings mounted.cgi so groß, dass es überhaupt keinen Sinn macht es in die Hauptseite auch wenn's optional zu includen.

Edit: Nun kommen meine Ergebnisse der Versuche mit dem SWAP
1. Die sda/sdb-Problematik hängt tatsächlich damit zusammen, ob man SWAP vor dem Abtrennen des Sticks deaktiviert oder nicht. Lässt man SWAP "weiter laufen", so zeigt /proc/swaps brav das Vorhandensein vom SWAP, obwohl kein Stick mehr an der Box hängt. Steckt man den Stick wieder rein, so wird er dann als sdb erkannt. Also typisches Verhalten, welches hier mehrfach beschrieben wurde und sich unter dem Sammelbegriff "unsauberes Entfernen" titulieren lässt.
2. Das blöde an der Geschichte ist nur, dass man nachher mit dem SWAP komplett verfangen ist. Weitere "swapoff" oder "swapoff -a" Versuche bringen etweder Fehler oder enden im Nichts. Die nichtvorhandene SWAP-Partition bleibt da hart rumhängen. Und --force gibt es leider nicht für swapoff. Kennt jemand dafür eine Lösung? Wäre für eine spätere Realisierung der Skripte hilfreich.
3. swapoff mit einem "überfüllten" SWAP funktioniert nur bedingt. Nachdem ich mein Speicher provoziert wachsen ließ:

/var/mod/root # aaa=$(cat /usr/sbin/openvpn)
/var/mod/root # bbb=$(cat /usr/sbin/openvpn)
/var/mod/root # ccc=$(cat /usr/sbin/openvpn)
/var/mod/root # ddd=$(cat /usr/sbin/openvpn)
/var/mod/root # eee=$(cat /usr/sbin/vsftpd)

Und dann noch mit mcview eines der Image auf meinem Stick aufmachte, zeigte mir die SWAP-Anzeige eine Belegung von etwa 12MB. Im RAM war auf jeden Fall nicht so viel Platz frei. Erstaunlicherweise hat swapoff es auch gemerkt:

/var/mod/root # swapoff /dev/sda4
swapoff: /dev/sda4: Cannot allocate memory
/var/mod/root # echo $?
1

Daraufhin schloß ich meinen mcview. SWAP-Größe schrumpfte auf etwa 5MB. Nun veranlasste ich wieder den SWAP sich zu beenden:

/var/mod/root # swapoff /dev/sda4
/var/mod/root #

Was auch zunächst ging, bis die Box sich kurz darauf rebootete. Also, hier tippe ich, dass die Erkennung des freien Speicher in diesem Fall entweder schief ging, oder Speicher wurde für das Verschieben der Daten ins RAM zusätzlich gebraucht. Und damit hat swapoff nicht gerechnet.
Zusammenfassend kann man sagen, dass swapoff nur dann Speichermängel erkennt, wenn SWAP so groß ist, dass es auf keinen Fall ins RAM passt. Für Grenzfälle ist die Erkennung nicht zuverlässig und endet in einem reboot.

Obwohl reboot ist immerhin besser als "Einfrieren" der Box. Von daher sehe ich es als nicht besonders kritisch an.

MfG