Γιατί μια υπηρεσία systemd δεν παίρνει τις ρυθμίσεις proxy του κελύφους σας

Εξετάστε την υπηρεσία που αποτυγχάνει αντί να εξάγετε άλλη μία μεταβλητή στο τερματικό. Το systemctl cat example.service δείχνει τη μονάδα της και τις συμπληρωματικές ρυθμίσεις· αναζητήστε ένα EnvironmentFile, άλλες παρακάμψεις ή ρυθμίσεις proxy της ίδιας της εφαρμογής. Διαβάστε τοπικά την έξοδο που περιέχει διαπιστευτήρια.

Αν η εφαρμογή χρησιμοποιεί μεταβλητές περιβάλλοντος για proxy HTTP, μια συμπληρωματική ρύθμιση της υπηρεσίας μπορεί να δώσει:

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

Αντικαταστήστε τη διεύθυνση του παραδείγματος και χρησιμοποιήστε τα ονόματα μεταβλητών που υποστηρίζει η εφαρμογή. Για υπηρεσία που επιτρέπεται να χρησιμοποιεί δημόσιους proxy HTTP, πιθανές διευθύνσεις υπάρχουν στη λίστα proxy HTTP. Ένας πελάτης με δική του διαμόρφωση μπορεί να αγνοήσει αυτές τις τιμές. Επιβεβαιώστε επίσης ότι πρόκειται για την επιθυμητή υπηρεσία συστήματος: Μια υπηρεσία χρήστη έχει διαφορετικό διαχειριστή και περιβάλλον· η αλλαγή μιας μονάδας συστήματος με παρόμοιο όνομα δεν θα τη διορθώσει.

Αφού επεξεργαστείτε τη σωστή μονάδα ή συμπληρωματική ρύθμιση, επαναφορτώστε τους ορισμούς και επανεκκινήστε την υπηρεσία όταν επιτρέπεται να διακοπεί η εργασία της:

sudo systemctl daemon-reload
sudo systemctl restart example.service

Το daemon-reload από μόνο του δεν αντικαθιστά το περιβάλλον μιας διεργασίας που εκτελείται. Η επανεκκίνηση ξεκινά τη νέα διεργασία· ένα export στο κέλυφος επηρεάζει μόνο εκείνο το κέλυφος και τις θυγατρικές διεργασίες που ξεκινά στη συνέχεια.

Μόλις η υπηρεσία λάβει το αναμενόμενο URL, ακολουθήστε το πραγματικό σφάλμα της. Ο λογαριασμός της μπορεί να μην έχει πρόσβαση στο αρχείο CA, ο χώρος ονομάτων δικτύου της μπορεί να μη φτάνει στο σημείο ακρόασης ή ο proxy μπορεί να απορρίπτει το αίτημα. Αυτοί είναι επόμενοι έλεγχοι, όχι λόγοι να συνεχίζετε να επεξεργάζεστε άσχετα προφίλ κελύφους.