On Mon, Jun 26, 2000 at 01:06:23PM +0200, Torsten Werner wrote:
On Mon, Jun 26, 2000 at 12:20:35PM +0200, Reinhard Foerster wrote:
On Mon, Jun 26, 2000 at 08:34:51AM +0200, Torsten Werner wrote:
$ help ulimit
Davon wird der Speicher auch nicht groesser und die Killstrategie des Kernels nicht beeinflusst.
Ich weiss ja nicht, was Du fuer einen Kernel benutzt, aber meiner macht folgendes:
~$ ulimit -d 10 ~$ ls ls: Memory exhausted ~$
Schon klar. Nur ist das keine Lösung fuer Andres Problem. Du muesstest fuer alle gleichzeitig laufenden Programme ein Limit vergeben und in der Summe der Limits unter Mem+Swap bleiben.
Das ist sicher nicht der Weisheit letzter Schluss, aber in vielen Faellen ausreichend, um beispielsweise wildlaufende netscapes oder aehnliche Sachen im Zaum zu halten und zu verhindern, dass ein wichtiger nfsd abstuerzt.
OK, als fast hack brauchbar.
Ein grober Fehler der ueblichen Distributionen ist es ausserdem, dass ein abgestuerzter Daemon meist nicht automatisch erneut gestartet wird.
Sehe ich völlig anders. Wenn ich ein korrektes Programm (was bei Miniprogrammen möglich sein sollte) starte, will ich davon ausgehen koennen, das dieses so lange laeuft, bis es sich beendet oder auf Wunsch von aussen beendet wird. Der Kernel *darf* es einfach nicht von sich aus killen denke ich. Dann muss ich diesen Fall auch nicht durch start per initab o.ae. behandeln. Es ist also eine Fehler des Kernels (oder evtl. des Speicherwaltungskonzepts von Unixen), wenn er die Prozesse auf die Art killt, wie Andre geschrieben hat. Komischerweise passiert das bei andern Unixen so selten bis fast nie, das dieser Prozesskilleffekt ausserhalb von Linux eingentlich unbekannt ist. Es geht also auch anders.
Andre: Was fuer ein Kenrel war es bei dir 2.0 oder 2.2 ?
Reinhard