SWAP-Leichen entfernen

[hermann72pb]

Ich bin gerade dabei FREETZMOUNT den ersten AVM-Änderungen anzupassen und hatte da ein Auge auf Behandlung von SWAPs geworfen. Zwar hatte jemand da irgendwann mal die Behandlung vom SWAP verbessert indem es auch in FREETZMOUNT mitbehandelt und automatisch aktiviert/deaktiviert wird, dies funktioniert jedoch nur mit SWAP-Dateien und nicht mit SWAP-Partitionen zuverlässig.
Ich hatte gerade z.B. vergessen SWAP zu stoppen und hatte meinen Stick samt SWAP-Partition herausgezogen. Diese Aktion hat leider fatale Folgen, denn in der proc-Datei ist die alte SWAP-Partition fest verankert:

root@fritz:/var/mod/root# cat /proc/swaps
Filename                                Type            Size    Used    Priority
/dev/sda3                               partition       128512  0       -5
r

Und kann von dort nicht entfernt werden:

root@fritz:/var/mod/root# swapoff /dev/sda3
swapoff: /dev/sda3: No such device or address

Die Datei /proc/swaps scheint von irgendeinem Prozess belegt zu sein und lässt sich weder löschen noch editieren.
Ich dachte, ich finde mal den Verursacher und lasse ihn killen:

root@fritz:/var/mod/root# ps | grep swap
   25 root         0 SW   [kswapd0]
 1394 root      1488 S    grep swap
root@fritz:/var/mod/root# kill 25
root@fritz:/var/mod/root# ps | grep swap
   25 root         0 SW   [kswapd0]
 1396 root      1488 S    grep swap
root@fritz:/var/mod/root# killall 25
killall: 25: no process killed

Allerdings vergeblich, wie ihr sehen könnt.
swapoff -a hat auch keine Wirkung.
Die Logik von unserem rc.swap ist leider so, dass man in so einem Zustand nicht mehr unternehmen kann. rc.swap denkt, es sei alles in Ordnung, weil sie sich aus /proc/swaps bedient.
Meine Idee wäre solche

swapoff: /dev/sda3: No such device or address

in rc.swap abzufangen und daraufhin solche "tote" SWAPs aus der Datei /proc/swaps zu löschen. Bloß, wie mache ich das? Oder blebt reboot als einzige Möglichkeit?

MfG

 

[cuma]

gesehen? Ein Punkt ist aber noch offen: beenden von swap beim "aushängen" der SwapPARTITION

 

[hermann72pb]

Ja eben cuma, genau hinter diesem Problem laufe ich jetzt her. Und ich weiß schon, dass ich in AVM-s /hotplug/storage noch eine Sektion dafür anfassen muss und zum libmodmount.sh portieren, nämlich die, wo die kompletten Medien und nicht nur einzelne Partitionen entfernt werden. Dort könnte man eine Prüfung nach /proc/swaps unterbringen, die dann checken würde ob das zu entfernende Medium (z.B. /dev/sda) eine SWAP-Partition unter /proc/swaps hinterlegt hat oder nicht und dann entfernen.
Auf dem Wege ist mir aber -wie ich oben sagte- aufgefallen, dass wir im schlimmsten Falle (einer zieht den Stick ohne Ankündigung) momentan ziemlich in eine Falle tappen, aus der ich momentan überhaupt keinen Ausweg kenne. Nativ würde ich sagen, swap-Daemon killen und Ruhe ist es. Es gibt aber anscheinend keins, oder ich kann ihn nicht killen.
Übrigens, ich hatte in FREETZMOUNT die Meldungen für AVM-Ereignisse verbessert. Zu einem, kommt da nun auch eine Meldung, wenn eine partition als SWAP eingebunden wird, zum anderen schreibe ich neben dem Namen (uStrorXY, oder eben als Label) noch die /dev/sdN-Bezeichnung, damit man es besser nachverfolgen kann.
Und eigentliche Motivation zur ganzen Aktion war, dass AVM jetzt do_umount in zwei Funktionen verteilt hat und genau dies wollte ich eigentlich einpflegen. SWAP ist sozusagen Nebenprodukt.

MfG

 

[cuma]

