LimitNPROC tsjin TasksMax: wat in OpenVPN-ienheid telt

In mislearre OpenVPN-start komt faak as in klacht oer boarnen tegearre mei in goedbedoelde suggestje om in limyt te ferheegjen, en dy suggestje wurket mar sawat de helte fan de kearen. Efter dy mislearrings steane twa losse tellers. Ien is in kernel-limyt op it oantal taken dat in echte brûkers-ID hat, en dat wurdt erfd as it proses útfierd wurdt. De oare is in cgroup-budget dat de tsjinstbehearder tapast op in ienheid en alles wat dy fertakket. It lêzen fan de effektive wearde fan elk, foar de ienheid dy't echt rint, kostet minder as in gissing.

Twa tellers, twa fragen

LimitNPROC is RLIMIT_NPROC ûnder in systemd-namme, en syn boekhâlding-ienheid is de echte brûkers-ID. Elk proses dat dy brûker hat, telt mei yn deselde som, ynklusyf wurk dat troch oare ienheden, troch in oanmeldsesje of troch in plennertaak begûn is. It limyt is dêrom gjin plafond per tsjinst, sels as it binnen in tsjinstienheid ynsteld wurdt, en in tsjinst dy't in helper fertakket foar elke klant konkurrearret mei al it oare dat ûnder dat akkount rint. In drokke cron-taak ûnder deselde brûker kin in VPN-ienheid oer in line triuwe dy't dy op himsels nea oerstiek.

TasksMax hat in oare eigner: de pids-kontrôleur op de cgroup fan de ienheid, dy't taken telt yn stee fan prosessen. Trieden binne taken, dus in daemon dy't ientriedich liket mar in worker-pool hat, kin in budget ferbrûke dat op it earste each folle grutter liket as syn oantal prosessen. EffectiveTasksMax meldt wat de cgroup-hierargy eins tastean nei't de âlder-slices har sizzen dien hawwe.

Wêrom't de root-útsûndering it antwurd feroaret

De kernel past RLIMIT_NPROC net ta op in proses dat CAP_SYS_RESOURCE of CAP_SYS_ADMIN draacht, en dêrom is in ienheid dy't as root rint sûnder privileezjes ôf te stean, praktysk ûnbeheind troch dy ynstelling. Dizze iene útsûndering ferklearret it tsjinstridige advys dat minsken útwikselje: LimitNPROC ferheegje reparearret in ynset dy't privileezjes ôfstie en docht hielendal neat foar ien dy't privilezje bleau. Kontrolearje User= en oft de daemon nei it starten fan identiteit feroaret foardat jo dy ynstelling kredyt of skuld jouwe. In privilezjele ienheid dy't letter oerstapt nei in net-privilezjele akkount, falt op it momint fan de oerstap wer ûnder it limyt, wat de tiidline fan 'e mislearring ek lêsber makket.

De mislearringsfase beheint it fierder. In wegering by de tarieding fan 'e útfiering, in fertakkingsflater dy't de daemon sels meldt en in wegere taak-oanmeitsjen binnen in cgroup jouwe ferskate journal-regels, en mar ien fan har wurdt beantwurde troch in grutter budget.

Lês de effektive wearden, net dy fan 'e shell

ulimit -u fan in ynteraktive shell beskriuwt dy shell. It beskriuwt net wat de tsjinstbehearder oan 'e daemon jûn hat, en it seit neat oer cgroup-boekhâlding. Freegje yn stee dêrfan de ienheid op, mei de eksimplaarnamme dy't op 'e host bestiet en net in foarbyld út in hânlieding.

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

Binnen in kontener hat it antwurd noch twa lêzingen nedich, want in ynterne wearde fan infinity beskriuwt allinnich de werjefte fan 'e gast. Freegje de host-eigner om it eigen pids-plafond fan 'e kontener, en befêstigje oft de ynterne tsjinstbehearder dy kontrôleur hielendal delegrearje kin. In nêstele ienheid kin gjin budget hâlde dat syn âlder-cgroup nea joech.

Mjit de omfang fan 'e repaaraasje en bewiis it ûnder lading

Kies in getal út 'e wurklading, net út 'e flatertekst. Tel de prosessen dy't de daemon start per ferbûne klant of per helper-oprop, fermannichfâldigje mei de paralleliteit dy't de ynset ferwachte wurdt te dragen, foegje in marzje ta foar beheardersesjes, en fergelykje dat getal dan mei de twa effektive wearden. In lokale drop-in-oerskriuwing hâldt de feroaring kontrolearber en oerlibbet pakketfernijings, wylst it bewurkjen fan in levere ienheidsbestân ferberget de feroaring oant de folgjende fernijing it ferfangt. Skriuw de rekkenjen njonken de oerskriuwing, want de folgjende persoan dy't it ferheget of ferleget hat de oannames nedich, net it einlike getal.

Budgetferoarings wurde by útfiering tapast, dus in opnij laden allinnich feroaret de grutte fan prosessen dy't al rinne net. Start de ienheid opnij troch har normale libbenssyklus, akseptearje de sesje-ûnderbrekking, en lês de tellers opnij op it nije eksimplaar.

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 de repaaraasje bewiist, is in opnij starte ienheid wêrfan't it taakgetal ûnder beide plafonds bliuwt wylst it de bedoelde lading draacht, plus in journal dy't op itselde stadium gjin taak- of fertakkingsútputting mear meldt. Bewarje de getallen foar en nei by de feroaring, sadat it folgjende ûndersyk fan in mjitting begjint en net fan itselde advys. As it getal noch it plafond berikt, wie de rekkenjen ferkeard en net it limyt tafallich te lyts, en dat ferskil is de muoite wurdich om te witten foar de folgjende werstart.