Nedávno jsme psali, že Fedora 32 patrně dostane démon EarlyOOM pro případ nedostatku paměti. Lennart Poettering v pondělí napsal, že systemd dostane podobný démon oomd, na kterém již několik let pracuje Facebook.
Mělo by se tak stát, jakmile bude oomd dokončen, což by mohlo být tak asi půl roku nebo rok, ale bez záruky. Nový oomd nebude potřebovat žádné nastavování a měl by dobře fungovat i na desktopu. Současná verze oomd v GitHubu stále nějaké nastavování vyžaduje.
(zdroj: phoronix)
nejsem priznivcem sYsTeMd, i kdyz ho pouzivam, obcas nejake divne chovani resim workaroundama, ale jednu systemd noninit cast pouzivam rad, na strojich s UEFI co maji moznost vlastnich klicu...
misto Grub zavadece pouzivam sicherboot, ktere vyuziva systemd-boot zavadec...
jde o pouziti s FullDiskEncryption, na disk 1x EFI oddil, 1x LUKS, sicherboot pripravi klice, ktere importuju do UEF(po te co z UEFI smazu Microsoft klice)I, pripravi efi binarku obsahujici jadro+initramdisk kterou automaticky podepise timto klicem...
narozdil od pouziti Grub kdy i kdyz instalaci *buntu udelam na rucne pripravenej opravdu FDE disk (vychozi instalace dela i u EFI oddelenej boot kam dava jadro + initramdisk ktere jsou tedy dostupne utocnikovi) tak je stale "teoreticka" moznost ze nekdo s pristupem ke stroji napadne Grub (i kdyz vyzaduje vetsi znalosti a doimplementovani podpory tcpio, ssh/ftp/cokoliv primo do Grubu, protoze jinak po nahozen jadra by keyloger zapadnul), tak v pripade sicherboot by bylo potreba zautocit na UEFI, preflashnout bios, vyndat baterkou atd, protoze jinak neumozni start jineho nez "mnou" podepsaneho...
Vtípky stranou — mít tuhle funkcionalitu v systemd dává perfektní smysl. Systemd má totiž k dobrému rozhodnutí daleko víc informací, než kernel, mj. zná závislostní graf všech služeb (a jejich cgroups). Má tak možnost předejít situacím, kdy oom_killer zastřelí xorg nebo jiný proces, na kterém závisí stovka dalších, a tím ochromí celý stroj.
10. 1. 2020, 21:46 editováno autorem komentáře
Nějaké takové možnosti jsou, třeba co jsem rychle z hlavy našel (man madvise):
MADV_FREE (since Linux 4.5)
The application no longer requires the pages in the range specified by addr and len. The kernel can thus free these pages, but the freeing could be delayed until memory pressure occurs. For each of the pages that has been marked to be freed but has not yet been freed, the free operation will be canceled if the caller writes into the page. After a successful MADV_FREE operation, any stale data (i.e., dirty, unwritten pages) will be lost when the kernel frees the pages. However, subsequent writes to pages in the range will succeed and then kernel cannot free those dirtied pages, so that the caller can always see just written data. If there is no subsequent write, the kernel can free the pages at any time. Once pages in the range have been freed, the caller will see zero-fill-on-demand pages upon subsequent page references.
11. 1. 2020, 14:05 editováno autorem komentáře
ČLÁNKY DO MAILU