Waarom ’n systemd-diens nie jou dop se instaanbedienerinstellings kry nie

Ondersoek die diens wat misluk eerder as om nog ’n veranderlike in jou terminaal uit te voer. systemctl cat example.service wys sy eenheid en aanvullende konfigurasielêers; kyk vir ’n EnvironmentFile, ’n ander oorheersing of die toepassing se eie instaanbedienerinstellings. Lees uitvoer wat aanmeldbesonderhede bevat plaaslik.

As die toepassing HTTP-instaanbedieneromgewingsveranderlikes gebruik, kan ’n aanvullende dienskonfigurasie die volgende verskaf:

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

Vervang die dokumentasie-eindpunt en gebruik veranderlikename wat die toepassing ondersteun. Vir ’n diens wat openbare HTTP-instaanbedieners mag gebruik, is moontlike adresse in die HTTP-instaanbedienerlys. ’n Kliënt met eie konfigurasie kan hierdie insette ignoreer. Bevestig ook dat dit die bedoelde stelseldiens is: ’n gebruikersdiens het ’n ander bestuurder en omgewing; die wysiging van ’n soortgelyk benoemde stelseleenheid sal dit nie regstel nie.

Nadat jy die bedoelde eenheid of aanvullende konfigurasie gewysig het, herlaai die definisies en herbegin daardie diens wanneer sy werklading onderbreek mag word:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload alleen vervang nie ’n lopende proses se omgewing nie. Herbegin begin die nuwe proses; ’n dopuitvoer beïnvloed slegs daardie dop en die kindprosesse wat dit daarna begin.

Sodra die diens die verwagte URL ontvang, volg sy werklike fout. Sy rekening het dalk geen toegang tot die CA-lêer nie, sy netwerknaamruimte kan dalk nie die luisterdiens bereik nie, of die instaanbediener kan die versoek weier. Dit is latere kontroles, nie redes om onverwante dopprofiele verder te wysig nie.