Mengapa Perkhidmatan systemd Tidak Menerima Tetapan Proksi Shell Anda

Periksa perkhidmatan yang gagal dan bukannya mengeksport satu lagi pemboleh ubah dalam terminal. systemctl cat example.service menunjukkan unit dan konfigurasi tambahannya; cari EnvironmentFile, pengatasan lain atau tetapan proksi milik aplikasi sendiri. Baca output yang mengandungi kelayakan log masuk secara setempat.

Jika aplikasi menggunakan pemboleh ubah persekitaran proksi HTTP, konfigurasi tambahan perkhidmatan boleh membekalkan:

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

Gantikan titik akhir contoh dokumentasi dan gunakan nama pemboleh ubah yang disokong aplikasi. Bagi perkhidmatan yang dibenarkan menggunakan proksi HTTP awam, alamat calon terdapat dalam senarai proksi HTTP. Klien dengan konfigurasi sendiri boleh mengabaikan input ini. Sahkan juga bahawa ini perkhidmatan sistem yang dimaksudkan: Perkhidmatan pengguna mempunyai pengurus dan persekitaran berbeza; mengubah unit sistem dengan nama serupa tidak akan membaikinya.

Selepas menyunting unit atau konfigurasi tambahan yang betul, muat semula definisi dan mulakan semula perkhidmatan itu apabila kerjanya boleh diganggu:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload sahaja tidak menggantikan persekitaran proses yang sedang berjalan. Memulakan semula akan menjalankan proses baharu; export dalam shell mempengaruhi hanya shell tersebut dan proses anak yang dilancarkannya selepas itu.

Apabila perkhidmatan menerima URL yang dijangka, ikuti ralat sebenar. Akaunnya mungkin tidak mempunyai akses kepada fail CA, ruang nama rangkaiannya mungkin tidak dapat mencapai pendengar atau proksi mungkin menolak permintaan. Itu pemeriksaan seterusnya, bukan alasan untuk terus menyunting profil shell yang tidak berkaitan.