Wenn jemand einfach seinen Stick abzieht ist das halt Pech, ich denke nicht dass man dagegen etwas machen kann. Alle Programme & Daten oder gar die Partition können dadurch zerstört werden.
Einen Hook für das unmounten von geräten habe ich noch nicht gefunden, wenn du das machst wäre cool

 

[hermann72pb]

Wo du gerade hier bist, cuma, habe ich eine Frage zu diesen autostart/autostop-Sektionen von rc.swap. Werden sie nur von FREETZMOUNT benutzt oder noch wo anders? Ich würde nämlich gerne Rückgabewerte etwas anpassen, dass rc.swap z.B. nur dann 0 zurück gibt, wenn wirklich eine Partition als SWAP eingebunden wurde und sonst Fehlerwerte. Denn ich hatte zwar die Meldung für AVM-Ereignisanzeige fertig gemacht, sie würde aber momentan in jedem Fall kommen, selbst wenn die Partition (warum auch immer) nicht als SWAP eingebunden werden kann.
Zum "selbst schuld", wenn einer Stick abzieht weiß ich noch nicht genau. Denn momentan passiert das auch ohne Eigenverschulden, sondern weil es noch nicht auf unserer Seite sauber läuft. Deswegen will ich schon gerne die Möglichkeit haben "SWAP-Leichen" zu beseitigen.

MfG

 

[linuxkasten]

Eventuell lässt sich der kswapd ja mit killall -9 kswapd killen. Wäre allerdings der "gewaltsame" Weg.

 

[hermann72pb]

root@fritz:/var/mod/root# killall -9 kswapd0
root@fritz:/var/mod/root# ps | grep swap
   25 root         0 SW   [kswapd0]
 1416 root      1488 S    grep swap

Nein, leider nicht. Was sind es für Prozesse in eckigen Klammern?

MfG

 

[cuma]

Hab mir die rc.swap angeschaut, die liefert doch 0 nur wenn es okay war, sonst 1.
autostart/autostop wurde auch von den alten storage-Patches genutzt, ich glaube die sind aber mittlerweile alle nicht mehr aktuell.
Die Meldungen im Errignisprotokoll sind ganz nett, hab die aber noch nie gesehen da ich da nicht hineinschaue. Könnte man das zusätzlich noch per Syslog ausgeben?
kswapd0 läuft übrigens bei mir auch, wenn kein Swap aktiviert ist. Die eckigen Klammern sind für Kernel-Threads, bzw wie sie gestartet wurden

 

[hermann72pb]

Wenn du mir verraten würdest, wie ich syslog am besten ansprechen kann, würde ich es tun. Allerdings muss man es extra/zusätzlich machen. AVM-Meldungen sind deren events, da kann man den Text der Meldung wenig beeinflüssen. Außerdem wird bei diesen storage-Sachen noch Einiges an die serielle Konsole geschickt.

Mit dem Freigeben dieser verdammten Datei klappt es bei mir immer noch nicht. Ich starte die Box extra nicht neu, um den Fall so bekämpfen zu können.

Die Rückgabewerte sind nicht immer und nicht durchgehend sauber, sonst würde es ja bei mir im Bild nicht diese erfolgreiche Meldung über SWAP stehen.

root@fritz:/var/mod/root# /etc/init.d/rc.swap autostart /dev/sdb3
root@fritz:/var/mod/root# echo $?
0
root@fritz:/var/mod/root# cat /proc/swaps
Filename                                Type            Size    Used    Priority
/dev/sda3                               partition       128512  0       -5

Es gibt da einige Fälle, wo 0 trotz Fehler zurückgegeben wird. Aber wie gesagt, ich versuche es abzufangen und werde es einpflegen. Es dürfte nicht stören.
Und die Stelle in "storage" habe ich auch gefunden, wo alles nacheinander ausgehängt wird und wo man swapoff für die SWAP-Partition einbauen könnte. Das ist remove-Sektion. Die werde ich wohl zu uns nach libmodmount.sh umziehen müssen und dort drinnen was zusammenbasteln.
Ich hatte gerade noch eine andere Idee gehabt, nämlich ins "/var/media/devmap" die SWAP-Partition einzutragen. Dann würde sie auf jeden Fall do_umount() durchlaufen und dort könnte man sie abfangen. Das Problem ist: Ich weiß nicht, ob AVM devmap nicht für sonstwas nutzt. Eigentlich beschreiben sie die Datei abhängig davon, ob was unter /proc/mounts steht. Und SWAP-Partitionen stehen bekanntlich nicht unter mounts. Von daher bleibe ich bei meiner ursprünglichen Variante.

