LimitNPROC verzus TasksMax: čo počíta jednotka OpenVPN

Neúspešné spustenie OpenVPN často prichádza ako sťažnosť na prostriedky spolu s dobre mieneným návrhom zvýšiť nejaký limit, a tento návrh zaberie len asi v polovici prípadov. Za týmito zlyhaniami stoja dva nesúvisiace počítadlá. Jedno je limit jadra na počet úloh vlastnených skutočným používateľským ID a dedí sa pri spustení procesu. Druhé je rozpočet cgroup, ktorý správca služieb uplatňuje na jednotku a na všetko, čo z nej vetví. Prečítať efektívnu hodnotu každého z nich pre jednotku, ktorá skutočne beží, stojí menej než odhad.

Dve počítadlá, dve otázky

LimitNPROC je RLIMIT_NPROC pod menom systemd a jeho účtovnou jednotkou je skutočné používateľské ID. Každý proces, ktorý tento používateľ vlastní, sa počíta do rovnakého súčtu, vrátane práce spustenej inými jednotkami, prihlasovacou reláciou alebo úlohou plánovača. Limit teda nie je stropom pre jednotlivú službu, aj keď je nastavený vnútri jednotky služby, a služba, ktorá pre každého klienta vetví pomocníka, súťaží so všetkým ostatným, čo pod týmto účtom beží. Zaneprázdnená úloha cron pod tým istým používateľom môže jednotku VPN vytlačiť za hranicu, ktorú sama nikdy neprekročila.

TasksMax má iného vlastníka: radič pids na cgroup jednotky, ktorý počíta úlohy, nie procesy. Vlákna sú úlohy, takže démon, ktorý vyzerá ako jednovláknový, ale má fond pracovníkov, môže spotrebovať rozpočet, ktorý na prvý pohľad vyzerá oveľa väčší než počet jeho procesov. EffectiveTasksMax hlási, čo hierarchia cgroup skutočne dovoľuje po tom, ako rodičovské rezy povedali svoje.

Prečo výnimka pre root mení odpoveď

Jadro neuplatňuje RLIMIT_NPROC na proces, ktorý nesie CAP_SYS_RESOURCE alebo CAP_SYS_ADMIN, a preto jednotka bežiaca ako root bez vzdania sa oprávnení nie je týmto nastavením prakticky nijako obmedzená. Táto jediná výnimka vysvetľuje protichodné rady, ktoré si ľudia vymieňajú: zvýšenie LimitNPROC opraví nasadenie, ktoré sa oprávnení vzdalo, a neurobí vôbec nič pre to, ktoré zostalo privilegované. Skontrolujte User= a to, či démon po spustení mení identitu, než tomuto nastaveniu pripíšete zásluhu alebo vinu. Privilegovaná jednotka, ktorá neskôr prejde na neprivilegovaný účet, spadne pod limit v okamihu prechodu, čo robí časovú os zlyhania tiež hodnou prečítania.

Fáza zlyhania to ďalej zužuje. Odmietnutie počas prípravy spustenia, chyba vetvenia hlásená samotným démonom a odmietnuté vytvorenie úlohy vnútri cgroup dávajú rôzne riadky v journali a len na jeden z nich odpovedá väčší rozpočet.

Čítajte efektívne hodnoty, nie tie zo shellu

ulimit -u interaktívneho shellu opisuje tento shell. Nepopisuje, čo správca služieb odovzdal démonovi, a nič nehovorí o účtovaní cgroup. Pýtajte sa namiesto toho jednotky, s použitím názvu inštancie, ktorý na hostiteľovi existuje, a nie príkladu z príručky.

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

Vnútri kontajnera potrebuje odpoveď ďalšie dve čítania, pretože vnútorná hodnota infinity opisuje len pohľad hosťa. Opýtajte sa vlastníka hostiteľa na vlastný strop pids kontajnera a overte, či vnútorný správca služieb môže tento radič vôbec delegovať. Vnorená jednotka nemôže držať rozpočet, ktorý jej rodičovská cgroup nikdy nepridelila.

Nadimenzujte opravu a preukážte ju pod záťažou

Číslo vyberte zo záťaže, nie z textu chyby. Spočítajte procesy, ktoré démon spúšťa na každého pripojeného klienta alebo na každé vyvolanie pomocníka, vynásobte súbežnosťou, ktorú má nasadenie uniesť, pridajte rezervu na administratívne relácie a potom toto číslo porovnajte s dvoma efektívnymi hodnotami. Miestne prepísanie typu drop-in udržiava zmenu kontrolovateľnou a prežije aktualizácie balíkov, zatiaľ čo úprava dodaného súboru jednotky skrýva zmenu, kým ju nenahradí ďalšia aktualizácia. Zapíšte aritmetiku vedľa prepísania, pretože ďalší človek, ktorý ho bude zvyšovať alebo znižovať, potrebuje predpoklady, nie konečné číslo.

Zmeny rozpočtu sa uplatňujú pri spustení, takže samotné opätovné načítanie nemení veľkosť už bežiacich procesov. Reštartujte jednotku jej obvyklým životným cyklom, prijmite prerušenie relácie a prečítajte počítadlá znova na novej inštancii.

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

Opravu dokazuje reštartovaná jednotka, ktorej počet úloh zostáva pod oboma stropmi, pričom nesie zamýšľanú záťaž, plus journal, ktorý v tej istej fáze už nehlási vyčerpanie úloh ani vetvení. Uložte čísla pred a po spolu so zmenou, aby ďalšie vyšetrovanie začalo meraním a nie tou istou radou. Ak počet stále dosahuje strop, aritmetika bola nesprávna a nie limit náhodou príliš malý, a ten rozdiel stojí za to poznať pred ďalším reštartom.