LimitNPROC laban sa TasksMax: ano ang binibilang ng isang unit ng OpenVPN

Ang bigong pag-start ng OpenVPN ay madalas dumarating bilang reklamo tungkol sa resources kasama ng mabuting intensyong suhestiyon na itaas ang isang limit, at gumagana lang ang suhestiyon sa mga kalahati ng pagkakataon. Sa likod ng mga pagkabigo sila ay may dalawang counter na walang kaugnayan. Ang isa ay limit ng kernel sa bilang ng mga task na pag-aari ng isang tunay na user ID, at namamana ito kapag pinapatakbo ang proseso. Ang isa pa ay badyet ng cgroup na inilalapat ng service manager sa isang unit at sa lahat ng pinu-fork nito. Ang pagbasa ng epektibong halaga ng bawat isa, para sa unit na talagang tumatakbo, ay mas mura kaysa sa isang hula.

Dalawang counter, dalawang tanong

LimitNPROC ay RLIMIT_NPROC sa ilalim ng isang pangalang systemd, at ang unit ng accounting nito ay ang tunay na user ID. Bawat prosesong pag-aari ng user na iyon ay binibilang sa parehong kabuuan, kasama ang trabahong sinimulan ng ibang unit, ng isang login session o ng isang task ng scheduler. Kaya ang limit na ito ay hindi kisame ng bawat serbisyo kahit pa ito ay itinakda sa loob ng isang service unit, at ang serbisyong nag-fork ng helper para sa bawat kliyente ay nakikipagkumpitensya sa lahat ng iba pang tumatakbo sa ilalim ng account na iyon. Ang abalang cron task sa ilalim ng parehong user ay maaaring magtulak ng VPN unit lampas sa linyang hindi nito kailanman tinawid nang mag-isa.

TasksMax ay may ibang may-ari: ang pids controller sa cgroup ng unit, na nagbibilang ng task sa halip na proseso. Ang mga thread ay task, kaya ang isang daemon na mukhang isang thread ngunit may pool ng manggagawa ay maaaring kumonsumo ng badyet na sa unang tingin ay mukhang mas malaki kaysa sa bilang ng mga proseso nito. Iniulat ng EffectiveTasksMax kung ano talaga ang pinapayagan ng hierarchy ng cgroup matapos magsalita ang mga parent slice.

Bakit binabago ng eksepsiyon sa root ang sagot

Hindi inilalapat ng kernel ang RLIMIT_NPROC sa isang prosesong may CAP_SYS_RESOURCE o CAP_SYS_ADMIN, kaya ang isang unit na tumatakbo bilang root nang hindi bumababa sa mga pribilehiyo ay talagang walang limitasyon sa setting na iyon. Ang nag-iisang eksepsiyong ito ang nagpapaliwanag sa magkakasalungat na payong ipinagpapalitan ng mga tao: ang pagtataas ng LimitNPROC ay nag-aayos ng deployment na bumaba sa mga pribilehiyo at walang ginagawa sa isang nanatiling may pribilehiyo. Tingnan ang User= at kung binabago ng daemon ang pagkakakilanlan pagkatapos ng start bago magbigay ng kredito o sisi sa setting na iyon. Ang isang unit na may pribilehiyo na kalaunan ay lumipat sa account na walang pribilehiyo ay bumabalik sa ilalim ng limit sa sandali ng paglipat, kaya ang timeline ng pagkabigo ay sulit ding basahin.

Pinaliit pa ito ng yugto ng pagkabigo. Ang pagtanggi habang naghahanda ng pagpapatupad, isang error sa fork na iniulat ng daemon mismo at isang tinanggihang paglikha ng task sa loob ng cgroup ay gumagawa ng iba't ibang linya ng journal, at isa lamang sa kanila ang sinasagot ng mas malaking badyet.

Basahin ang mga epektibong halaga, hindi ang sa shell

Ang ulimit -u ng isang interactive na shell ay naglalarawan sa shell na iyon. Hindi nito inilalarawan kung ano ang ipinasa ng service manager sa daemon, at wala itong sinasabi tungkol sa accounting ng cgroup. Tanungin ang unit sa halip, gamit ang pangalan ng instance na umiiral sa host at hindi isang halimbawa mula sa gabay.

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

Sa loob ng isang container kailangan ng sagot ang dalawa pang pagbasa, dahil ang panloob na halaga ng infinity ay naglalarawan lamang ng pananaw ng bisita. Tanungin ang may-ari ng host para sa sariling kisame ng pids ng container, at kumpirmahin kung ang panloob na service manager ay makakapag-delegate sa controller na iyon. Ang nakapaloob na unit ay hindi makakahawak ng badyet na hindi ibinigay ng parent cgroup nito.

Sukatin ang lawak ng pagwawasto at patunayan ito sa ilalim ng karga

Pumili ng numero mula sa karga ng trabaho at hindi mula sa teksto ng error. Bilangin ang mga prosesong sinisimulan ng daemon bawat konektadong kliyente o bawat tawag ng helper, i-multiply sa concurrency na inaasahang kakayanin ng deployment, magdagdag ng margin para sa mga administratibong session, at pagkatapos ay ihambing ang numerong iyon sa dalawang epektibong halaga. Ang lokal na drop-in override ay nagpapanatili sa pagbabagong masusuri at nakakaligtas sa mga pag-upgrade ng package, samantalang itinatago ng pag-edit ng isang shipped na unit file ang pagbabago hanggang palitan ito ng susunod na update. Isulat ang aritmetika sa tabi ng override, dahil ang susunod na taong magtataas o magbababa nito ay kailangan ang mga palagay, hindi ang huling numero.

Inilalapat ang mga pagbabago sa badyet sa pagpapatupad, kaya ang muling pag-load lamang ay hindi nagbabago ng laki ng mga prosesong tumatakbo na. I-restart ang unit sa normal na lifecycle nito, tanggapin ang pagkaantala ng session, at basahin muli ang mga counter sa bagong instance.

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

Ang nagpapatunay sa pagwawasto ay isang na-restart na unit na ang bilang ng task ay nananatiling mas mababa sa dalawang kisame habang dinadala ang nilalayong karga, kasama ang journal na hindi na nag-uulat ng pagkaubos ng task o fork sa parehong yugto. Itago ang mga numero bago at pagkatapos kasama ng pagbabago, upang ang susunod na imbestigasyon ay magsimula sa isang pagsukat at hindi sa parehong payo. Kung ang bilang ay umaabot pa rin sa kisame, ang aritmetika ang mali at hindi ang limit na nagkataong masyadong maliit, at ang pagkakaibang iyon ay sulit malaman bago ang susunod na restart.