פֿאַר וואָס אַ systemd־דינסט באַקומט נישט די פּראָקסי־איינשטעלונגען פֿון אײַער שעל

אונטערזוכט דעם דינסט וואָס פֿאַלט דורכן, אַנשטאָט צו עקספּאָרטירן נאָך אַ וואַריאַבל אין טערמינאַל. systemctl cat example.service ווײַזט זײַן איינהייט און צוגאָב־קאָנפֿיגוראַציעס; זוכט אַן EnvironmentFile, אַנדערע איבערשרײַבונגען אָדער פּראָקסי־איינשטעלונגען פֿון דער אַפּליקאַציע אַליין. לייענט אויסגאַבע מיט צוטריט־דאַטן לאָקאַל.

אויב די אַפּליקאַציע ניצט סבֿיבֿה־וואַריאַבלען פֿאַר HTTP־פּראָקסי, קען אַ צוגאָב־קאָנפֿיגוראַציע פֿונעם דינסט צושטעלן:

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

בײַט אויס דעם בײַשפּיל־אַדרעס פֿון דער דאָקומענטאַציע און ניצט וואַריאַבלנעמען וואָס די אַפּליקאַציע שטיצט. פֿאַר אַ דינסט וואָס מע מעג לאָזן ניצן עפֿנטלעכע HTTP־פּראָקסיס, זײַנען מעגלעכע אַדרעסן אין דער רשימה פֿון HTTP־פּראָקסיס. אַ קליענט מיט אַן אייגענער קאָנפֿיגוראַציע קען איגנאָרירן די ווערטן. באַשטעטיקט אויך אַז דאָס איז דער געמיינטער סיסטעם־דינסט: אַ באַניצער־דינסט האָט אַן אַנדער פֿאַרוואַלטער און סבֿיבֿה; ענדערן אַ סיסטעם־איינהייט מיט אַ ענלעכן נאָמען וועט אים נישט פֿאַרריכטן.

נאָכן רעדאַקטירן די ריכטיקע איינהייט אָדער צוגאָב־קאָנפֿיגוראַציע לאָדט די דעפֿיניציעס ווידער און ריסטאַרטירט יענעם דינסט ווען זײַן אַרבעט מעג ווערן איבערגעריסן:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload אַליין פֿאַרבײַט נישט די סבֿיבֿה פֿון אַ לויפֿנדיקן פּראָצעס. אַ ריסטאַרט הייבט אָן דעם נײַעם פּראָצעס; אַן עקספּאָרט אינעם שעל ווירקט נאָר אויף יענעם שעל און די קינד־פּראָצעסן וואָס ער הייבט אָן שפּעטער.

ווען דער דינסט באַקומט דעם דערוואַרטן URL, פֿאָלגט זײַן אמתן טעות. זײַן קאָנטע קען נישט האָבן צוטריט צו דער CA־טעקע, זײַן נעץ־נאָמען־פּלאַץ קען נישט דערגרייכן דעם צוהערער, אָדער דער פּראָקסי קען אָפּוואַרפֿן די אָנפֿרעג. דאָס זײַנען שפּעטערדיקע קאָנטראָלן, נישט קיין סיבות ווײַטער צו רעדאַקטירן שעל־פּראָפֿילן אָן שײַכות צום פּראָבלעם.