LimitNPROC teenoor TasksMax: wat 'n OpenVPN-eenheid tel

Wanneer 'n OpenVPN-begin misluk, kom dit dikwels voor as 'n klag oor hulpbronne plus 'n goedbedoelde voorstel om 'n limiet te verhoog, en dié voorstel werk net omtrent die helfte van die tyd. Twee onverwante tellers sit agter dié mislukkings. Een is 'n kerneellimiet op die aantal take wat deur 'n werklike gebruiker-ID besit word, en dit word geërf wanneer die proses uitgevoer word. Die ander is 'n cgroup-begroting wat die diensbestuurder op 'n eenheid en alles wat dit vurk, toepas. Om die werklike waarde van elkeen te lees, vir die eenheid wat werklik loop, kos minder as 'n raaiskoot.

Twee tellers, twee vrae

LimitNPROC is RLIMIT_NPROC onder 'n systemd-naam, en sy rekeneenheid is die werklike gebruiker-ID. Elke proses wat dié gebruiker besit, tel teen dieselfde totaal, insluitend werk wat deur ander eenhede, deur 'n aanmeldsessie of deur 'n skeduleerder-taak begin is. Die limiet is dus nie 'n per-diens-plafon nie, selfs wanneer dit binne 'n dienseenheid gestel word, en 'n diens wat 'n helper vir elke kliënt vurk, ding mee met alles anders wat onder daardie rekening loop. 'n Besige cron-taak onder dieselfde gebruiker kan 'n VPN-eenheid oor 'n lyn stoot wat dit op sy eie nooit sou oorskry nie.

TasksMax het 'n ander eienaar: die pids-beheerder op die eenheid se cgroup, wat take eerder as prosesse tel. Draadjies is take, so 'n daemon wat na een draad lyk maar 'n werkerspoel het, kan 'n begroting verbruik wat met die eerste oogopslag baie groter lyk as sy prosesgetal. EffectiveTasksMax rapporteer wat die cgroup-hiërargie werklik toelaat nadat ouer-skywe hul sê gehad het.

Waarom die root-uitsondering die antwoord verander

Die kern pas RLIMIT_NPROC nie toe op 'n proses wat CAP_SYS_RESOURCE of CAP_SYS_ADMIN dra nie, en daarom is 'n eenheid wat as root loop sonder om voorregte te laat vaar, in effek onbeperk deur daardie instelling. Hierdie enkele uitsondering verduidelik die teenstrydige raad wat mense uitruil: om LimitNPROC te verhoog herstel 'n ontplooiing wat voorregte laat vaar het en doen heeltemal niks vir een wat bevoorreg gebly het nie. Kyk na User= en of die daemon ná die opstart van identiteit verander voordat jy daardie instelling krediet of die skuld gee. 'n Bevoorregte eenheid wat later na 'n onbevoorregte rekening oorskakel, val op die oomblik van die skakel terug onder die limiet, wat die tydlyn van die mislukking ook die moeite werd maak om te lees.

Die mislukkingstadium vernou dit verder. 'n Weiering tydens die opstel van uitvoering, 'n vurk-fout wat die daemon self rapporteer en 'n verwerpte taak-skepping binne 'n cgroup lewer verskillende joernaalreëls, en net een van hulle word deur 'n groter begroting beantwoord.

Lees die werklike waardes, nie dié van die skulp nie

'n Interaktiewe skulp se ulimit -u beskryf daardie skulp. Dit beskryf nie wat die diensbestuurder aan die daemon gegee het nie, en dit sê niks oor cgroup-rekeningkunde nie. Vra eerder die eenheid uit, met die instansienaam wat op die gasheer bestaan eerder as 'n voorbeeld uit 'n gids.

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

Binne 'n houer het die antwoord nog twee lesings nodig, want 'n innerlike waarde van infinity beskryf net die gas se siening. Vra die gasheer-eienaar vir die houer se eie pids-plafon, en bevestig of die innerlike diensbestuurder daardie beheerder hoegenaamd kan delegeer. 'n Geneste eenheid kan nie 'n begroting hou wat sy ouer-cgroup nooit toegestaan het nie.

Bepaal die omvang van die regstelling en bewys dit onder las

Kies 'n getal uit die werklas eerder as uit die foutteks. Tel die prosesse wat die daemon per gekoppelde kliënt of per helper-aanroep begin, vermenigvuldig met die gelyktydigheid wat die ontplooiing verwag word om te dra, voeg 'n marge vir administratiewe sessies by, en vergelyk dan daardie syfer met die twee werklike waardes. 'n Plaaslike drop-in-oorheersing hou die verandering hersienbaar en oorleef pakketopgraderings, terwyl die wysiging van 'n verskepte eenheidslêer die verandering verberg totdat die volgende opdatering dit vervang. Skryf die rekenkunde langs die oorheersing neer, want die volgende persoon wat dit verhoog of verlaag, het die aannames nodig eerder as die finale getal.

Begrotingsveranderinge word by uitvoering toegepas, so 'n herlaai alleen verander nie die grootte van prosesse wat reeds loop nie. Herbegin die eenheid deur sy normale lewensiklus, aanvaar die sessie-onderbreking, en lees die tellers weer op die nuwe instansie.

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 die herstelling bewys, is 'n herbegin eenheid wie se taakgetal onder beide plafonne sit terwyl dit die beoogde las dra, plus 'n joernaal wat nie meer taak- of vurk-uitputting op dieselfde stadium rapporteer nie. Hou die voor-en-na-syfers by die verandering sodat die volgende ondersoek by 'n meting begin eerder as by dieselfde raad. As die getal steeds die plafon bereik, was die rekenkunde verkeerd eerder as dat die limiet toevallig te klein was, en daardie verskil is die moeite werd om te ken voor die volgende herbegin.