systemd ਸੇਵਾ ਨੂੰ ਤੁਹਾਡੇ ਸ਼ੈੱਲ ਦੀਆਂ ਪ੍ਰੌਕਸੀ ਸੈਟਿੰਗਾਂ ਕਿਉਂ ਨਹੀਂ ਮਿਲਦੀਆਂ

ਟਰਮੀਨਲ ਵਿੱਚ ਇੱਕ ਹੋਰ ਵੇਰੀਏਬਲ ਐਕਸਪੋਰਟ ਕਰਨ ਦੀ ਥਾਂ ਫੇਲ੍ਹ ਹੋ ਰਹੀ ਸੇਵਾ ਦੀ ਜਾਂਚ ਕਰੋ। systemctl cat example.service ਉਸ ਦੀ ਯੂਨਿਟ ਅਤੇ ਵਾਧੂ ਸੰਰਚਨਾਵਾਂ ਦਿਖਾਉਂਦਾ ਹੈ; EnvironmentFile, ਕੋਈ ਹੋਰ ਓਵਰਰਾਈਡ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਦੀਆਂ ਆਪਣੀਆਂ ਪ੍ਰੌਕਸੀ ਸੈਟਿੰਗਾਂ ਲੱਭੋ। ਲੌਗਇਨ ਜਾਣਕਾਰੀ ਵਾਲਾ ਆਉਟਪੁੱਟ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਪੜ੍ਹੋ।

ਜੇ ਐਪਲੀਕੇਸ਼ਨ HTTP ਪ੍ਰੌਕਸੀ ਦੇ ਵਾਤਾਵਰਨ ਵੇਰੀਏਬਲ ਵਰਤਦੀ ਹੈ ਤਾਂ ਸੇਵਾ ਦੀ ਵਾਧੂ ਸੰਰਚਨਾ ਇਹ ਦੇ ਸਕਦੀ ਹੈ:

[Service]
Environment="HTTP_PROXY=http://203.0.113.10:8080"
Environment="HTTPS_PROXY=http://203.0.113.10:8080"

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

ਲੋੜੀਂਦੀ ਯੂਨਿਟ ਜਾਂ ਵਾਧੂ ਸੰਰਚਨਾ ਸੋਧਣ ਤੋਂ ਬਾਅਦ ਪਰਿਭਾਸ਼ਾਵਾਂ ਮੁੜ ਲੋਡ ਕਰੋ ਅਤੇ ਕੰਮ ਰੋਕਿਆ ਜਾ ਸਕਣ ਵੇਲੇ ਉਸ ਸੇਵਾ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰੋ:

sudo systemctl daemon-reload
sudo systemctl restart example.service

ਸਿਰਫ਼ daemon-reload ਚੱਲਦੇ ਪ੍ਰੋਸੈਸ ਦਾ ਵਾਤਾਵਰਨ ਨਹੀਂ ਬਦਲਦਾ। ਮੁੜ ਚਾਲੂ ਕਰਨ ਨਾਲ ਨਵਾਂ ਪ੍ਰੋਸੈਸ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ; ਸ਼ੈੱਲ ਵਿੱਚ export ਦਾ ਅਸਰ ਸਿਰਫ਼ ਉਸ ਸ਼ੈੱਲ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਉਸ ਵੱਲੋਂ ਸ਼ੁਰੂ ਕੀਤੇ ਚਾਈਲਡ ਪ੍ਰੋਸੈਸਾਂ ਉੱਤੇ ਪੈਂਦਾ ਹੈ।

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