LimitNPROC kundrejt TasksMax: çfarë numëron një njësi OpenVPN

Një nisje e dështuar e OpenVPN shpesh vjen si ankesë për burimet bashkë me një sugjerim me qëllim të mirë për të ngritur një kufi, dhe sugjerimi funksionon vetëm në rreth gjysmën e rasteve. Pas këtyre dështimeve qëndrojnë dy numërues të palidhur. Njëri është një kufi i kernelit mbi numrin e detyrave në pronësi të një ID-je reale përdoruesi, dhe trashëgohet kur ekzekutohet procesi. Tjetri është një buxhet cgroup që menaxheri i shërbimeve zbaton mbi një njësi dhe gjithçka që ajo degëzon. Leximi i vlerës efektive të secilit, për njësinë që ekzekutohet vërtet, kushton më pak se një hamendje.

Dy numërues, dy pyetje

LimitNPROC është RLIMIT_NPROC nën një emër systemd, dhe njësia e kontabilitetit është ID-ja reale e përdoruesit. Çdo proces që zotëron ai përdorues numërohet në të njëjtën shumë, përfshirë punën e nisur nga njësi të tjera, nga një sesion identifikimi ose nga një detyrë planifikuesi. Kufiri, pra, nuk është një tavan për shërbim edhe kur vendoset brenda një njësie shërbimi, dhe një shërbim që degëzon një ndihmës për çdo klient konkurron me gjithçka tjetër që ekzekutohet nën atë llogari. Një detyrë cron e zënë nën të njëjtin përdorues mund ta shtyjë një njësi VPN përtej një vije që ajo vetë nuk e ka kaluar kurrë.

TasksMax ka një pronar tjetër: kontrolluesi pids mbi cgroup-in e njësisë, i cili numëron detyra dhe jo procese. Fijet janë detyra, kështu që një daemon që duket me një fije, por ka një grup punëtorësh, mund të konsumojë një buxhet që në shikim të parë duket shumë më i madh se numri i proceseve të tij. EffectiveTasksMax raporton çfarë lejon vërtet hierarkia e cgroup pasi feta prindërore kanë thënë fjalën e tyre.

Përse përjashtimi root e ndryshon përgjigjen

Kerneli nuk e zbaton RLIMIT_NPROC mbi një proces që mban CAP_SYS_RESOURCE ose CAP_SYS_ADMIN, prandaj një njësi që ekzekutohet si root pa hequr dorë nga privilegjet është në praktikë e pakufizuar nga ajo cilësim. Ky përjashtim i vetëm shpjegon këshillat kontradiktore që njerëzit shkëmbejnë: ngritja e LimitNPROC rregullon një vendosje që hoqi dorë nga privilegjet dhe nuk bën absolutisht asgjë për një që mbeti e privilegjuar. Kontrolloni User= dhe nëse daemoni ndryshon identitet pas nisjes përpara se t'i atribuoni merita ose faj atij cilësimi. Një njësi e privilegjuar që më vonë kalon në një llogari pa privilegje kthehet nën kufi në momentin e kalimit, gjë që e bën edhe kronologjinë e dështimit të denjë për lexim.

Faza e dështimit e ngushton më tej. Një refuzim gjatë përgatitjes së ekzekutimit, një gabim degëzimi i raportuar nga vetë daemoni dhe një krijim detyre i refuzuar brenda një cgroup prodhojnë rreshta journal të ndryshëm, dhe vetëm njërit prej tyre i përgjigjet një buxhet më i madh.

Lexoni vlerat efektive, jo ato të shell-it

ulimit -u i një shell-i interaktiv përshkruan atë shell. Nuk përshkruan çfarë i ka kaluar menaxheri i shërbimeve daemonit, dhe nuk thotë asgjë për kontabilitetin e cgroup. Pyesni në vend të kësaj njësinë, duke përdorur emrin e instancës që ekziston në host dhe jo një shembull nga një udhëzues.

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

Brenda një kontejneri përgjigja kërkon dy lexime të tjera, sepse një vlerë e brendshme e infinity përshkruan vetëm pamjen e mysafirit. Kërkoni nga pronari i host-it tavani i pids i vetë kontejnerit dhe konfirmoni nëse menaxheri i brendshëm i shërbimeve mund ta delegojë fare atë kontrollues. Një njësi e ndërlidhur nuk mund të mbajë një buxhet që cgroup-i i saj prind nuk e ka dhënë kurrë.

Vlerësoni përmasat e rregullimit dhe provojeni nën ngarkesë

Zgjidhni një numër nga ngarkesa e punës dhe jo nga teksti i gabimit. Numëroni proceset që daemoni nis për çdo klient të lidhur ose për çdo thirrje ndihmësi, shumëzoni me konkurrencën që vendosja pritet të mbajë, shtoni një diferencë për sesionet administrative dhe më pas krahasoni atë numër me dy vlerat efektive. Një zëvendësim lokal i tipit drop-in e mban ndryshimin të rishikueshëm dhe i mbijeton përditësimeve të paketave, ndërsa redaktimi i një skedari njësie të dorëzuar e fsheh ndryshimin derisa përditësimi i radhës ta zëvendësojë. Shkruani aritmetikën pranë zëvendësimit, sepse personi i radhës që do ta ngrejë ose ulë ka nevojë për supozimet, jo për numrin përfundimtar.

Ndryshimet e buxhetit zbatohen në ekzekutim, prandaj një rimbushje e vetme nuk i ripërmason proceset që tashmë po ekzekutohen. Rinisni njësinë përmes ciklit të saj normal të jetës, pranoni ndërprerjen e sesionit dhe lexoni numëruesit përsëri në instancën e re.

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

Ajo që provon rregullimin është një njësi e rinisur, numri i detyrave të së cilës qëndron nën të dy tavanet ndërsa mban ngarkesën e synuar, plus një journal që nuk raporton më shterim detyrash ose degëzimesh në të njëjtën fazë. Ruani numrat para dhe pas bashkë me ndryshimin, që hetimi i radhës të nisë nga një matje dhe jo nga i njëjti këshillë. Nëse numri ende arrin tavanin, aritmetika ishte e gabuar dhe jo kufiri rastësisht shumë i vogël, dhe ai ndryshim ia vlen të dihet përpara rinisjes së radhës.