Af hverju systemd-þjónusta fær ekki milliþjónsstillingar skeljarinnar

Skoðaðu þjónustuna sem bregst í stað þess að flytja út enn eina breytu í útstöðinni. systemctl cat example.service sýnir einingu hennar og viðbótarstillingar; leitaðu að EnvironmentFile, öðrum yfirskriftum eða eigin milliþjónsstillingum forritsins. Lestu úttak sem inniheldur aðgangsupplýsingar staðbundið.

Ef forritið notar umhverfisbreytur fyrir HTTP-milliþjón getur viðbótarstilling þjónustunnar gefið:

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

Skiptu út dæmisendapunktinum og notaðu breytuheitin sem forritið styður. Fyrir þjónustu sem má nota opinbera HTTP-milliþjóna eru möguleg vistföng á HTTP-milliþjónalistanum. Biðlari með eigin stillingar getur hunsað þessi gildi. Staðfestu líka að þetta sé rétt kerfisþjónusta: Notandaþjónusta hefur annan stjórnanda og annað umhverfi; breyting á kerfiseiningu með svipuðu heiti lagar hana ekki.

Eftir að réttri einingu eða viðbótarstillingu hefur verið breytt skaltu endurhlaða skilgreiningarnar og endurræsa þjónustuna þegar rjúfa má vinnu hennar:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload eitt og sér skiptir ekki út umhverfi keyrandi ferlis. Endurræsing ræsir nýja ferlið; útflutningur breytu í skel hefur áhrif aðeins á þá skel og afkomendaferlin sem hún ræsir síðar.

Þegar þjónustan fær rétta URL-slóð skaltu fylgja raunverulegu villunni. Reikningur hennar gæti ekki haft aðgang að CA-skránni, netnafnrýmið gæti ekki náð hlustaranum eða milliþjónninn hafnað beiðninni. Þetta eru síðari athuganir, ekki ástæður til að halda áfram að breyta ótengdum skeljarsniðum.