ਪ੍ਰਕਿਰਿਆ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ Mac VPN ਹੈਲਪਰ ਦੀ ਪਛਾਣ ਕਰੋ
ਰੋਕਣ ਤੋਂ ਪਹਿਲਾਂ VPN ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਇਸ ਦੀ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਫਾਈਲ, ਕੰਟਰੋਲਰ ਅਤੇ ਨੈੱਟਵਰਕ ਭੂਮਿਕਾ ਨਾਲ ਮਿਲਾਓ, ਫਿਰ ਸਿਗਨਲ ਦੀ ਥਾਂ ਮਾਲਕ ਦੇ ਰੋਕਣ ਵਾਲੇ ਰਾਹ ਦੀ ਵਰਤੋਂ ਕਰੋ।
ਪਹਿਲਾਂ ਹੀ ਚੱਲ ਰਹੇ ਹੈਲਪਰ ਬਾਰੇ ਆਉਣ ਵਾਲੇ ਸੁਨੇਹੇ ਨੂੰ ਜੀਵਨ-ਚੱਕਰ ਦਾ ਸੰਕੇਤ ਮੰਨੋ, ਪ੍ਰਕਿਰਿਆਵਾਂ ਮਾਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ। ਖ਼ਤਰਨਾਕ ਕਦਮ ਰੋਕਣਾ ਆਪ ਨਹੀਂ, ਸਗੋਂ ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਪਛਾਣ ਹੈ, ਕਿਉਂਕਿ ਇੱਕ ਹੀ Mac ਉੱਤੇ ਸਮਾਨ ਨਾਵਾਂ ਵਾਲੇ ਕਈ ਕੰਪੋਨੈਂਟ ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਕਨੈਕਸ਼ਨ ਦਾ ਮਾਲਕ ਹੁੰਦਾ ਹੈ। ਪਹਿਲਾਂ ਪਛਾਣ ਦਾ ਰਿਕਾਰਡ ਬਣਾਓ। ਫਿਰ ਫੈਸਲਾ ਕਰੋ ਕਿ ਰੋਕਣਾ ਸਹੀ ਕਦਮ ਹੈ ਵੀ ਜਾਂ ਨਹੀਂ।
ਕੰਮ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪਛਾਣ ਦਾ ਰਿਕਾਰਡ ਬਣਾਓ
ਚਾਰ ਤੱਥ ਕਿਸੇ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪਛਾਣਨਯੋਗ ਬਣਾਉਂਦੇ ਹਨ: ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ ਸਮੇਤ ਮੌਜੂਦਾ PID, ਇਹ ਕਿਸ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਫਾਈਲ ਅਤੇ ਉਤਪਾਦ ਦੀ ਹੈ, ਇਹ ਕਿਸ ਵਰਤੋਂਕਾਰ ਜਾਂ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਸੰਦਰਭ ਹੇਠ ਚੱਲਦੀ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਕਿਸ ਨੇ ਸ਼ੁਰੂ ਕੀਤਾ। ps -o pid,ppid,user,etime,command -p 1234 ਤੁਹਾਨੂੰ ਪਹਿਲੇ ਤਿੰਨ ਤੱਥ ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਦਿੰਦਾ ਹੈ, ਪ੍ਰਕਿਰਿਆ ਕਿੰਨੀ ਦੇਰ ਤੋਂ ਚੱਲ ਰਹੀ ਹੈ ਸਮੇਤ। ਐਕਟੀਵਿਟੀ ਮਾਨੀਟਰ ਉਹੀ ਜਾਣਕਾਰੀ ਹੋਰ ਸੌਖੇ ਢੰਗ ਨਾਲ ਦਿਖਾਉਂਦਾ ਹੈ। ਕੰਟਰੋਲਰ ਵੀ ਸ਼ਾਮਲ ਕਰੋ, ਭਾਵ ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਸੇਵਾ ਜੋ ਇਸ ਨੂੰ ਸ਼ੁਰੂ ਅਤੇ ਬੰਦ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਇਹ ਚਾਰ ਹੋਣ ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਨਾਮ ਨਹੀਂ ਰਹਿੰਦੀ, ਸੋਚਣ ਯੋਗ ਵਸਤੂ ਬਣ ਜਾਂਦੀ ਹੈ।
ਜੇ ਇਹਨਾਂ ਚਾਰ ਵਿੱਚੋਂ ਇੱਕ ਵੀ ਅਣਜਾਣ ਹੈ ਤਾਂ ਉੱਥੇ ਹੀ ਰੁਕੋ। ਅਣਜਾਣ ਕੰਪੋਨੈਂਟ ਪ੍ਰਕਾਸ਼ਕ ਜਾਂ ਪ੍ਰਸ਼ਾਸਕ ਲਈ ਸਵਾਲ ਹੈ, ਪ੍ਰਯੋਗ ਲਈ ਨਹੀਂ।
ਪੁਰਾਣੇ ਲੌਗ ਵਿੱਚਲਾ PID ਹੁਣ ਕਿਸੇ ਹੋਰ ਦਾ ਹੈ
ਪ੍ਰਕਿਰਿਆ ID ਮੁੜ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਕੱਲ੍ਹ ਦੇ ਲੌਗ ਤੋਂ ਕਾਪੀ ਕੀਤਾ ਨੰਬਰ ਹੁਣ ਕਿਸੇ ਬਿਲਕੁਲ ਅਸੰਬੰਧਿਤ ਚੀਜ਼ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਸਕਦਾ ਹੈ। ਕੋਈ ਵੀ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ ਦੀ ਤੁਲਨਾ ਲੌਗ ਦੇ ਟਾਈਮਸਟੈਂਪ ਨਾਲ ਕਰੋ। ਇਹੀ ਗੱਲ ਛੋਟੇ ਨਾਮ ਉੱਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ: ਇੱਕ ਉਤਪਾਦ ਦੇ ਦੋ ਬਿਲਡ ਇੱਕੋ ਨਾਮ ਪਰ ਵੱਖਰੇ ਮਕਸਦ ਵਾਲੇ ਹੈਲਪਰ ਭੇਜ ਸਕਦੇ ਹਨ। ਪਛਾਣ ਟਪਲ ਹੁੰਦੀ ਹੈ, ਕਦੇ ਵੀ ਸਿਰਫ਼ ਨੰਬਰ ਨਹੀਂ।
ਹੋਰ ਕੁਝ ਵੀ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਵੱਖ ਕਰੋ। ਇੱਕ ਕਨੈਕਸ਼ਨ ਦਾ ਕਲਾਇੰਟ, ਕਈ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਸੇਵਾ ਕਰਨ ਵਾਲਾ ਸਾਂਝਾ ਹੈਲਪਰ, ਅਤੇ ਦੂਜਿਆਂ ਦੇ ਸੈਸ਼ਨ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲਾ ਸਰਵਰ — ਇਹ ਸਾਰੇ ਸੂਚੀ ਵਿੱਚ ਬੈਕਗਰਾਊਂਡ ਪ੍ਰਕਿਰਿਆ ਵਾਂਗ ਦਿਖਦੇ ਹਨ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਨੂੰ ਹੀ ਬਿਨਾਂ ਅਣਸੋਚੇ ਨਤੀਜਿਆਂ ਦੇ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਸਿਗਨਲ ਰਾਹੀਂ ਨਹੀਂ, ਮਾਲਕ ਰਾਹੀਂ ਰੋਕੋ
ਉਸ ਕੰਟਰੋਲ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਉਸ ਚੀਜ਼ ਦਾ ਮਾਲਕ ਹੈ: ਕਨੈਕਸ਼ਨ ਦਾ ਡਿਸਕਨੈਕਟ ਬਟਨ, ਸੇਵਾ ਦਾ ਸਮਰਥਿਤ ਰੋਕਣ ਵਾਲਾ ਕਮਾਂਡ, ਜਾਂ ਪ੍ਰਬੰਧਨ ਏਜੰਟ ਦੀ ਆਪਣੀ ਕਾਰਵਾਈ। ਇਹ ਰਾਹ ਉਹ ਟੀਅਰਡਾਊਨ ਚਲਾਉਂਦੇ ਹਨ ਜਿਸ ਦੀ ਉਤਪਾਦ ਆਸ ਰੱਖਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਰੂਟ ਹਟਾਉਣਾ ਅਤੇ ਟਨਲ ਡਿਵਾਈਸ ਬੰਦ ਕਰਨਾ ਸ਼ਾਮਲ ਹੈ। ਸਿਗਨਲ ਇਹ ਸਭ ਛੱਡ ਦਿੰਦਾ ਹੈ ਅਤੇ ਪਿੱਛੇ ਸਥਿਤੀ ਛੱਡ ਜਾਂਦਾ ਹੈ।
ਬਾਅਦ ਵਿੱਚ ਕੀ ਬਚਦਾ ਹੈ, ਦੇਖੋ। ਰਹਿ ਗਈ ਪ੍ਰਕਿਰਿਆ ਅਗਲੇ ਕਨੈਕਸ਼ਨ ਦੀ ਉਡੀਕ ਕਰ ਰਹੀ ਹੋ ਸਕਦੀ ਹੈ, ਜੋ ਅਸਫਲ ਰੋਕ ਨਹੀਂ, ਡਿਜ਼ਾਈਨ ਦੀ ਚੋਣ ਹੈ।
ਸੁਪਰਵਾਈਜ਼ਰ ਤੁਹਾਡੇ ਮਾਰੇ ਹੋਏ ਨੂੰ ਕਿਉਂ ਮੁੜ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ
ਜੇ ਲਾਂਚ ਡੈਮਨ ਜਾਂ ਸਵੈ-ਕਨੈਕਟ ਨੀਤੀ ਚਾਹੁੰਦੀ ਹੈ ਕਿ ਟਨਲ ਖੁੱਲ੍ਹਾ ਰਹੇ, ਤਾਂ ਪ੍ਰਕਿਰਿਆ ਮਾਰਨਾ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਸੁਪਰਵਾਈਜ਼ਰ ਬਾਹਰ ਨਿਕਲਣਾ ਦੇਖਦਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਫਿਰ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ, ਕਈ ਵਾਰ ਤੁਹਾਡੇ ਲੌਗ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ।
ਲੜਨ ਤੋਂ ਪਹਿਲਾਂ ਸੁਪਰਵਾਈਜ਼ਰ ਲੱਭੋ। launchctl list ਲੋਡ ਹੋਏ ਜੌਬ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਲੇਬਲ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ keep-alive ਸੈਟਿੰਗ ਵਾਲੀ ਜੌਬ ਬਾਹਰ ਨਿਕਲਣ ਉੱਤੇ ਮੁੜ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਉਸੇ ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ। ਉੱਥੇ ਸਹੀ ਕੰਮ ਇਰਾਦਾ ਬਦਲਣਾ ਹੈ: ਜੌਬ ਅਨਲੋਡ ਕਰੋ, ਸਵੈ-ਕਨੈਕਟ ਨੀਤੀ ਬੰਦ ਕਰੋ, ਜਾਂ ਪ੍ਰਸ਼ਾਸਕ ਨੂੰ ਅਜਿਹਾ ਕਰਨ ਲਈ ਕਹੋ। ਜ਼ਬਰਦਸਤੀ ਬੰਦ ਕਰਨਾ ਵੱਖਰਾ ਅਰਥ ਰੱਖਣ ਵਾਲਾ ਵੱਖਰਾ ਸੰਦ ਹੈ, ਅਤੇ ਇਹ ਅਟਕੀ ਹੋਈ ਪ੍ਰਕਿਰਿਆ ਲਈ ਲਿਖਤੀ ਰਿਕਵਰੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਹਿੱਸਾ ਹੈ, ਨਿਯਮਿਤ ਕਨੈਕਸ਼ਨ ਪ੍ਰਬੰਧਨ ਦਾ ਨਹੀਂ।
ਮਾਰਨਾ ਨਹੀਂ, ਜੀਵਨ-ਚੱਕਰ ਘਟਨਾ ਦਰਜ ਕਰੋ
ਕੰਪੋਨੈਂਟ ਦੀ ਪਛਾਣ, ਕਲਾਇੰਟ ਸੰਸਕਰਣ, ਪਹਿਲੀ ਸੰਬੰਧਿਤ ਜੀਵਨ-ਚੱਕਰ ਘਟਨਾ ਅਤੇ ਤੁਸੀਂ ਕੀ ਕੀਤਾ, ਲਿਖੋ। ਘਟਨਾ ਕਾਰਵਾਈ ਨਾਲੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਲੌਗਇਨ ਸਮੇਂ ਦੋ ਇੰਸਟੈਂਸ ਦਿਖਣਾ ਸ਼ੁਰੂਆਤੀ ਕ੍ਰਮ ਦੀ ਸਮੱਸਿਆ ਹੈ ਜੋ ਦੁਹਰਾਏਗੀ। ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਫਾਈਲ ਅਤੇ ਕੰਟਰੋਲਰ ਦਾ ਨਾਮ ਦੱਸਣ ਵਾਲਾ ਰਿਕਾਰਡ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਇਸ ਨੂੰ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰਨ ਦਿੰਦਾ ਹੈ।
ਫਿਰ ਇੱਛਤ ਸਥਿਤੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: ਵਰਤੋਂਕਾਰ ਨੂੰ ਲੋੜੀਂਦੀ ਸੇਵਾ, ਅਤੇ ਉਹ ਨਿੱਜੀ ਸਰੋਤ ਜਿਸ ਤੱਕ ਇਹ ਪਹੁੰਚਦੀ ਹੈ। ਸਬਸਟ੍ਰਿੰਗ ਲੱਭ ਕੇ ਹਰ ਮੇਲ ਨੂੰ ਜ਼ਬਰਦਸਤੀ ਮਾਰਨ ਵਾਲੀ ਪਾਈਪਲਾਈਨ ਤੋਂ ਬਚੋ, ਕਿਉਂਕਿ ਇਹ ਉੱਪਰ ਦੱਸੀ ਹਰ ਗੱਲ ਛੱਡ ਦਿੰਦੀ ਹੈ ਅਤੇ ਆਮ ਤੌਰ ਉੱਤੇ ਇਸ ਬਾਰੇ ਸਬੂਤ ਨਸ਼ਟ ਕਰ ਦਿੰਦੀ ਹੈ ਕਿ ਦੋ ਇੰਸਟੈਂਸ ਕਿਉਂ ਸਨ। ਜੇ ਪ੍ਰਕਿਰਿਆ ਵਾਰ-ਵਾਰ ਵਾਪਸ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਨਤੀਜਾ ਸੰਰਚਨਾ ਜਾਂ ਕ੍ਰਮ ਦੀ ਖਰਾਬੀ ਹੈ, ਅਤੇ ਸੁਧਾਰ ਕਲਾਇੰਟ ਦੇ ਸ਼ੁਰੂਆਤੀ ਵਿਵਹਾਰ ਦੇ ਮਾਲਕ ਕੋਲ ਹੀ ਹੈ।