LimitNPROC kontra TasksMax: mit számol egy OpenVPN-egység

Egy sikertelen OpenVPN-indítás gyakran erőforrás-panaszként érkezik, egy jóindulatú javaslattal együtt valamilyen korlát emelésére, és a javaslat csak az esetek körülbelül felében működik. E hibák mögött két független számláló áll. Az egyik a kernel korlátja arra, hány feladat tartozik egy valódi felhasználói azonosítóhoz, és ez a folyamat végrehajtásakor öröklődik. A másik egy cgroup-költségvetés, amelyet a szolgáltatáskezelő egy egységre és mindenre alkalmaz, amit az elágaztat. Mindkettő tényleges értékét kiolvasni, arra az egységre, amely valóban fut, kevesebbe kerül, mint egy tippelés.

Két számláló, két kérdés

LimitNPROC a RLIMIT_NPROC egy systemd-név alatt, elszámolási egysége pedig a valódi felhasználói azonosító. Minden folyamat, amely ennek a felhasználónak a tulajdonában van, ugyanabba az összegbe számít, beleértve a más egységek, egy bejelentkezési munkamenet vagy egy ütemező feladat által indított munkát. A korlát ezért nem szolgáltatásonkénti plafon akkor sem, ha egy szolgáltatási egységen belül van beállítva, és egy szolgáltatás, amely minden ügyfélhez segédet ágaztat el, verseng mindennel, ami ugyanazon fiók alatt fut. Egy forgalmas cron-feladat ugyanazon felhasználó alatt olyan vonalon túlra tolhat egy VPN-egységet, amelyet az egyedül soha nem lépett át.

TasksMax más tulajdonossal rendelkezik: az egység cgroupján futó pids-vezérlővel, amely feladatokat számol, nem folyamatokat. A szálak feladatok, így egy egyszálúnak látszó, de munkásmedencével rendelkező démon olyan költségvetést fogyaszthat, amely első pillantásra jóval nagyobbnak tűnik a folyamatszámánál. EffectiveTasksMax azt jelenti, amit a cgroup-hierarchia valójában engedélyez, miután a szülő szeletek elmondták a magukét.

Miért változtatja meg a root-kivétel a választ

A kernel nem alkalmazza a RLIMIT_NPROC-et olyan folyamatra, amely CAP_SYS_RESOURCE vagy CAP_SYS_ADMIN jogosultsággal rendelkezik, ezért a rootként, jogosultságok feladása nélkül futó egység gyakorlatilag korlátlan e beállítás szerint. Ez az egyetlen kivétel magyarázza az egymásnak ellentmondó tanácsokat, amelyeket az emberek cserélnek: a LimitNPROC emelése helyreállítja a jogosultságokat feladó telepítést, és semmit sem tesz azért, amelyik jogosultsággal maradt. Ellenőrizze a User=-et és azt, hogy a démon indítás után vált-e identitást, mielőtt érdemet vagy hibát tulajdonítana ennek a beállításnak. Egy kiváltságos egység, amely később nem kiváltságos fiókra vált, a váltás pillanatában visszakerül a korlát alá, ami a hiba idővonalát is érdemessé teszi az olvasásra.

A hiba szakasza tovább szűkíti. A végrehajtás előkészítése közbeni elutasítás, a démon által jelentett elágaztatási hiba és a cgroupon belül elutasított feladat-létrehozás különböző journal-sorokat ad, és csak az egyikükre válaszol nagyobb költségvetés.

A tényleges értékeket olvassa, ne a shellét

Egy interaktív shell ulimit -u értéke azt a shellt írja le. Nem írja le, mit adott át a szolgáltatáskezelő a démonnak, és semmit sem mond a cgroup-elszámolásról. Kérdezze meg inkább az egységet, a gazdagépen létező példánynévvel, nem egy útmutatóból vett példával.

systemctl show [email protected] -p User -p LimitNPROC -p TasksCurrent -p TasksMax -p EffectiveTasksMax
cat /proc/$(systemctl show -p MainPID --value [email protected])/limits | grep -i processes

Egy konténeren belül a válaszhoz még két leolvasás kell, mert a infinity belső értéke csak a vendég nézetét írja le. Kérdezze meg a gazdagép tulajdonosától a konténer saját pids-plafonját, és erősítse meg, hogy a belső szolgáltatáskezelő egyáltalán delegálhatja-e ezt a vezérlőt. Egy beágyazott egység nem tarthat olyan költségvetést, amelyet a szülő cgroupja soha nem adott.

Mérje fel a javítás méretét, és bizonyítsa terhelés alatt

A számot a munkaterhelésből válassza, ne a hiba szövegéből. Számolja meg, hány folyamatot indít a démon csatlakozott ügyfelenként vagy segédhívásonként, szorozza meg azzal a párhuzamossággal, amelyet a telepítésnek el kell viselnie, adjon hozzá tartalékot az adminisztratív munkamenetekhez, majd hasonlítsa össze ezt a számot a két tényleges értékkel. Egy helyi drop-in felülírás áttekinthetően tartja a változtatást, és túléli a csomagfrissítéseket, míg egy szállított egységfájl szerkesztése elrejti a módosítást, amíg a következő frissítés le nem cseréli. Írja le a számítást a felülírás mellé, mert a következő embernek, aki emelni vagy csökkenteni fogja, a feltevésekre van szüksége, nem a végső számra.

A költségvetési változtatások végrehajtáskor lépnek életbe, így az újratöltés önmagában nem méretezi át a már futó folyamatokat. Indítsa újra az egységet a normál életciklusán keresztül, fogadja el a munkamenet megszakítását, és olvassa le újra a számlálókat az új példányon.

sudo systemctl daemon-reload
sudo systemctl restart [email protected]
systemctl show [email protected] -p TasksCurrent -p EffectiveTasksMax
sudo journalctl -u [email protected] -b --no-pager | tail -n 20

A javítást egy újraindított egység bizonyítja, amelynek feladatszáma mindkét plafon alatt marad, miközben hordozza a tervezett terhelést, valamint egy journal, amely ugyanabban a szakaszban már nem jelent feladat- vagy elágaztatási kimerülést. Őrizze meg a változtatás mellett a előtte és utána számokat, hogy a következő vizsgálat méréssel kezdődjön, ne ugyanazzal a tanáccsal. Ha a szám továbbra is eléri a plafont, a számítás volt hibás, nem a korlát véletlenül túl kicsi, és ezt a különbséget érdemes tudni a következő újraindítás előtt.