Re: Rechner töten
Gruesse!
* Gerhard Brauer <gerhard.brauer@web.de> 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)
Reply to: