Kial systemd-servo ne ricevas la prokurilajn agordojn de via ŝelo

Inspektu la malsukcesantan servon anstataŭ eksporti plian variablon en via terminalo. systemctl cat example.service montras ĝian unuon kaj aldonajn agordojn; serĉu EnvironmentFile, alian superregan agordon aŭ prokurilajn agordojn de la aplikaĵo mem. Legu eligaĵon enhavantan akreditaĵojn loke.

Se la aplikaĵo uzas mediajn variablojn por HTTP-prokurilo, aldona agordo de la servo povas liveri:

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

Anstataŭigu la dokumentan ekzempladreson kaj uzu la variablonomojn subtenatajn de la aplikaĵo. Por servo rajtigita uzi publikajn HTTP-prokurilojn, eblaj adresoj estas en la listo de HTTP-prokuriloj. Kliento kun propra agordo povas ignori ĉi tiujn enigojn. Konfirmu ankaŭ, ke temas pri la celita sistemservo: Uzantoservo havas alian administrilon kaj medion; ŝanĝi simile nomitan sistemunuon ne riparos ĝin.

Post redaktado de la ĝusta unuo aŭ aldona agordo, reŝargu la difinojn kaj restartigu tiun servon kiam ĝia laboro povas esti interrompita:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload sola ne anstataŭigas la medion de ruliĝanta procezo. Restartigo lanĉas la novan procezon; eksporto en ŝelo efikas nur al tiu ŝelo kaj la idaj procezoj, kiujn ĝi poste lanĉas.

Kiam la servo ricevas la atendatan URL-on, sekvu ĝian efektivan eraron. Ĝia konto eble ne havas aliron al la CA-dosiero, ĝia reta nomspaco eble ne atingas la aŭskultilon, aŭ la prokurilo eble rifuzas la peton. Tiuj estas postaj kontroloj, ne kialoj por plu redakti senrilatajn ŝelprofilojn.