MfG

 

[sf3978]

..., wie ich syslog am besten ansprechen kann, ...

Im Skript kann man es z. B., mit logger machen:

logger -t info [ip_archiv] "$(date && /usr/bin/get_ip -d)"

Oct  9 21:05:21 fritz user.notice info: [ip_archiv] Sat Oct  9 21:05:21 CEST 2010 ##.###.##.##6

 

[RalfFriedl]

Die Datei /proc/swaps scheint von irgendeinem Prozess belegt zu sein und lässt sich weder löschen noch editieren.

Alles, was unter /proc (und unter /sys) steht, sind keine normalen Dateien, sondern Schnittstellen zum Kernel, die wie Dateien aussehen und über die man Informationen auslesen oder setzen kann. Löschen kann man diese grundsätzlich nicht, und /proc/swaps kann nur gelesen und nicht verändert werden.

Eine aktive Swap-Partition zu entfernen ist keine gute Idee, wobei Du in diesem Fall das Glück hast, daß nichts auf dieser Partition belegt war. Trotzdem ist es vermutlich das Beste, die Box neu zu starten.

Möglicherweise entfernen neuere Kernel-Versionen die Swap-Partition automatisch, wenn der USB-Speicher entfernt wird, wobei es keine gute Lösung gibt, wenn tatsächlich etwas auf diese Partition ausgelagert wurde.

 

[cuma]

Der falsche Return-Wert wird ausgegeben, da du wohl noch die "defekte" Swap-Partition hast. Dies sollte mit r5948 gelöst sein

 

[hermann72pb]

Danke fürs Korrigieren.
Ich war schon fast fertig mit dem Programmieren vom Entfernen von SWAP-Partitionen, als ich gesehen hatte, welchen Unfug AVMs da verbrochen haben. Sie haben von Version 80 auf 86 komplett die Aufrufparameter von einigen storage-Sektionen umgeworfen. Der berühmte do_umount wird nicht mehr mit 4 Aufrufparameter aufgerufen, sondern irgendwie anders. Das Blöde liegt daran, dass $3 nun $2 ist und $2 gar nicht mehr gibt. Diese Idioten von AVM sollte man zum Nordpol schicken, anstatt sie überhaupt Shell-skripte schreiben zu lassen.
Es wird also keine schnelle Nummer mehr, wie erhoft. Ich muss beide storage-Skripte (80 gegen 86) genau unter die Lupe nehmen und versuchen unter FREETZMOUNT eine Autoerkennung der Parameter einzubauen. Sonst kann man nicht mit dem gleichen FREETZMOUNT ältere und neuere Boxen bedienen.

MfG

 

[cuma]

