LimitNPROC lawan TasksMax: apa yang dikira oleh unit OpenVPN

Kegagalan memulakan OpenVPN sering datang sebagai aduan sumber bersama cadangan berniat baik untuk menaikkan sesuatu had, dan cadangan itu hanya berkesan dalam kira-kira separuh kes. Di sebalik kegagalan itu terdapat dua pembilang yang tidak berkaitan. Satu ialah had kernel pada bilangan tugas yang dimiliki oleh ID pengguna sebenar, dan ia diwarisi apabila proses dilaksanakan. Satu lagi ialah belanjawan cgroup yang dikenakan oleh pengurus perkhidmatan pada satu unit dan semua yang diforknya. Membaca nilai berkesan setiap satu, untuk unit yang benar-benar berjalan, lebih murah daripada tekaan.

Dua pembilang, dua soalan

LimitNPROC ialah RLIMIT_NPROC di bawah nama systemd, dan unit perakaunannya ialah ID pengguna sebenar. Setiap proses milik pengguna itu dikira terhadap jumlah yang sama, termasuk kerja yang dimulakan oleh unit lain, sesi log masuk atau tugas penjadual. Oleh itu had ini bukan siling setiap perkhidmatan walaupun ia ditetapkan di dalam unit perkhidmatan, dan perkhidmatan yang memfork pembantu bagi setiap klien bersaing dengan semua perkara lain yang berjalan di bawah akaun itu. Tugas cron yang sibuk di bawah pengguna yang sama boleh menolak unit VPN melepasi garisan yang tidak pernah dilaluinya sendiri.

TasksMax mempunyai pemilik lain: pengawal pids pada cgroup unit itu, yang mengira tugas dan bukan proses. Benang ialah tugas, jadi daemon yang kelihatan satu benang tetapi mempunyai kumpulan pekerja boleh menghabiskan belanjawan yang pada pandangan pertama kelihatan jauh lebih besar daripada bilangan prosesnya. EffectiveTasksMax melaporkan apa yang sebenarnya dibenarkan oleh hierarki cgroup selepas slaid induk berkata bahagiannya.

Mengapa pengecualian root mengubah jawapannya

Kernel tidak menerapkan RLIMIT_NPROC pada proses yang membawa CAP_SYS_RESOURCE atau CAP_SYS_ADMIN, dan itulah sebabnya unit yang berjalan sebagai root tanpa melepaskan keistimewaan secara praktiknya tidak terhad oleh tetapan itu. Pengecualian tunggal ini menjelaskan nasihat bercanggah yang orang saling bertukar: menaikkan LimitNPROC membaiki penggunaan yang melepaskan keistimewaan dan tidak melakukan apa-apa sama sekali bagi yang kekal istimewa. Semak User= dan sama ada daemon menukar identiti selepas permulaan sebelum menyalahkan atau memuji tetapan itu. Unit istimewa yang kemudian beralih kepada akaun tanpa keistimewaan kembali jatuh di bawah had pada saat peralihan, yang menjadikan garis masa kegagalan itu juga wajar dibaca.

Peringkat kegagalan menyempitkannya lagi. Penolakan semasa penyediaan pelaksanaan, ralat fork yang dilaporkan oleh daemon sendiri dan penciptaan tugas yang ditolak di dalam cgroup menghasilkan baris journal yang berbeza, dan hanya satu daripadanya dijawab oleh belanjawan yang lebih besar.

Baca nilai berkesan, bukan nilai shell

ulimit -u dalam shell interaktif menerangkan shell itu. Ia tidak menerangkan apa yang diserahkan oleh pengurus perkhidmatan kepada daemon, dan tidak berkata apa-apa tentang perakaunan cgroup. Tanyalah unit itu, menggunakan nama instans yang wujud pada hos dan bukan contoh daripada panduan.

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

Di dalam kontena jawapannya memerlukan dua bacaan lagi, kerana nilai dalaman infinity hanya menerangkan pandangan tetamu. Mintalah siling pids kontena itu sendiri daripada pemilik hos, dan sahkan sama ada pengurus perkhidmatan dalaman boleh mewakilkan pengawal itu langsung. Unit bersarang tidak boleh memegang belanjawan yang tidak pernah diberikan oleh cgroup induknya.

Saiz pembaikan dan buktikannya di bawah beban

Pilih nombor daripada beban kerja, bukan daripada teks ralat. Kira proses yang dimulakan daemon bagi setiap klien yang disambungkan atau setiap panggilan pembantu, darab dengan keserentakan yang dijangka ditanggung oleh penggunaan, tambah sedikit margin untuk sesi pentadbiran, kemudian bandingkan nombor itu dengan dua nilai berkesan. Penggantian drop-in setempat mengekalkan perubahan boleh disemak dan bertahan melalui peningkatan pakej, manakala menyunting fail unit yang dihantar menyembunyikan perubahan sehingga kemas kini berikutnya menggantikannya. Tulis aritmetik di sebelah penggantian, kerana orang seterusnya yang menaikkan atau menurunkannya memerlukan andaian, bukan nombor akhir.

Perubahan belanjawan digunakan semasa pelaksanaan, jadi memuat semula sahaja tidak mengubah saiz proses yang sudah berjalan. Mulakan semula unit melalui kitaran hayat biasanya, terima gangguan sesi itu, dan baca pembilang sekali lagi pada instans baharu.

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

Yang membuktikan pembaikan ialah unit yang dimulakan semula dengan bilangan tugas di bawah kedua-dua siling sambil memikul beban yang dimaksudkan, serta journal yang tidak lagi melaporkan kehabisan tugas atau fork pada peringkat yang sama. Simpan nombor sebelum dan selepas bersama perubahan itu supaya siasatan berikutnya bermula daripada ukuran dan bukan daripada nasihat yang sama. Jika bilangannya masih mencapai siling, aritmetiknya yang salah dan bukan hadnya kebetulan terlalu kecil, dan perbezaan itu wajar diketahui sebelum permulaan semula yang berikutnya.