LimitNPROC د TasksMax په وړاندې: یوه OpenVPN واحد څه شمېري

د OpenVPN ناکام پیل ډېری وخت د سرچینو د شکایت او د یو حد د پورته کولو د ښه نیت وړاندیز سره یوځای راځي، او هغه وړاندیز یوازې په نږدې نیمو پېښو کې کار کوي۔ د دغو ناکامیو تر شا دوه غیرمرتبط شمېرونکي دي۔ یو د کرنل هغه حد دی چې په یوه ریښتیني کارن ID پورې اړوند د دندو شمېر ټاکي، او کله چې پروسه چلېږي میراثي کېږي۔ بل د cgroup بودیجه ده چې د خدمت مدیر یې پر یوه واحد او هر هغه څه پلي کوي چې هغه یې څانګې کوي۔ د هر یوه اغېزمن ارزښت لوستل، د هغه واحد لپاره چې واقعاً چلېږي، له اټکل څخه لږ لګښت لري۔

دوه شمېرونکي، دوه پوښتنې

LimitNPROC د systemd تر نوم لاندې RLIMIT_NPROC دی، او د حساب واحد یې ریښتینی کارن ID دی۔ هره پروسه چې هغه کارن یې مالک وي په هماغه ټولټال کې شمېرل کېږي، په شمول هغه کار چې نورو واحدونو، د ننوتلو غونډې یا د مهالوېش دندې پیل کړی وي۔ نو دا حد د هر خدمت لپاره جلا سرحد نه دی، حتی کله چې د خدمت د واحد دننه ټاکل شوی وي، او هغه خدمت چې د هر پیرودونکي لپاره مرستندوی څانګې کوي له هغه هر څه سره سیالي کوي چې د هماغه حساب لاندې چلېږي۔ د هماغه کارن لاندې بوخت cron کار کولای شي د VPN واحد له هغې کرښې هاخوا کړي چې هغه پخپله هېڅکله نه وه اوړېدلې۔

TasksMax بل مالک لري: د واحد د cgroup پر سر pids کنټرولر، چې د پروسو پرځای دندې شمېري۔ تارونه دندې دي، نو یو ډیمون چې یوتاره ښکاري خو د کارګرو حوض لري کولای شي هغه بودیجه مصرف کړي چې په لومړي نظر کې د هغه د پروسو له شمېر څخه ډېره لویه ښکاري۔ EffectiveTasksMax راپور ورکوي چې د مورني سلیسونو له خبرې وروسته د cgroup لړۍ واقعاً څه اجازه ورکوي۔

ولې د root استثنا ځواب بدلوي

کرنل RLIMIT_NPROC پر هغه پروسه نه پلي کوي چې CAP_SYS_RESOURCE یا CAP_SYS_ADMIN لري، نو ځکه هغه واحد چې د امتیازاتو له پرېښودو پرته د root په توګه چلېږي د دې تنظیم له مخې عملاً بېحد دی۔ همدا یوازینۍ استثنا هغه متضادې مشورې تشریح کوي چې خلک یې تبادله کوي: د LimitNPROC پورته کول هغه ځایپرځای کول سمول چې امتیازات یې پرېښي وو او د هغه لپاره چې امتیازي پاتې شو هېڅ هم نه کوي۔ مخکې لدې چې دې تنظیم ته اعتبار یا ګناه ونسپئ، User= او دا چې ډیمون له پیل وروسته خپل هویت بدلوي که نه، وګورئ۔ امتیازي واحد چې وروسته بېامتیازه حساب ته ځي، د بدلون په شېبه کې بیا د حد لاندې راځي، چې د ناکامۍ مهالکرښه هم د لوستلو وړ ګرځوي۔

د ناکامۍ پړاو دا لا تنګوي۔ د اجرا د چمتووالي پر مهال رد، هغه څانګې تېروتنه چې ډیمون پخپله راپور ورکوي، او د cgroup دننه رد شوې دنده جوړونه بېلابېلې journal کرښې ورکوي، او یوازې یوې ته یې لویه بودیجه ځواب وایي۔

اغېزمن ارزښتونه ولولئ، نه د شیل هغه

د یوې متقابلې شیل ulimit -u هماغه شیل تشریح کوي۔ دوی نه تشریح کوي چې د خدمت مدیر ډیمون ته څه ورکړي، او د cgroup د حساب په اړه هېڅ نه وایي۔ پرځای یې له واحد څخه وپوښتئ، د لارښود له بېلګې پرځای په هوسټ کې موجود د نمونې نوم وکاروئ۔

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

د کانټینر دننه ځواب لا دوو لوستلو ته اړتیا لري، ځکه چې د infinity داخلي ارزښت یوازې د مېلمه لید تشریح کوي۔ د هوسټ له مالک څخه د کانټینر خپله pids سقف وپوښتئ، او تایید کړئ چې ایا داخلي خدمت مدیر هغه کنټرولر هم سپارلی شي۔ ننوتلی واحد نه شي کولای هغه بودیجه وساتي چې مورني cgroup هېڅکله نه ده ورکړې۔

د سمون اندازه وټاکئ او د بار لاندې یې ثابت کړئ

شمېره د تېروتنې له متن څخه نه، بلکې د کار له بار څخه وټاکئ۔ هغه پروسې وشمېرئ چې ډیمون د هر نښلول شوي پیرودونکي یا هر مرستندوی غوښتنې لپاره پیلوي، په هغه هممهالنې سره یې ضرب کړئ چې ځایپرځای کول یې باید وزغمي، د اداري غونډو لپاره لږ حاشیه ورزیات کړئ، او بیا هغه شمېره له دوو اغېزمنو ارزښتونو سره پرتله کړئ۔ ځایي drop-in بدلون بدلون د بیاکتنې وړ ساتي او د بستې لوړولو وروسته هم پاتې کېږي، په داسې حال کې چې د لېږل شوي واحد دوتنې سمول بدلون تر هغه پټوي چې بله تازه کول یې بدل کړي۔ حساب د بدلون تر څنګ ولیکئ، ځکه چې بل کس چې دا به پورته یا ښکته کړي هغه ته وروستۍ شمېره نه، بلکې انګېرنې ته اړتیا لري۔

د بودیجې بدلونونه د اجرا په وخت کې پلي کېږي، نو یوازې بیا لوستل د هغو پروسو اندازه نه بدلوي چې مخکې له مخکې چلېږي۔ واحد د خپل عادي ژوند چرخې له لارې بیا پیل کړئ، د غونډې مداخله ومنئ، او په نوي نمونه کې شمېرونکي بیا ولولئ۔

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

د سمون ثبوت هغه بیا پیل شوی واحد دی چې د دندو شمېر یې دواړو سقفونو لاندې پاتې کېږي په داسې حال کې چې اړین بار وړي، او همدارنګه هغه journal چې په هماغه پړاو کې نور د دندو یا څانګې د تمامېدو راپور نه ورکوي۔ د بدلون سره یوځای مخکې او وروسته شمېرې وساتئ، تر څو بله څېړنه له هماغې مشورې نه، بلکې له یوې اندازې پیل شي۔ که شمېر لا هم سقف ته ورسېږي، نو حساب غلط و، نه دا چې حد ناڅاپه ډېر کوچنی و، او دا توپیر باید د بل بیا پیلولو مخکې معلوم وي۔