LimitNPROC ба TasksMax: OpenVPN нэгж юу тоолдог

OpenVPN эхлүүлэхэд гарсан алдаа нь ихэвчлэн нөөцийн талаарх гомдол болон ямар нэг хязгаарыг өсгөх санаа бодолтой саналын хамт ирдэг бөгөөд тэр санал зөвхөн ойролцоогоор хагас тохиолдолд л ажилладаг. Эдгээр алдааны цаана хоорондоо холбоогүй хоёр тоолуур байдаг. Нэг нь бодит хэрэглэгчийн ID-д хамаарах даалгаврын тоонд цөмийн тавьдаг хязгаар бөгөөд процесс ажиллах үед өвлөгддөг. Нөгөө нь үйлчилгээний менежер нэг нэгж болон түүнээс салбарлаж гарсан бүх зүйлд хэрэглэдэг cgroup-ийн төсөв юм. Аль нэг нь жинхэнэ ажиллаж буй нэгжийн хувьд бодит утгыг унших нь таамаглалаас хямд.

Хоёр тоолуур, хоёр асуулт

LimitNPROC бол systemd нэрэн дор байх RLIMIT_NPROC бөгөөд түүний тооцооны нэгж нь бодит хэрэглэгчийн ID юм. Тэр хэрэглэгчийн эзэмшдэг бүх процесс ижил нийлбэрт тооцогддог бөгөөд бусад нэгж, нэвтрэх сесс эсвэл төлөвлөгчийн даалгаврын эхлүүлсэн ажил ч багтана. Тиймээс энэ хязгаар нь үйлчилгээний нэгжийн дотор тавигдсан ч үйлчилгээ тус бүрийн дээд хязгаар биш бөгөөд үйлчлүүлэгч бүрт туслахыг салбарладаг үйлчилгээ тэр дансны дор ажиллаж буй бусад бүх зүйлтэй өрсөлддөг. Мөн хэрэглэгчийн дор ажиллаж буй завгүй cron даалгавар VPN нэгжийг өөрөө хэзээ ч хөндөөгүй шугамаас цааш түлхэж болно.

TasksMax өөр эзэнтэй: нэгжийн cgroup дээрх pids хянагч бөгөөд процесс биш даалгаврыг тоолдог. Утаснууд нь даалгавар тул нэг утастай мэт харагдах боловч ажилчдын сантай демон процессын тооноос хамаагүй том харагдах төсвийг зарцуулж болно. EffectiveTasksMax эцэг хэсгүүд үгээ хэлсний дараа cgroup-ийн шатлал бодитоор юуг зөвшөөрдөг талаар мэдээлдэг.

Яагаад root-ийн үл хамаарах зүйл хариултыг өөрчилдөг

Цөм нь CAP_SYS_RESOURCE эсвэл CAP_SYS_ADMIN агуулсан процесс дээр RLIMIT_NPROC-ийг хэрэглэдэггүй тул онцгой эрхээс татгалзахгүйгээр 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 юм. Өөрчлөлтийн хамт өмнөх ба дараах тоог хадгалаарай, ингэснээр дараагийн шалгалт тэр зөвлөмжөөс биш хэмжилтээс эхэлнэ. Хэрэв тоо дээд хязгаарт хүрсээр байвал арифметик буруу байсан бөгөөд хязгаар санамсаргүй хэт бага байгаагүй, тэр ялгааг дараагийн дахин эхлүүлэлтийн өмнө мэдэх нь зүйтэй.