LimitNPROC ਬਨਾਮ TasksMax: ਇੱਕ OpenVPN ਯੂਨਿਟ ਕੀ ਗਿਣਦੀ ਹੈ

ਅਸਫਲ OpenVPN ਸ਼ੁਰੂਆਤ ਅਕਸਰ ਸਰੋਤ ਦੀ ਸ਼ਿਕਾਇਤ ਅਤੇ ਸੀਮਾ ਵਧਾਉਣ ਦੇ ਚੰਗੇ ਇਰਾਦੇ ਵਾਲੇ ਸੁਝਾਅ ਨਾਲ ਆਉਂਦੀ ਹੈ, ਅਤੇ ਉਹ ਸੁਝਾਅ ਸਿਰਫ਼ ਲਗਭਗ ਅੱਧੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਅਸਫਲਤਾਵਾਂ ਪਿੱਛੇ ਦੋ ਅਸੰਬੰਧਿਤ ਕਾਊਂਟਰ ਹਨ। ਇੱਕ ਅਸਲੀ ਵਰਤੋਂਕਾਰ ID ਦੀ ਮਲਕੀਅਤ ਵਾਲੇ ਕੰਮਾਂ ਦੀ ਗਿਣਤੀ ਉੱਤੇ ਕਰਨਲ ਦੀ ਸੀਮਾ ਹੈ, ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਚਲਾਉਣ ਵੇਲੇ ਇਹ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਦੀ ਹੈ। ਦੂਜਾ cgroup ਬਜਟ ਹੈ, ਜੋ ਸੇਵਾ ਪ੍ਰਬੰਧਕ ਇੱਕ ਯੂਨਿਟ ਅਤੇ ਉਸ ਤੋਂ ਫੋਰਕ ਹੋਣ ਵਾਲੀ ਹਰ ਚੀਜ਼ ਉੱਤੇ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਜੋ ਯੂਨਿਟ ਅਸਲ ਵਿੱਚ ਚੱਲ ਰਹੀ ਹੈ, ਉਸ ਲਈ ਹਰੇਕ ਦਾ ਪ੍ਰਭਾਵੀ ਮੁੱਲ ਪੜ੍ਹਨਾ ਅੰਦਾਜ਼ੇ ਤੋਂ ਘੱਟ ਖਰਚੀਲਾ ਹੈ।

ਦੋ ਕਾਊਂਟਰ, ਦੋ ਸਵਾਲ

LimitNPROC systemd ਨਾਂ ਹੇਠ RLIMIT_NPROC ਹੈ, ਅਤੇ ਇਸਦੀ ਲੇਖਾ-ਇਕਾਈ ਅਸਲੀ ਵਰਤੋਂਕਾਰ ID ਹੈ। ਉਸ ਵਰਤੋਂਕਾਰ ਦੀ ਮਲਕੀਅਤ ਵਾਲੀ ਹਰ ਪ੍ਰਕਿਰਿਆ ਉਸੇ ਕੁੱਲ ਵਿੱਚ ਗਿਣੀ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਹੋਰ ਯੂਨਿਟਾਂ, ਲੌਗਇਨ ਸੈਸ਼ਨ ਜਾਂ ਸ਼ਡਿਊਲਰ ਜੌਬ ਵੱਲੋਂ ਸ਼ੁਰੂ ਕੀਤਾ ਕੰਮ ਵੀ ਸ਼ਾਮਲ ਹੈ। ਇਸ ਲਈ ਇਹ ਸੀਮਾ ਸੇਵਾ-ਵਾਰ ਕੈਪ ਨਹੀਂ ਹੈ, ਭਾਵੇਂ ਇਹ ਕਿਸੇ ਸੇਵਾ ਯੂਨਿਟ ਦੇ ਅੰਦਰ ਸੈੱਟ ਕੀਤੀ ਗਈ ਹੋਵੇ, ਅਤੇ ਹਰ ਕਲਾਇੰਟ ਲਈ ਸਹਾਇਕ ਫੋਰਕ ਕਰਨ ਵਾਲੀ ਸੇਵਾ ਉਸ ਖਾਤੇ ਹੇਠ ਚੱਲ ਰਹੀ ਬਾਕੀ ਹਰ ਚੀਜ਼ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦੀ ਹੈ। ਉਸੇ ਵਰਤੋਂਕਾਰ ਹੇਠ ਇੱਕ ਰੁੱਝਿਆ ਕ੍ਰੋਨ ਜੌਬ 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 ਜੋ ਉਸੇ ਪੜਾਅ ਉੱਤੇ ਹੁਣ ਕੰਮ ਜਾਂ ਫੋਰਕ ਖ਼ਤਮ ਹੋਣ ਦੀ ਸੂਚਨਾ ਨਹੀਂ ਦਿੰਦਾ। ਬਦਲਾਅ ਨਾਲ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਦੀਆਂ ਗਿਣਤੀਆਂ ਰੱਖੋ, ਤਾਂ ਜੋ ਅਗਲੀ ਜਾਂਚ ਉਸੇ ਸਲਾਹ ਤੋਂ ਨਹੀਂ, ਮਾਪ ਤੋਂ ਸ਼ੁਰੂ ਹੋਵੇ। ਜੇ ਗਿਣਤੀ ਅਜੇ ਵੀ ਸੀਮਾ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ, ਤਾਂ ਗਣਨਾ ਹੀ ਗਲਤ ਸੀ, ਸੀਮਾ ਇਤਫ਼ਾਕਨ ਬਹੁਤ ਛੋਟੀ ਨਹੀਂ ਸੀ, ਅਤੇ ਅਗਲੇ ਰੀਸਟਾਰਟ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਫ਼ਰਕ ਜਾਣਨਾ ਢੁੱਕਦਾ ਹੈ।