LimitNPROC kontraŭ TasksMax: kion kalkulas unuo de OpenVPN

Malsukcesa starto de OpenVPN ofte alvenas kiel plendo pri rimedoj kune kun bonintenca sugesto plialtigi iun limon, kaj la sugesto funkcias nur proksimume duonon da fojoj. Malantaŭ tiuj fiaskoj staras du senrilataj kalkiloj. Unu estas limo de la kerno pri la nombro de taskoj posedataj de reala uzantidentigilo, kaj ĝi herediĝas kiam la procezo estas ekzekutata. La alia estas buĝeto de cgroup, kiun la servoadministranto aplikas al unuo kaj al ĉio, kion ĝi disbranĉigas. Legi la efektivan valoron de ĉiu el ili, por la unuo kiu efektive funkcias, kostas malpli ol konjekto.

Du kalkiloj, du demandoj

LimitNPROC estas RLIMIT_NPROC sub nomo de systemd, kaj ĝia kalkula unuo estas la reala uzantidentigilo. Ĉiu procezo posedata de tiu uzanto kalkuliĝas kontraŭ la sama sumo, inkluzive de laboro startigita de aliaj unuoj, de ensaluta seanco aŭ de plano-tasko. La limo do ne estas supraĵo por unu servo eĉ kiam ĝi estas agordita ene de serva unuo, kaj servo, kiu disbranĉigas helpanton por ĉiu kliento, konkuras kun ĉio alia funkcianta sub tiu konto. Okupata cron-tasko sub la sama uzanto povas puŝi VPN-unuon trans linion, kiun ĝi mem neniam trapasis.

TasksMax havas alian posedanton: la pids-regilon sur la cgroup de la unuo, kiu kalkulas taskojn anstataŭ procezojn. Fadenoj estas taskoj, do demono aspektanta unufadena sed havanta laborantaron povas konsumi buĝeton, kiu unuavide aspektas multe pli granda ol ĝia nombro da procezoj. EffectiveTasksMax raportas, kion la cgroup-hierarkio efektive permesas post kiam la gepatraj segmentoj diris sian opinion.

Kial la radika escepto ŝanĝas la respondon

La kerno ne aplikas RLIMIT_NPROC al procezo, kiu portas CAP_SYS_RESOURCE aŭ CAP_SYS_ADMIN, kaj tial unuo funkcianta kiel root sen rezigni privilegiojn estas efektive senlima laŭ tiu agordo. Ĉi tiu ununura escepto klarigas la kontraŭdirajn konsilojn, kiujn homoj interŝanĝas: plialtigi LimitNPROC riparas aranĝon, kiu rezignis privilegiojn, kaj faras absolute nenion por unu, kiu restis privilegia. Kontrolu User= kaj ĉu la demono ŝanĝas identecon post starto antaŭ ol atribui al tiu agordo meriton aŭ kulpon. Privilegia unuo, kiu poste transiras al neprivilegia konto, refalas sub la limon en la momento de la transiro, kio igas ankaŭ la tempan linion de la fiasko inda je legado.

La fiaska stadio pli mallarĝigas tion. Rifuzo dum ekzekuta preparo, disbranĉiga eraro raportita de la demono mem kaj rifuzita taskokreado ene de cgroup produktas malsamajn ĵurnalliniojn, kaj nur unu el ili estas respondata de pli granda buĝeto.

Legu la efektivajn valorojn, ne tiujn de la ŝelo

ulimit -u de interaga ŝelo priskribas tiun ŝelon. Ĝi ne priskribas, kion la servoadministranto transdonis al la demono, kaj diras nenion pri cgroup-kalkulado. Demendu la unuon anstataŭe, uzante la instancnomon, kiu ekzistas sur la gastiganto, anstataŭ ekzemplon el gvidlibro.

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

Ene de ujo la respondo bezonas du pliajn legadojn, ĉar interna valoro de infinity priskribas nur la vidon de la gasto. Demandu la gastigantan posedanton pri la propra pids-supraĵo de la ujo, kaj konfirmu, ĉu la interna servoadministranto entute povas delegi tiun regilon. Enigita unuo ne povas teni buĝeton, kiun ĝia gepatra cgroup neniam donis.

Taksumu la riparon kaj pruvu ĝin sub ŝarĝo

Elektu nombron el la laborŝarĝo anstataŭ el la erarteksto. Kalkulu la procezojn, kiujn la demono startigas por ĉiu konektita kliento aŭ por ĉiu helpantovoko, multipliku per la samtempeco, kiun la aranĝo devas porti, aldonu marĝenon por administraj seancoj, kaj poste komparu tiun nombron kun la du efektivaj valoroj. Loka anstataŭigo de tipo drop-in tenas la ŝanĝon revidebla kaj postvivas pakaĵajn ĝisdatigojn, dum redakti liveritan dosieron de unuo kaŝas la modifon ĝis la sekva ĝisdatigo anstataŭigos ĝin. Skribu la aritmetikon apud la anstataŭigo, ĉar la sekva persono, kiu plialtigos aŭ malaltigos ĝin, bezonas la supozojn, ne la finan nombron.

Buĝetaj ŝanĝoj aplikiĝas ĉe ekzekuto, do nura reŝargo ne regrandigas procezojn, kiuj jam funkcias. Restartigu la unuon tra ĝia normala vivociklo, akceptante la seancinterrompon, kaj relegu la kalkilojn sur la nova instanco.

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

Kion pruvas la riparo, estas restartigita unuo, kies taskonombro restas sub ambaŭ supraĵoj dum ĝi portas la celatan ŝarĝon, kune kun ĵurnalo, kiu ne plu raportas taskan aŭ disbranĉigan elĉerpiĝon en la sama stadio. Konservu la nombrojn antaŭ kaj post kune kun la ŝanĝo, por ke la sekva enketo komenciĝu per mezurado anstataŭ per la sama konsilo. Se la nombro ankoraŭ atingas la supraĵon, la aritmetiko estis malĝusta, ne la limo hazarde tro malgranda, kaj tiu diferenco indas esti sciata antaŭ la sekva restarto.