Jak chcete aby aplikace vyvíjela ještě nějakou aktivitu ke které potřebuje systémové zdroje (a korektní ukončení muže z takových 70% takovou aktivitou být) když se toho nejdůležitějšího nedostává.
Tento problém se obecně řeší nastavením prahů. Podobně jako u omezení zdrojů setrlimit. Komerční unixy to mají i pro případ celkových zdrojů OS.
To ano. Jenže to přece neřeší situaci aplikace. Pro běh systému tedy paměť je, ale aplikace ji už k dispozici nemá. To by mohlo vést ke dvěma možným koncům : Pokusu o alokaci selže. je vyvolána vyjímka a pokud je ošetřena, aplikaci pravděpodobně z 99% ukončí (což má stejný efekt jako SIGKILL), nebo ošetřena není, pokusí se zapsat někam kam nemá a systém ji tentokrát bez pardonu sestřelí. Druhá možnost bude taková, že pokus o alokci se blokne, systém nebude vracet informaci chybějící pameti, bude se snažit někde nějakou splašit a jsme v cyklu.... Leda, že by hrábl do rezervy za limitem, ale pak je ten limit zcela zbytečný.
Navíc, nikde není psáno, že aplikace se hned po obdržení maskovatelného signálu ukončí. Ona klidně může signál ignorovat a dál pokračovat v činnosti. A to vše je jaksi kontraproduktivní a s ttakovým přístupem by pak byl OOM Killer de facto zbytečný.
Jistě, že ten signál může špatný programátor ignorovat, i když to naruší konzistenci dat aplikace. Špatný programátor může cokoli.
Ano, ale programátoři Linuxu se vždycky (jindy lépe, jindy hůře), aby systém takovým programátorům kladl do cesty co nejvíce překážek a co možná nejvíce minimalizoval škody, které mohou svými špatně navrženými aplikacemi napáchat...
Ať se na to dívám jak chci, tak pořád se mi zdá taková benevolence ze strany sytému kontraproduktivní a pro uživatele více problematická, než stávající řešení. jiná možnost by byla, kdyby si uživatel mohl sám určit, jak má systém v takovýchto případech postupovat. veškeré následky jdou potom však na triko uživatele...
Zobrazit příspěvky
Dokonce existuje i české diskuzní fórum, změřené právě na toto distro.