Ich glaub fast sowas wird mit Absicht gemacht...
Schau doch wieviele Parameter es gibt ($#) und berechne dann den fehlenden

 

[hermann72pb]

Wenn das so einfach wäre...
Die Anzahl der Parameter ist leider nicht eindeutig definiert. Die gleiche Funktion kann entweder mit 3, 4 oder sogar 5 Parameter angesprochen werden, je nachdem woher die Anfrage kommt. Aber ich habe mir da schon was zurecht gebastelt. Glücklicherweise kann man anhand eines Parameters (Nr.1 oder Nr.2, je nach Funktion) ziemlich leicht erkennen, wie es angesprochen wird. Sowas in der Art:

do_umount ()
{
	if [ "${1:1:3}" == "dev" ]
	then # old parameter style
		local mnt_path=$2	# /var/media/ftp/uStorMN
		local mnt_name=$3	# uStorMN or LABEL
	else # new parameter style
		local mnt_path=$1	# /var/media/ftp/uStorMN
		local mnt_name=$2	# uStorMN or LABEL
	fi
	local err_code=0
....

Betrifft glücklicherweise auch nur umount Operationen. Bei mount-Operationen habe ich ziemlich viel in den originalen AVM-Dateien drin gelassen, sodass es sich dort ausgleicht, wenn die AVM-s was ändern. Die Schnittstelle zu do_mount() ist bei näheren Betrachtung gleich geblieben.

Ich hatte aber eben eine unschöne Sache entdeckt, warum es auch bis jetzt mit Aushängen von SWAP-Partitionen nicht geklappt hat. In den storage-Skripten gibt es zwei Sektionen zum Aushängen von Medien:
1. unplug, um eine einzelne Partition auszuhängen:

/etc/hotplug/storage unplug /var/media/ftp/SYSTEM

2. remove, um ein komplettes Medium zu entfernen:

/etc/hotplug/storage remove 002 /proc/bus/usb/001/002 sda # (hier nach altem Still mit 3 Parametern)

Jetzt dürft ihr raten, was zum Entfernen von kompleten Medien ratsam wäre? Natürlich zweite Möglichkeit. Und genau dort hatte ich meine Sachen zum Aushängen von SWAP-Partitionen runtergebracht.
Und was macht AVM in deren WebIF, wenn man den Button "sicher entfernen" drückt? Sie entfernen per unplug manuell nacheinander nach und nach alle Freigaben, anstatt sich per remove bequem zu bedienen. Wenn sie den Erfolg melden, bleibt die SWAP-Partition natürlich immer noch nicht angefasst, weil sie diesen sequentiellen Weg gehen.
Man kann natürlich jetzt den Stick hart abziehen. Dabei wird die "stop"-Sektion vom storage-Skript angestoßen. Allerdings lande ich in einem solchen Fall bei meinem alten Problem:

root@fritz:/var/mod/root# cat /proc/swaps
Filename                                Type            Size    Used    Priority
/dev/sda3                               partition       128512  0       -11

bleibt hängen und ist nicht herauszubekommen.

MfG

 

[cuma]

Vielleicht funktioniert es besser, wenn man die Swap-Partition in devmap einträgt? Evtl wir sie dann mit "unplug" ausgehängt?

 

[hermann72pb]

Ich habe da meine Bedenken... Wer weiß, wofür AVM da diese devmap sonst verwendet. Mediaserver, Samba, Ftp... Es ist unschön...

Ich habe da eine andere Idee, an der ich momentan mit Hochdruck arbeite. Ich kann in diese unplug-Sektion etwas Intelligenz einbauen und vor dem Verlassen checken, ob noch Partitionen auf dem besagten Medium geblieben sind. Wenn es gerade die letzte Partition war, dann kommt noch eine Prüfung darauf, dass es vom ctlmgr aufgerufen wurde. Und wenn diese zweite Bedingung erfüllt ist, dann rufe ich als "Extra-Wurst" für diesen konkreten Fall mein swap_remove().
Leider haben die AVMs auch hier mir einige Hürden in Weg gelegt: Sie rufen es nicht direkt aus ctlmgr (so wäre es für mich leichter nach $PPID zu erkennen), sondern lassen eine berühmte "sh -c" starten.
Ich bin gerade dabei per top, grep und co diese Eltern-Kind-Beziehungen sauber zu zerlegen, damit man eindeutig sagen kann: Jawohl, ctlmgr war das und deswegen machen wir swap umount.
Leider haben AVMs da noch ein Paar unschöne Dinge in unplug-Sektion eingeführt, die ich zunächst blind übernommen hatte, weiterhin aber wahrscheinlich doch rausschmeiße. Es werden z.B. bei jedem unplug einer einzigen Partition ALLE Partitionen zunächst mal auf RO gesetzt. Ist vielleich eine interessante Lösung für AVM, um remove wiederum mal nicht zu benutzen. Bei uns würde sowas allerdings dazu führen, dass alle Partitionen nachher auf RO bleiben (nach dem unmount-Knopf).

MfG

 

[hermann72pb]

FREETZMOUNT: an XX.04.86 angepasste Version + SWAPOFF

Nun ist es vollbracht und der erste Schuss sitzt. Es funktioniert sowohl auf meiner 7170 als auch 7270. Nach Wunsch von cuma streut der FREETZMOUNT nun in alle mögliche Richtungen mit seinen Log-Meldungen. Leider noch nicht immer passend und gelungen, das ist aber alles Kosmetik, die man nachher noch ändern könnte.
Patch gegen Trunk ist bei. Da es von mir sowohl auf einer 7170 (FW80) als auch auf einer 7270v2 (FW86) erfolgreich getestet wurde, gehe ich davon aus, dass es sonst auch funktionieren sollte und kann von mir aus eingecheckt werden.
SWAPOFF nach dem aushängen aus AVM-WebIF heraus funktioniert nach dem oben vorgeschlagenen Prinzip: Wenn letzte Partition vom besagten Medium entfernt wurde UND ctlmgr als Verursacher anhand einer komplizierten Kette der Vererbung identifiziert wurde, dann wird SWAPOFF angestoßen. Ansosten sollte man ihn eigentlich über /etc/hotplug/storage remove initiieren. Dazu kann man später im FREETZ-WebIF noch entsprechende Knöpfe cgi-mäßig anlegen.
Einige kosmetische Unschönheiten:
1. Bei 86-Firmware kommt im AVM-Log das Wort "Partition" doppelt. Hängt damit zusammen, dass bei älteren Firmwares da keine "Partition" stand und ich das Wort da reingebracht hatte. Natürlich hat AVM wieder in die gleiche Richtung mitgedacht. Das lassen wir später korrigieren.
2. Einige Meldungen im SYSLOG klingen etwas komisch, bzw. sogar überflüssig. Liegt zu einem an meinem Englisch zu anderem daran, dass ich einfach alle AVM-Meldungen, die der seriellen Konsole galten auch nach syslog geleitet hatte. Dies kann man nachher auch optimieren.
SYSLOG:

Jan  1 01:01:04 fritz user.notice FREETZMOUNT: Mounting SYSTEM to device /dev/sda2 ... 
Jan  1 01:01:06 fritz user.notice FREETZMOUNT: Partition SYSTEM (/dev/sda2) was successful mounted
Jan  1 01:01:11 fritz user.err telefon[697]: TAM init error
Jan  1 01:01:11 fritz user.notice FREETZMOUNT: Mounting uStor03 to device /dev/sda3 ... 
Jan  1 01:01:12 fritz user.notice FREETZMOUNT: SWAP Partition uStor03 (/dev/sda3) was successful mounted
Jan  1 01:01:14 fritz user.notice FREETZMOUNT: Mounting uStor04 to device /dev/sda4 ... 
Jan  1 01:01:14 fritz user.err FREETZMOUNT: Partition uStor04 (/dev/sda4): Not supported file system or wrong partition table
Jan  1 01:01:15 fritz user.notice FREETZMOUNT: Mounting NTFS to device /dev/sda5 ... 
Jan  1 01:01:17 fritz user.err FREETZMOUNT: Partition NTFS (/dev/sda5): NTFS mount error (127)
Jan  1 01:01:18 fritz user.err FREETZMOUNT: Partition NTFS (/dev/sda5): Not supported file system or wrong partition table
Jan  1 01:01:20 fritz user.notice FREETZMOUNT: Mounting EXT3 to device /dev/sda6 ... 
Jan  1 01:01:21 fritz user.err FREETZMOUNT: Partition EXT3 (/dev/sda6): Not supported file system or wrong partition table
Jan  1 01:01:22 fritz user.notice FREETZMOUNT: Mounting NTFS2 to device /dev/sda7 ... 
Jan  1 01:01:22 fritz user.err FREETZMOUNT: Partition NTFS2 (/dev/sda7): NTFS mount error (127)
Jan  1 01:01:22 fritz user.err FREETZMOUNT: Partition NTFS2 (/dev/sda7): Not supported file system or wrong partition table
Jan  1 01:04:42 fritz user.err FREETZMOUNT: Partition SYSTEM (/dev/sda2) could not be unmount
Jan  1 01:04:46 fritz user.notice FREETZMOUNT: Partition FAT (/dev/sda1) removed
Jan  1 01:06:35 fritz user.notice FREETZMOUNT: Partition SYSTEM (/dev/sda2) removed
Jan  1 01:06:39 fritz user.notice FREETZMOUNT: SWAP Partition (/dev/sda3) removed

AVM-Logs siehe Bilder.

MfG