ਕੁਝ ਇੱਕ OpenVPN ਯੂਨਿਟ ਨੂੰ ਵਾਰ-ਵਾਰ ਸ਼ੁਰੂ ਕਰ ਰਿਹਾ ਹੈ: ਸਰੋਤ ਲੱਭੋ

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

ਪਹਿਲਾਂ ਸਹੀ ਯੂਨਿਟ ਦਾ ਨਾਮ ਦਿਓ

ਪਰੋਫਾਈਲ ਫਾਈਲ ਦੇ ਨਾਮ ਦੀ ਬਜਾਏ journal ਵਿੱਚ ਯੂਨਿਟ ਦੇ ਨਾਮ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਇੰਸਟੈਂਸ ਦਾ ਨਾਮ openvpn@, openvpn-client@, openvpn-server@ ਜਾਂ ਵੰਡ-ਵਿਸ਼ੇਸ਼ ਕੁਝ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਨਾਮ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਤੁਹਾਨੂੰ ਗਲਤ ਟੈਂਪਲੇਟ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ। ਸਟੇਟਸ ਆਉਟਪੁੱਟ ਉਸ ਯੂਨਿਟ ਦਾ ਨਾਮ ਦਿੰਦੀ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਚੱਲੀ, ਅਤੇ ਇੱਥੇ ਸਿਰਫ਼ ਉਹੀ ਨਾਮ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇਸਨੂੰ ਬਿਲਕੁਲ ਉਵੇਂ ਕਾਪੀ ਕਰੋ, ਕਿਸੇ ਵੀ ਪਿਛੇਤਰ ਸਮੇਤ।

ਹੇਠ ਲਿਖੇ ਕਮਾਂਡ ਕੁਝ ਬਦਲੇ ਬਿਨਾਂ ਉਸ ਯੂਨਿਟ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ। systemctl show ਫਰੈਗਮੈਂਟ ਪਥ, ਸਰੋਤ ਪਥ, ਯੂਨਿਟ ਫਾਈਲ ਦੀ ਸਥਿਤੀ, ਕੋਈ ਵੀ drop-in ਅਤੇ ਇਸਨੂੰ ਕੀ ਸਰਗਰਮ ਕਰਦਾ ਹੈ, ਦੱਸਦਾ ਹੈ। list-dependencies --reverse ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਲੋਡ ਕੀਤੀਆਂ ਯੂਨਿਟਾਂ ਇਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀਆਂ ਹਨ। ਦੋਵੇਂ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਵਾਲੇ ਹਨ, ਇਸ ਲਈ ਸਿਧਾਂਤ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹਨਾਂ ਨੂੰ ਚਲਾਓ।

ਦਿੱਸਿਆ ਨਾਮ ਹਰ ਥਾਂ ਬਦਲੋ। ਕਾਪੀ ਕੀਤਾ ਉਦਾਹਰਨ ਨਾਮ ਗਲਤ ਸੇਵਾ ਦੀ ਜਾਂਚ ਦਾ ਸਭ ਤੋਂ ਆਮ ਤਰੀਕਾ ਹੈ, ਅਤੇ ਇਹ ਅਜਿਹੀ ਯੂਨਿਟ ਬਾਰੇ ਭਰੋਸੇਯੋਗ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜੋ ਕਦੇ ਨਹੀਂ ਚੱਲੀ।

ਫਾਈਲ ਦਾ ਨਾਮ ਜਾਣਨ ਲਈ ਟੈਂਪਲੇਟ ਪੜ੍ਹੋ

ਇੰਸਟੈਂਸ ਯੂਨਿਟ ਟੈਂਪਲੇਟ ਦਾ ਵਿਸਤਾਰ ਹੈ, ਅਤੇ ਟੈਂਪਲੇਟ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿਹੜੀ ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ। ਇੰਸਟੈਂਸ-ਵਿਸ਼ੇਸ਼ ਪਲੇਸਹੋਲਡਰ ਉੱਤੇ ਖ਼ਤਮ ਹੋਣ ਵਾਲੀ ਕਮਾਂਡ ਲਾਈਨ ਇੰਸਟੈਂਸ ਨਾਮ ਅਤੇ ਪਿਛੇਤਰ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ। ਜੇ ਪਿਛੇਤਰ .conf ਹੈ ਅਤੇ ਇੰਸਟੈਂਸ ਦਾ ਨਾਮ old ਹੈ, ਫਾਈਲ old.conf ਹੈ। ਜੇ ਇੰਸਟੈਂਸ ਦਾ ਨਾਮ old.conf ਰੱਖੋ, ਉਹੀ ਟੈਂਪਲੇਟ old.conf.conf ਮੰਗਦਾ ਹੈ।

