Gruesse!
* Gerhard Brauer <[EMAIL PROTECTED]> schrieb am [29.03.05 14:17]:
>
> Hallo,
>
> ich suche eine M�glichkeit, einen Rechner in einen "kaputten Zustand" zu
> kriegen.
>
> Folgende B�sartigkeiten w�rde ich gerne simulieren:
>
> - Festplatten/Bussystem nicht ansprechbar
> - /proc nicht ansprechbar
> - CPU "h�ngt"
> - keine neuen Prozesse/Subprozesse mehr m�glich
So, einige Sachen habe ich gefunden, evtl. sind die hilfreich. Mir ging
es v.a. um softwareseitige Hilfsmittel.
a) Um Festplattenausf�lle bzw. nichtbeschreibbare Filesysteme zu
simulieren bieten sich
1) hdparm mit diversen Parametern an. man hdparm
2) die Dateisysteme im Betrieb ro zu remounten. man mount
b) Zum Simulieren das keine Dateien mehr g�ffnet werden k�nnen kann der
Wert in /proc/sys/fs/file-max manipuliert werden. Ein:
echo "20" > /proc/sys/fs/file-max
bewirkt, das nach einer gewissen Zeit keine Programme, Shells etc. mehr
laufen da kein FileDescriptor mehr erh�ltlich ist.
c) Zum Simulieren das keine weiteren Prozesse mehr m�glich sind kann der
Wert in /proc/sys/kernel/threads-max ver�ndert werden. Ein:
echo "10" > /proc/sys/kernel/threads-max
bewirkt, das nach einer gewissen Zeit keine neuen Prozesse mehr erzeugt
werden k�nnen bzw. laufende sich unkontrolliert verhalten.
d) Eine kernel panic kann man �ber MagicSysrequest ausl�sen. Sofern der
Kernel mit MagicSysrequest gebaut ist kann man mit ALT+S-Abf+C eine
kernel panic erzeugen. Das konnte ich noch nicht testen, da mein
Test-Kernel ohne diese Option gebaut war. Die Kernel-Doku gibt zu
sysrequest einen �berblich �ber die weitere Optionen.
Alle o.a. Test, au�er kernel panic, habe ich getestet und der
Software-Watchdog hat sie anstandslos verarbeitet ("gehandelt ;-))
Getestet alles in einer VirtM und mit Kernel 2.4.x
e) Interessant ist auch crashme (apt-cache show crashme), das die
Stabilit�t des Kernels testen soll. Wie in der Doc beschrieben crasht
der Rechner aber nach einiger Zeit und quittiert dieses Maltr�tieren mit
einem sofortigem Reboot.
Was ich allerdings nicht gefunden habe (auch aufgrund nur rudim�nterer
C-Kenntnisse) ist die M�glichkeit z.B. durch fehlerhafte Programmierung
(malloc, Zeiger-manipulation/Adressierung) Speicher�berlauf,
Memory-Leaks oder deadlocks zu simulieren. Vielleicht hat da ein
"Wissender" n�tzliche Code-Fragmente.
Auch direkte Manipulation der CPU (Register, Werte) z.B. mit Assembler
w�ren interessant. Ich wei� nicht, ob es z.B. unter dem Linux-Kernel
�berhaupt m�glich ist. Zu DOS-Zeiten konnte man ja IMHO durch soetwas
die CPU gewaltig durcheinander bringen.
F�r mich geht es darum um die Frage, ob man durch software-seitige
Manipulation einen Rechner in (ann�hernd) so einen Zustand kriegen kann,
wie er oft durch fehlerhafte/schlechte Hardware verursacht wird.
Also Rechner "h�ngt", oftmals geht noch ein Ping, Tastatur l��t noch das
Umschalten zwischen den Konsolen zu aber keine Interaktion mit dem
System mehr. Fehlermeldungen oder ein OOPs ist nicht zu sehen, in den
Logfiles findet sich nach einem Reboot keinerlei Eintrag zu dem Absturz.
Da dann aber oftmals noch die Option mit dem SysREQuest geht oder ein
Dump, kann der Kernel noch nicht vollkommen "tot" sein.
Und das h�tte ich gerne getestet, ob in diesem Zustand ein
Software-Watchdog noch eine Chance hat.
Aber wahrscheinlich sind die Ursachen f�r so einen Zustand so vielf�ltig
(Netzteil, Bus/Platten,...) das eine "Simulation" nicht m�glich ist.
Au�er man hat den betreffenden Rechner wirklich zur Hand und der Fehler
w�re reproduzierbar (was er ja meist nicht ist).
Auf dem betroffenen System hab ich auf jedenfall mal den
Software-Watchdog aktiviert weil "Schaden kann das ja nichts".
Dank an alle (auch f�r die "lustigen" Vorschl�ge)
Gru�
Gerhard
--
Ist Ihnen mutt zu kompliziert? Ihr Mailprogramm zu "fett"?
Sie moegen keine man pages?
Versuchen Sie: rm -rf (ReadMail -Realy Fast)
