LimitNPROC gegn TasksMax: hvað OpenVPN-eining telur

Mistök við ræsingu OpenVPN koma oft sem kvörtun um auðlindir ásamt vel meintri tillögu um að hækka einhver mörk, og tillagan virkar aðeins í um helmingi tilvika. Að baki þessum mistökum standa tveir ótengdir teljarar. Annar er mörk kjarnans á fjölda verka sem raunverulegt notandaaðkenni á, og þau erfast þegar ferlið er keyrt. Hinn er cgroup-fjárveiting sem þjónustustjórinn beitir á einingu og allt sem hún greinir frá sér. Að lesa raunverulegt gildi hvors um sig, fyrir eininguna sem raunverulega keyrir, kostar minna en ágiskun.

Tveir teljarar, tvær spurningar

LimitNPROC er RLIMIT_NPROC undir systemd-nafni, og reikningseining þess er raunverulega notandaaðkennið. Hvert ferli sem sá notandi á telst í sömu heild, þar á meðal vinna sem aðrar einingar, innskráningarlota eða verk áætlunarbúnaðar hófu. Mörkin eru því ekki þak á hverja þjónustu jafnvel þegar þau eru sett inni í þjónustueiningu, og þjónusta sem greinir hjálpara frá sér fyrir hvern skjólstæðing keppir við allt annað sem keyrir undir þeim reikningi. Annasamt cron-verk undir sama notanda getur ýtt VPN-einingu yfir línu sem hún fór sjálf aldrei yfir.

TasksMax hefur annan eiganda: pids-stýringuna á cgroup einingarinnar, sem telur verk í stað ferla. Þræðir eru verk, svo dæmon sem virðist einþráður en hefur vinnuhóp getur eytt fjárveitingu sem virðist við fyrstu sýn miklu meiri en ferlafjöldi hans. EffectiveTasksMax greinir frá því sem cgroup-stigveldið leyfir í raun þegar yfirskífurnar hafa sagt sitt.

Hvers vegna root-undantekningin breytir svarinu

Kjarninn beitir ekki RLIMIT_NPROC á ferli sem ber CAP_SYS_RESOURCE eða CAP_SYS_ADMIN, og þess vegna er eining sem keyrir sem root án þess að afsala sér forræðum í raun ótakmörkuð af þeirri stillingu. Þessi eina undantekning skýrir misvísandi ráðin sem fólk skiptist á: að hækka LimitNPROC lagar uppsetningu sem afsalaði sér forræðum og gerir alls ekkert fyrir þá sem hélt þeim. Athugaðu User= og hvort dæmoninn skiptir um auðkenni eftir ræsingu áður en þú gefur þeirri stillingu heiður eða sökina. Eining með forræðum sem síðar fer yfir á reikning án forræða fellur aftur undir mörkin á þeirri stundu, sem gerir tímalínu mistakanna líka þess virði að lesa.

Stig mistakanna þrengir þetta frekar. Synjun við undirbúning keyrslu, greiningarvilla sem dæmoninn tilkynnir sjálfur og synjuð verkasköpun innan cgroup framleiða mismunandi journal-línur, og aðeins einni þeirra er svarað með stærri fjárveitingu.

Lestu raunverulegu gildin, ekki þau sem skeljarinn sýnir

ulimit -u gagnvirkrar skeljar lýsir þeirri skel. Það lýsir ekki því sem þjónustustjórinn gaf dæmoninum og segir ekkert um cgroup-reikningsskil. Spurðu einingarinnar í staðinn, með því að nota tilviksnafnið sem er til á hýslinum en ekki dæmi úr leiðarvísi.

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

Inni í gám þarf svarið tvær lestrar í viðbót, því innra gildi infinity lýsir aðeins sýn gestsins. Biddu eiganda hýsilsins um eigin pids-þak gámsins og staðfestu hvort innri þjónustustjórinn geti yfirleitt framselt þá stýringu. Hreiðruð eining getur ekki haldið fjárveitingu sem foreldris-cgroup hennar veitti aldrei.

Metið umfang lagfæringarinnar og sannið hana undir álagi

Veldu tölu úr vinnuálaginu en ekki úr villutextanum. Teldu ferlin sem dæmoninn ræsir fyrir hvern tengdan skjólstæðing eða hverja hjálparaköllun, margfaldaðu með samhliða getu sem uppsetningin á að þola, bættu við skekkjumörkum fyrir stjórnunarlotur og berðu þá tölu saman við tvö raunveruleg gildi. Staðbundið drop-in-yfirskrift heldur breytingunni yfirfaranlegri og lifir af pakkauppfærslur, en að breyta afhentri einingarskrá felur breytinguna þar til næsta uppfærsla kemur í staðinn. Skrifaðu reikninginn við hlið yfirskriftarinnar, því næsta manneskja sem hækkar eða lækkar hana þarf forsendurnar, ekki lokatöluna.

Fjárveitingabreytingar eru beittar við keyrslu, svo endurhleðsla ein og sér breytir ekki stærð ferla sem þegar eru í gangi. Endurræstu eininguna í gegnum venjulegan lífsferil hennar, samþykktu truflun lotunnar og lestu teljarana aftur á nýja tilvikinu.

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ð sem sannar lagfæringuna er endurræst eining þar sem verkafjöldinn liggur undir báðum þökum meðan hún ber fyrirhugað álag, ásamt journal sem tilkynnir ekki lengur um verk- eða greiningarþrot á sama stigi. Geymdu tölurnar fyrir og eftir með breytingunni svo næsta rannsókn byrji á mælingu en ekki sömu ráðleggingu. Ef fjöldinn nær enn þakinu var reikningurinn rangur en ekki mörkin óvart of lítil, og þann mun er vert að þekkja fyrir næstu endurræsingu.