ਇਹ ਵੇਰਵਾ ਡੁਪਲੀਕੇਟਾਂ ਦੀ ਇੱਕ ਸ਼੍ਰੇਣੀ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ। ਕੋਈ ਗਲਤ ਨਾਮ ਹੇਠ ਦੂਜਾ ਇੰਸਟੈਂਸ ਜੋੜਦਾ ਹੈ, ਪਹਿਲਾ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਹੋਸਟ ਦੋ ਟਨਲ ਅਤੇ ਇੱਕ ਉਲਝਣ ਭਰਿਆ ਲੌਗ ਨਾਲ ਰਹਿ ਜਾਂਦਾ ਹੈ।

ਉਹ ਫਾਈਲ ਪੜ੍ਹੋ ਜੋ ਅਸਲ ਵਿੱਚ ਲਾਗੂ ਹੈ, ਨਾ ਕਿ ਉਹ ਜੋ ਤੁਹਾਨੂੰ ਸੰਪਾਦਿਤ ਕੀਤੀ ਯਾਦ ਹੈ। Drop-in ਕਮਾਂਡ ਲਾਈਨ ਬਦਲ ਸਕਦਾ ਹੈ, ਅਤੇ ਬੂਟ ਸਮੇਂ ਉਹੀ ਬਦਲਾਅ ਚੱਲਦਾ ਹੈ।

ਟ੍ਰੇਸ ਕਰੋ ਕਿ ਇਹ ਬੂਟ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਵਿੱਚ ਕਿਵੇਂ ਦਾਖਲ ਹੁੰਦਾ ਹੈ

ਤਿੰਨ ਰਾਹ ਆਮ ਹਨ: ਟਾਰਗੇਟ ਤੋਂ wants ਲਿੰਕ, ਦੂਜੀ ਯੂਨਿਟ ਤੋਂ ਲੋੜ, ਜਾਂ ਪੈਕੇਜ ਜਨਰੇਟਰ ਦੁਆਰਾ ਬਣਾਈ ਯੂਨਿਟ। ਉਲਟ ਨਿਰਭਰਤਾਵਾਂ ਦੀ ਸੂਚੀ ਪਹਿਲੇ ਦੋ ਨੂੰ ਲੋਡ ਕੀਤੀਆਂ ਗ੍ਰਾਫ ਐਂਟਰੀਆਂ ਵਜੋਂ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ। ਇਹ ਟਾਈਮਰ, ਹੁੱਕ ਜਾਂ ਬਾਹਰੀ ਬੇਨਤੀ ਨੂੰ ਸ਼ਾਮਲ ਨਹੀਂ ਕਰਦੀ, ਇਸ ਲਈ ਸੂਚੀ ਪੂਰੀ ਆਡਿਟ ਨਹੀਂ ਬਲਕਿ ਸਬੂਤ ਹੈ।

/run/systemd/generator ਹੇਠ ਬਣਾਇਆ ਆਉਟਪੁੱਟ ਉਤਪਾਦ ਹੈ, ਸਰੋਤ ਨਹੀਂ। ਇਸਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨਾ ਸਿਰਫ਼ ਅਗਲੀ ਜਨਰੇਸ਼ਨ ਤੱਕ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਉੱਥੇ ਲਾਗੂ ਸੁਧਾਰ ਸਫਲ ਦਿਸਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ।

ਇਹ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਜਨਰੇਟਰ ਕਿੱਥੋਂ ਪੜ੍ਹਦਾ ਹੈ, ਪੈਕੇਜ ਦੇ ਦਸਤਾਵੇਜ਼ੀ ਇਨਪੁੱਟ ਦੀ ਜਾਂਚ ਕਰੋ। ਕਿਸੇ ਡਾਇਰੈਕਟਰੀ ਦੀ ਬਿਨਾਂ ਦਸਤਾਵੇਜ਼ ਸਕੈਨਿੰਗ ਹੀ ਆਮ ਕਾਰਨ ਹੈ ਕਿ ਯੂਨਿਟ ਸਰਗਰਮੀ ਲਿੰਕ ਤੋਂ ਬਿਨਾਂ ਦਿਸਦੀ ਹੈ।

ਸਰਗਰਮੀ ਹਟਾਓ, ਸਿਰਫ਼ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ

