Bir systemd hizmeti kabuğunuzun proxy ayarlarını neden almaz?
Proxy yapılandırmasını systemd hizmetinin gerçek ortamına koyun; terminaldeki bir export çalışan süreci yeniden yapılandırmaz.
Terminalde bir değişken daha dışa aktarmak yerine hata veren hizmeti inceleyin. systemctl cat example.service birimini ve ek yapılandırmalarını gösterir; bir EnvironmentFile, başka geçersiz kılmalar veya uygulamanın kendi proxy ayarları olup olmadığına bakın. Kimlik bilgileri içeren çıktıları yerel olarak okuyun.
Uygulama HTTP proxy ortam değişkenlerini kullanıyorsa, hizmetin ek yapılandırması şunları sağlayabilir:
[Service]
Environment="HTTP_PROXY=http://203.0.113.10:8080"
Environment="HTTPS_PROXY=http://203.0.113.10:8080"Belge örneğindeki uç noktayı değiştirin ve uygulamanın desteklediği değişken adlarını kullanın. Genel HTTP proxylerini kullanmasına izin verilen bir hizmet için aday adresler HTTP proxy listesinde bulunur. Kendi yapılandırması olan bir istemci bu girdileri yok sayabilir. Ayrıca bunun amaçlanan sistem hizmeti olduğunu doğrulayın: Kullanıcı hizmetinin yöneticisi ve ortamı farklıdır; benzer adlı bir sistem birimini değiştirmek onu düzeltmez.
Doğru birimi veya ek yapılandırmayı düzenledikten sonra tanımları yeniden yükleyin ve iş yükü kesintiye uğratılabildiğinde o hizmeti yeniden başlatın:
sudo systemctl daemon-reload
sudo systemctl restart example.servicedaemon-reload tek başına çalışan sürecin ortamını değiştirmez. Yeniden başlatma yeni süreci başlatır; kabuktaki bir export yalnızca o kabuğu ve daha sonra başlattığı alt süreçleri etkiler.
Hizmet beklenen URL'yi aldıktan sonra gerçek hatasını izleyin. Hesabının CA dosyasına erişimi olmayabilir, ağ ad alanı dinleyiciye ulaşamayabilir veya proxy isteği reddedebilir. Bunlar sonraki denetimlerdir; ilgisiz kabuk profillerini düzenlemeyi sürdürmek için gerekçe değildir.