LimitNPROC géint TasksMax: wat eng OpenVPN-Eenheet zielt

E feelgeschloene Start vun OpenVPN kënnt dacks als Ressource-Beschwéier mat engem gutt gemengten Virschlag, eng Limite ze hiewen, a dee Virschlag fonctionnéiert nëmmen an ongeféier der Hallschecht vun de Fäll. Hannert dëse Feeler stinn zwou onofhängeg Ziler. Déi eng ass eng Kernel-Limit fir d'Zuel vun den Aufgaben, déi eng richteg Benotzer-ID besëtzt, an se gëtt beim Ausféiere vum Prozess geierft. Déi aner ass e cgroup-Budget, deen de Servicemanager op eng Eenheet an alles, wat se fächert, uwënnt. Deen effektive Wäert vun allenzwee liesen, fir d'Eenheet déi tatsächlech leeft, kascht manner wéi eng Vermutung.

Zwou Ziler, zwou Froen

LimitNPROC ass RLIMIT_NPROC ënner engem systemd-Numm, an seng Rechnungsunitéit ass déi richteg Benotzer-ID. All Prozess, deen dëse Benotzer besëtzt, zielt an déiselwecht Zomm, dorënner Aarbecht, déi aner Eenheeten, eng Login-Sessioun oder en Task vum Planer ugefaangen huet. D'Limite ass dofir keen Top pro Service, och wann se bannen an enger Service-Eenheet gesat ass, an e Service, deen e Hëllefer fir all Client fächert, konkurréiert mat allem aneren, wat ënner deem Kont leeft. En beschäftegten Cron-Task ënner deem selwechte Benotzer kann eng VPN-Eenheet iwwer eng Linn drécken, déi se eleng ni iwwerschratt huet.

TasksMax huet en aneren Eegentemer: de pids-Controller um cgroup vun der Eenheet, deen Aufgaben zielt an net Prozesser. Fiedem sinn Aufgaben, also kann en Daemon, deen eenfiedereg ausgesäit, awer e Worker-Pool huet, e Budget verbrauchen, deen op den éischte Bléck vill méi grouss wierkt wéi seng Prozesszuel. EffectiveTasksMax mellt, wat d'cgroup-Hierarchie tatsächlech erlaabt, nodeems d'Elteren-Slices hir Soe gesot hunn.

Firwat d'Root-Ausnam d'Äntwert ännert

De Kernel uwënnt RLIMIT_NPROC net op e Prozess, deen CAP_SYS_RESOURCE oder CAP_SYS_ADMIN dréit, dofir ass eng Eenheet, déi als root leeft ouni Privilegien opzeginn, praktesch onbegrenzt duerch déi Astellung. Dës eenzeg Ausnam erkläert déi géigesätzlech Rotschléi, déi d'Leit austauschen: LimitNPROC hiewen reparéiert eng Deployement, déi Privilegien opginn huet, an dinn absolut näischt fir eng, déi privilegiéiert bliwwen ass. Kontrolléiert User= an ob den Daemon no dem Start seng Identitéit ännert, ier Dir där Astellung Verdéngscht oder Schold gitt. Eng privilegiéiert Eenheet, déi méi spéit op e Kont ouni Privilegien iwwergeet, fält am Moment vum Iwwergang erëm ënner d'Limite, wat d'Chronologie vum Feeler och liesenswäert mécht.

D'Feelerstadium enkelt et weider an. Eng Oflehnung wärend der Virbereedung vun der Ausféierung, e Fächerfeeler, deen den Daemon selwer mellt, an eng ofgelehnt Aufgab-Erstellung bannen an engem cgroup produzéieren ënnerschiddlech Journal-Linnen, an nëmmen eng dovun gëtt mat engem gréissere Budget beäntwert.

Liest déi effektiv Wäerter, net déi vun der Shell

ulimit -u vun enger interaktiver Shell beschreift déi Shell. Et beschreift net, wat de Servicemanager dem Daemon iwwerginn huet, an et seet näischt iwwer d'cgroup-Rechnung. Frot amplaz d'Eenheet, mat dem Instanznumm, deen um Host existéiert, an net engem Beispill aus engem Guide.

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

Bannen an engem Container brauch d'Äntwert nach zwou Liesungen, well en bannenzege Wäert vun infinity nëmmen d'Siicht vum Gast beschreift. Frot den Host-Eegentemer no dem eegene pids-Top vum Container, a bestätegt, ob de bannenzege Servicemanager deen Controller iwwerhaapt delegéiere kann. Eng nestéiert Eenheet kann kee Budget halen, deen hirem Elteren-cgroup ni ginn huet.

Moost d'Gréisst vun der Korrektur a bewise se ënner Laascht

Wielt eng Zuel aus der Aarbechtslaascht an net aus dem Feelertext. Zielt d'Prozesser, déi den Daemon pro verbonnenem Client oder pro Hëllefer-Opruff startet, multiplizéiert mat der Paralleltéit, déi d'Deployement droen soll, füügt eng Margin fir administrativ Sessiounen derbäi, a vergläicht dann déi Zuel mat den zwou effektiven Wäerter. Eng lokal Drop-in-Iwwerschreifung hält d'Ännerung iwwerpréifbar an iwwerlieft Pak-Update, wärend d'Ännere vun enger geliwwerter Eenheetsdatei d'Ännerung verstoppt, bis den nächsten Update se ersetzt. Schreift d'Arithmetik nieft d'Iwwerschreifung, well déi nächst Persoun, déi se hieft oder senkt, d'Annahmen brauch an net déi lescht Zuel.

Budget-Ännerunge ginn bei der Ausféierung ugewannt, also ännert en Nei-Lueden eleng net d'Gréisst vu Prozesser, déi scho lafen. Start d'Eenheet iwwer hire normale Liewenszyklus nei, akzeptéier d'Ënnerbriechung vun der Sessioun, a liest d'Ziler op der neier Instanz nach eng Kéier.

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

Wat d'Reparatur beweist, ass eng nei gestart Eenheet, där hir Aufgabzuel ënner béiden Tope bleift, wärend se déi virgesinn Laascht dréit, plus e Journal, deen op deem selwechte Stadium keng Aufgab- oder Fächererschöpfung méi mellt. Halt d'Zuelen virdrun an duerno bei der Ännerung, sou datt déi nächst Enquête mat enger Mooss ufänkt an net mat deem selwechte Rot. Wann d'Zuel nach ëmmer den Top erreecht, war d'Arithmetik falsch an net d'Limite zoufälleg ze kleng, an deen Ënnerscheed ass wäert ze wëssen virum nächsten Neistart.