ExecStart ਕੋਈ shell ਨਹੀਂ: VPN ਸਹਾਇਕ ਯੂਨਿਟ ਠੀਕ ਕਰਨਾ
ExecStart ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਆਰਗਿਊਮੈਂਟਾਂ ਨਾਲ ਚਲਾਉਂਦਾ ਹੈ, shell ਪਾਈਪਲਾਈਨ ਨਹੀਂ। ਸਪਸ਼ਟ ਇੰਟਰਪ੍ਰੀਟਰ ਜਾਂ ਅਸਲ ਸਕ੍ਰਿਪਟ ਵਰਤੋ, ਫਿਰ ਯੂਨਿਟ ਜਾਂਚੋ ਅਤੇ ਜਰਨਲ ਪੜ੍ਹੋ।
ਕੰਮ ਕਰਦੀ ਕਮਾਂਡ ਲਾਈਨ ExecStart ਵਿੱਚ ਕਾਪੀ ਕਰੋ, ਰੀਲੋਡ ਕਰੋ, ਅਤੇ ਯੂਨਿਟ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ ਜਾਂ ਚੁੱਪਚਾਪ ਬਾਹਰ ਨਿਕਲ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਆਰਗਿਊਮੈਂਟਾਂ ਨੂੰ ਫਾਈਲ ਨਾਮ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। systemd ਵਿੱਚ ਕੁਝ ਵੀ ਟੁੱਟਿਆ ਨਹੀਂ। ExecStart ਆਰਗਿਊਮੈਂਟਾਂ ਦੀ ਸੂਚੀ ਹੈ, shell ਨਹੀਂ, ਇਸ ਲਈ ਪਾਈਪ, ਰੀਡਾਇਰੈਕਸ਼ਨ ਅਤੇ ਸ਼ਰਤਾਂ ਤੁਹਾਡਾ ਟਰਮੀਨਲ ਛੱਡਣ ਸਾਰ ਅਰਥ ਗੁਆ ਦਿੰਦੀਆਂ ਹਨ। shell ਕਿੱਥੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਇਹ ਤੈਅ ਕਰੋ, ਫਿਰ ਅਜਿਹੀ ਯੂਨਿਟ ਲਿਖੋ ਜੋ ਠੀਕ-ਠੀਕ ਦੱਸੇ ਕਿ ਕੀ ਚਲਾਉਣਾ ਹੈ।
ExecStart ਵਿੱਚ ਪਾਈਪਲਾਈਨ ਕਿਉਂ ਕੁਝ ਨਹੀਂ ਕਰਦੀ
ਜਦੋਂ ਟਰਮੀਨਲ ਵਿੱਚ ਕਮਾਂਡ ਟਾਈਪ ਹੁੰਦੀ ਹੈ, shell ਪਹਿਲਾਂ ਉਸ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦਾ ਹੈ। ਇਹ ਪਾਈਪਲਾਈਨ ਬਣਾਉਂਦਾ ਹੈ, ਰੀਡਾਇਰੈਕਸ਼ਨ ਲਈ ਫਾਈਲਾਂ ਖੋਲ੍ਹਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਵੀ ਪ੍ਰੋਗਰਾਮ ਦੇ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਵੇਰੀਏਬਲਾਂ ਦਾ ਵਿਸਤਾਰ ਕਰਦਾ ਹੈ। systemd ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਨਹੀਂ ਕਰਦਾ: ਇਹ ਆਪਣੇ ਨਿਯਮਾਂ ਅਨੁਸਾਰ ExecStart ਨੂੰ ਵੰਡਦਾ ਹੈ ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ ਮਿਲੇ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਉਹਨਾਂ ਆਰਗਿਊਮੈਂਟਾਂ ਨਾਲ ਚਲਾਉਂਦਾ ਹੈ। ਇਸ ਲਈ > ਸ਼ਬਦੀ ਆਰਗਿਊਮੈਂਟ ਵਜੋਂ ਆਉਂਦਾ ਹੈ, ਅਤੇ | ਦੋ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਜੋੜਨ ਦੀ ਬਜਾਏ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਯੂਨਿਟ ਗਲਤ ਵਿਵਹਾਰ ਨਹੀਂ ਕਰ ਰਹੀ; ਵਾਕ-ਰਚਨਾ ਦਾ ਅਰਥ ਕੁਝ ਹੋਰ ਸੀ।
ਇਹ ਲਾਪਰਵਾਹੀ ਨਹੀਂ, ਜਾਣ-ਬੁੱਝ ਕੇ ਹੈ, ਕਿਉਂਕਿ ਆਰਗਿਊਮੈਂਟਾਂ ਦੀ ਅਨੁਮਾਨਿਤ ਸੰਭਾਲ ਹੀ ਯੂਨਿਟਾਂ ਨੂੰ ਆਡਿਟ-ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ। ਇਹ ਸਿਰਫ਼ ਉਹਨਾਂ ਨੂੰ ਹੈਰਾਨ ਕਰਦਾ ਹੈ ਜੋ ਮੰਨਦੇ ਹਨ ਕਿ shell ਮੌਜੂਦ ਹੈ।
ਅਜਿਹੀ ਯੂਨਿਟ ਲਿਖੋ ਜੋ ਠੀਕ-ਠੀਕ ਦੱਸੇ ਕਿ ਕੀ ਚੱਲਦਾ ਹੈ
ਛੋਟੀ ਯੂਨਿਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜਿਸ ਦਾ ਉਦੇਸ਼ ਜਰਨਲ ਵਿੱਚ ਦਿਸਦਾ ਹੈ, ਤਾਂ ਜੋ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਸੁਰੰਗ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਵੱਖ ਰਹਿਣ। ਇਹ ਸਿਰਫ਼ ਬਾਈਨਰੀ ਦਾ ਸੰਸਕਰਣ ਦੱਸਦੀ ਹੈ।
[Unit]
Description=Report the installed OpenVPN version
[Service]
Type=oneshot
ExecStart=/usr/sbin/openvpn --version
StandardOutput=journal
StandardError=journalਰਾਹ ਇੱਕ ਪਲੇਸਹੋਲਡਰ ਹੈ, ਇਸ ਲਈ ਅਸਲ ਵਿੱਚ ਇੰਸਟਾਲ ਕੀਤੀ ਬਾਈਨਰੀ ਰੱਖੋ। Type=oneshot ਅਜਿਹੀ ਕਮਾਂਡ ਲਈ ਢੁੱਕਵੀਂ ਹੈ ਜੋ ਅੰਤ ਤੱਕ ਚੱਲਦੀ ਹੈ, ਅਤੇ ਜਰਨਲ ਸੈਟਿੰਗਾਂ ਇਸ ਦਾ ਆਉਟਪੁੱਟ ਉੱਥੇ ਰੱਖਦੀਆਂ ਹਨ ਜਿੱਥੇ ਤੁਸੀਂ ਟਰਮੀਨਲ ਤੋਂ ਬਿਨਾਂ ਪੜ੍ਹ ਸਕਦੇ ਹੋ। ਜਾਣ-ਬੁੱਝ ਕੇ ਕੋਈ ਇੰਸਟਾਲ ਭਾਗ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਯੂਨਿਟ ਬੂਟ ’ਤੇ ਸਮਰੱਥ ਹੋਣ ਦੀ ਬਜਾਏ ਹੱਥ ਨਾਲ ਬੁਲਾਈ ਜਾਂਦੀ ਹੈ। ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਫਾਈਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਕਿਉਂਕਿ ਨਿਰਦੇਸ਼ ਦੇ ਨਾਮ ਵਿੱਚ ਟਾਈਪੋ ਰਾਹ ਵਿੱਚ ਟਾਈਪੋ ਨਾਲੋਂ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੁੰਦਾ ਹੈ।
systemd-analyze verify /etc/systemd/system/openvpn-version.service
systemctl start openvpn-version.serviceshell ਤਰਕ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਰੱਖੋ
ਜਦੋਂ ਸਹਾਇਕ ਨੂੰ ਸੱਚਮੁੱਚ ਸ਼ਰਤੀ ਤਰਕ ਦੀ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਉਹ ਤਰਕ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਬੁਲਾਓ। ਸਕ੍ਰਿਪਟ ਨੂੰ ਇੰਟਰਪ੍ਰੀਟਰ ਲਾਈਨ, ਚਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਅਤੇ ਅਜਿਹੇ ਐਗਜ਼ਿਟ ਕੋਡ ਚਾਹੀਦੇ ਹਨ ਜੋ ਸੇਵਾ ਦੱਸ ਸਕੇ। /bin/sh -c ਨੂੰ ਹਵਾਲਾ-ਚਿੰਨ੍ਹਾਂ ਵਾਲੀ ਕਮਾਂਡ ਨਾਲ ਚਲਾਉਣਾ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਯੂਨਿਟ ਦੇ ਅੰਦਰ ਹਵਾਲਾ ਨਿਯਮ ਲੁਕਾਉਂਦਾ ਹੈ ਅਤੇ ਸਮੀਖਿਆ ਔਖੀ ਬਣਾਉਂਦਾ ਹੈ। ਨਾਮ ਵਾਲੀ ਸਕ੍ਰਿਪਟ ਹੱਥ ਨਾਲ ਪਰਖੀ ਜਾ ਸਕਦੀ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਯੂਨਿਟ ਸੋਧੇ ਬਿਨਾਂ ਬਦਲੀ ਜਾ ਸਕਦੀ ਹੈ। ਇੰਟਰਐਕਟਿਵ ਵਰਤੋਂਕਾਰ ਦੀ shell ਪ੍ਰੋਫਾਈਲ ’ਤੇ ਨਿਰਭਰ ਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਸੇਵਾ ਆਪਣੇ ਵਾਤਾਵਰਣ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ।
ਜਦੋਂ ਸਾਪੇਖ ਰਾਹ ਮਹੱਤਵਪੂਰਨ ਹੋਣ ਤਾਂ WorkingDirectory ਸੈੱਟ ਕਰੋ, ਅਤੇ ਵਾਤਾਵਰਣ ਨੂੰ ਟਰਮੀਨਲ ਵਿੱਚ ਐਕਸਪੋਰਟ ਕਰਨ ਦੀ ਬਜਾਏ ਯੂਨਿਟ ਦੇ ਸਮਰਥਿਤ ਨਿਰਦੇਸ਼ਾਂ ਰਾਹੀਂ ਭੇਜੋ। ਭੇਦ ਸੁਰੱਖਿਅਤ ਫਾਈਲਾਂ ਜਾਂ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ, ਅਜਿਹੀਆਂ ਆਰਗਿਊਮੈਂਟ ਸੂਚੀਆਂ ਵਿੱਚ ਨਹੀਂ ਜੋ ਜਰਨਲ ਦਰਜ ਕਰ ਸਕੇ।
ਅਸਲ ਵਿੱਚ ਮੌਜੂਦ ਯੂਨਿਟ ਦੀ ਜਾਂਚ ਕਰੋ
drop-in ਫਾਈਲਾਂ ਤੁਹਾਡੇ ਸੋਧੇ ਹੋਣ ਦੀ ਯਾਦ ਵਾਲੀ ਫਾਈਲ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਵਿਵਹਾਰ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ। ਪੜ੍ਹੋ ਕਿ ਪ੍ਰਬੰਧਕ ਨੇ ਕੀ ਲੋਡ ਕੀਤਾ ਅਤੇ ਪਿਛਲੇ ਰਨ ਨੇ ਕੀ ਦੱਸਿਆ।
systemctl cat vpn-helper.service
journalctl -u vpn-helper.service -n 20 --no-pagerਯੂਨਿਟ ਡੰਪ ਲੋਡ ਕ੍ਰਮ ਵਿੱਚ drop-in ਫਾਈਲਾਂ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਣਕਿਆਸੀ ExecStart ਆਮ ਤੌਰ ’ਤੇ ਉੱਥੋਂ ਹੀ ਆਉਂਦੀ ਹੈ। ਕਿਸੇ ਵੀ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਪ੍ਰਬੰਧਕ ਰੀਲੋਡ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਨਵੀਂ ਪਰਿਭਾਸ਼ਾ systemctl cat ਵੱਲੋਂ ਪ੍ਰਿੰਟ ਕੀਤੀ ਗਈ ਚੀਜ਼ ਹੈ। ਜਰਨਲ ਸਹੀ ਕਮਾਂਡ ਲਾਈਨ ਅਤੇ ਐਗਜ਼ਿਟ ਸਥਿਤੀ ਦਿਖਾਉਂਦਾ ਹੈ, ਜੋ ਆਰਗਿਊਮੈਂਟ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਗੁੰਮ ਬਾਈਨਰੀ ਜਾਂ ਇਜਾਜ਼ਤ ਗਲਤੀ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। ਫਿਰ ਤੈਅ ਕਰੋ ਕਿ ਸਹਾਇਕ ਮੌਜੂਦਾ VPN ਜੀਵਨ-ਚੱਕਰ ਦਾ ਹਿੱਸਾ ਹੈ ਜਾਂ ਹੱਥ ਨਾਲ ਕੀਤਾ ਨਿਦਾਨ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਦੂਜੀ ਬੈਕਗ੍ਰਾਊਂਡ ਸੁਰੰਗ ਪ੍ਰਕਿਰਿਆ ਇੱਕ ਮੁਕਾਬਲੇ ਵਾਲਾ ਮਾਲਕ ਬਣਾਉਂਦੀ ਹੈ।
ਮੰਗ ’ਤੇ ਸਹੀ ਆਉਟਪੁੱਟ ਪ੍ਰਿੰਟ ਕਰਨ ਵਾਲੀ ਯੂਨਿਟ ਚੰਗਾ ਪਹਿਲਾ ਪੜਾਅ ਹੈ। ਇਹ ਹਜੇ ਸੁਰੰਗ ਨਹੀਂ, ਅਤੇ ਸੁਰੰਗ ਹੋਣ ਦਾ ਦਿਖਾਵਾ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ।