چرا سرویس systemd تنظیمات پراکسی پوستهٔ شما را دریافت نمی‌کند؟

به‌جای export کردن یک متغیر دیگر در پایانه، سرویس دچار خطا را بررسی کنید. 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 به‌تنهایی محیط فرایند در حال اجرا را جایگزین نمی‌کند. راه‌اندازی مجدد فرایند جدید را شروع می‌کند؛ export در پوسته فقط بر همان پوسته و فرایندهای فرزندی که بعداً راه‌اندازی می‌کند اثر دارد.

وقتی سرویس URL مورد انتظار را دریافت کرد، خطای واقعی آن را دنبال کنید. حساب آن ممکن است به فایل CA دسترسی نداشته باشد، فضای نام شبکهٔ آن شاید به شنونده نرسد یا پراکسی درخواست را رد کند. این‌ها بررسی‌های بعدی‌اند، نه دلیلی برای ادامهٔ ویرایش پروفایل‌های نامرتبط پوسته.