Pse një shërbim systemd nuk merr cilësimet proxy të shell-it tuaj

Inspektoni shërbimin që dështon në vend që të eksportoni një ndryshore tjetër në terminal. systemctl cat example.service tregon njësinë dhe konfigurimet plotësuese të tij; kërkoni një EnvironmentFile, një mbivendosje tjetër ose cilësimet proxy të vetë aplikacionit. Lexojeni lokalisht daljen që përmban kredenciale.

Nëse aplikacioni përdor ndryshore mjedisi për proxy HTTP, një konfigurim plotësues i shërbimit mund të japë:

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

Zëvendësoni adresën e shembullit dhe përdorni emrat e ndryshoreve që mbështet aplikacioni. Për një shërbim që lejohet të përdorë proxy HTTP publikë, adresa të mundshme gjenden në listën e proxy-ve HTTP. Një klient me konfigurim të vetin mund t’i shpërfillë këto vlera. Konfirmoni edhe që ky është shërbimi i synuar i sistemit: Një shërbim përdoruesi ka menaxhues dhe mjedis tjetër; ndryshimi i një njësie sistemi me emër të ngjashëm nuk do ta rregullojë.

Pas redaktimit të njësisë ose konfigurimit plotësues të duhur, ringarkoni përkufizimet dhe rinisni atë shërbim kur puna e tij mund të ndërpritet:

sudo systemctl daemon-reload
sudo systemctl restart example.service

Vetëm daemon-reload nuk zëvendëson mjedisin e një procesi në punë. Rinisja nis procesin e ri; një eksport në shell ndikon vetëm te ai shell dhe proceset bijë që ai nis më pas.

Pasi shërbimi merr URL-në e pritur, ndiqni gabimin e tij real. Llogaria e tij mund të mos ketë qasje te skedari CA, hapësira e tij e emrave të rrjetit mund të mos arrijë dëgjuesin ose proxy mund të refuzojë kërkesën. Këto janë kontrolle të mëvonshme, jo arsye për të vazhduar redaktimin e profileve të palidhura të shell-it.