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 চলমান প্রসেসের পরিবেশ বদলায় না। পুনরায় চালু করলে নতুন প্রসেস শুরু হয়; শেলে export প্রভাব ফেলে শুধু সেই শেল এবং পরে সেটি যে চাইল্ড প্রসেস চালু করে সেগুলোর ওপর।

পরিষেবা প্রত্যাশিত URL পাওয়ার পর তার প্রকৃত ত্রুটি অনুসরণ করুন। তার অ্যাকাউন্টের CA ফাইলে প্রবেশাধিকার নাও থাকতে পারে, তার নেটওয়ার্ক নেমস্পেস লিসনারে পৌঁছাতে না-ও পারে বা প্রক্সি রিকোয়েস্ট প্রত্যাখ্যান করতে পারে। এগুলো পরবর্তী পরীক্ষা, সম্পর্কহীন শেল প্রোফাইল সম্পাদনা করে যাওয়ার কারণ নয়।