ਜੇ ਇੰਸਟੈਂਸ ਸਿੱਧਾ ਸਰਗਰਮ ਹੈ ਅਤੇ ਸੱਚਮੁੱਚ ਪੁਰਾਣਾ ਹੈ, systemctl disable --now ਇਸਨੂੰ ਰੋਕਦਾ ਹੈ ਅਤੇ ਬੂਟ ਲਿੰਕ ਇੱਕ ਕਦਮ ਵਿੱਚ ਹਟਾ ਦਿੰਦਾ ਹੈ। ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ ਇਹ ਟਨਲ ਹੋਸਟ ਤੱਕ ਤੁਹਾਡਾ ਇੱਕੋ-ਇੱਕ ਪ੍ਰਬੰਧਕੀ ਰਾਹ ਨਹੀਂ। ਕਮਾਂਡ ਜੀਵਨ-ਚੱਕਰ ਦੀ ਉਦਾਹਰਨ ਹੈ, ਮਸ਼ੀਨ ਉੱਤੇ ਹਰ VPN ਰੋਕਣ ਦਾ ਸੁਝਾਅ ਨਹੀਂ। ਜਾਂਚ ਕਮਾਂਡ ਤੋਂ ਪਹਿਲਾਂ ਕਰੋ, ਬਾਅਦ ਵਿੱਚ ਨਹੀਂ।

ਦੋਵੇਂ ਅੱਧ ਵੱਖ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ ਅਤੇ ਅਕਸਰ ਉਲਝ ਜਾਂਦੇ ਹਨ। ਅਸਮਰੱਥ ਕਰਨਾ ਚੱਲ ਰਹੀ ਸੇਵਾ ਨੂੰ ਨਹੀਂ ਰੋਕਦਾ, ਅਤੇ ਰੋਕਣਾ ਸਰਗਰਮੀ ਨਹੀਂ ਹਟਾਉਂਦਾ, ਇਸ ਲਈ ਅਧੂਰੀ ਕਮਾਂਡ ਉਸ ਸਮੱਸਿਆ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ ਜੋ ਬੂਟ ਉੱਤੇ ਵਾਪਸ ਆਉਂਦੀ ਹੈ।

ਅਸਮਰੱਥ ਯੂਨਿਟ ਅਜੇ ਵੀ ਦੂਜੀ ਯੂਨਿਟ ਜਾਂ ਸਪੱਸ਼ਟ ਬੇਨਤੀ ਨਾਲ ਸ਼ੁਰੂ ਹੋ ਸਕਦੀ ਹੈ। ਜਦੋਂ ਸਰਗਰਮੀ ਜਨਰੇਟਰ ਕੋਲ ਹੋਵੇ, ਤਾਂ ਉਸਦਾ ਆਉਟਪੁੱਟ ਅਸਮਰੱਥ ਕਰਨ ਦੀ ਬਜਾਏ ਉਸਦਾ ਇਨਪੁੱਟ ਠੀਕ ਕਰੋ। ਮਾਸਕਿੰਗ ਵਧੇਰੇ ਰਾਹ ਰੋਕਦੀ ਹੈ ਪਰ ਨਿਰਭਰਤਾਵਾਂ ਤੋੜ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਇਹ ਸਮਝ ਦਾ ਬਦਲ ਨਹੀਂ।

ਸਟੇਟਸ ਸਕਰੀਨ ਨਾਲ ਨਹੀਂ, ਰੀਬੂਟ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ

ਜੇ ਯੂਨਿਟ ਪਰਿਭਾਸ਼ਾਵਾਂ ਜਾਂ ਜਨਰੇਟਰ ਇਨਪੁੱਟ ਬਦਲੇ ਹਨ ਤਾਂ systemd ਮੁੜ ਲੋਡ ਕਰੋ, ਫਿਰ ਨਤੀਜੇ ਵਾਲੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰੋ। ਡੈਮਨ ਮੁੜ ਲੋਡ ਚੱਲ ਰਹੀ ਟਨਲ ਵਿੱਚ ਨਵੀਂ ਪਰੋਫਾਈਲ ਨਹੀਂ ਧੱਕਦਾ, ਇਸ ਲਈ ਦੋਵੇਂ ਜਾਂਚਾਂ ਵੱਖਰੀਆਂ ਹਨ। ਰੀਬੂਟ ਤੈਅ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇੰਸਟੈਂਸ ਗੈਰਹਾਜ਼ਰ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਇੱਛਤ ਟਨਲ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦੀ ਹੈ।

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