systemctl বলছে systemd PID 1 নয়: তাহলে কী করব?

যখন systemctl start openvpn-client@office চালানো হয় আর সিস্টেমটি systemd দিয়ে বুট হয়নি — এমন বার্তা পাওয়া যায়, তখন সেটি সেবা-ব্যর্থতার মতো শোনায়। আসলে এটি কোনও সেবা-ব্যর্থতাই নয়: আপনি যে systemctl ডেকেছেন, তা কথা বলার জন্য কোনও চলমান ম্যানেজার খুঁজে পায় না, তাই OpenVPN সম্পর্কে কিছুই পরীক্ষা করা হয়নি। sudo কোনও ম্যানেজার তৈরি করে না, আর একটি unit ফাইল ইনস্টল করলেও তা তৈরি হয় না। কমান্ড আর মেশিন দুটি ভিন্ন জগৎ থেকে আসে, এবং ত্রুটিই একমাত্র জায়গা যেখানে সেটি ধরা পড়েছে।

প্রথমে জিজ্ঞেস করুন, কমান্ডটি যেখানে চলে সেখানে PID 1 কে ধরে আছে, কারণ সেই উত্তরই ঠিক করে unit আদৌ আছে কি না।

ত্রুটি OpenVPN নয়, পরিবেশের নাম বলে

systemctl একটি ক্লায়েন্ট, ম্যানেজার নয়। এটি সকেটের মাধ্যমে সিস্টেম ম্যানেজারের সঙ্গে যুক্ত হয়, আর অন্য প্রান্তে কোনও ম্যানেজার না থাকলে লোকেরা ফোরামে যে বার্তাটি পেস্ট করে সেটিই ছাপে। ps -p 1 -o pid=,comm= দেখায় আসলে কী PID 1 হিসেবে চলছে, আর উত্তরটি প্রায়শই একটি শেল, একটি init মোড়ক, বা কন্টেইনারের নিজের এন্ট্রিপয়েন্ট। সেই পরিস্থিতিতে একটি unit ফাইল পুরোপুরি বৈধ হয়েও কখনও পড়া নাও হতে পারে। কমান্ডটি root হিসেবে পুনরাবৃত্তি করলে কেবল ক্লায়েন্টের ক্রেডেনশিয়াল বদলায়।

প্রথম লাইনের আগে পুরো বার্তাটি পড়ুন। ম্যানেজারের নিজের কাছ থেকে আসা ত্রুটি, যেমন একটি অনুপস্থিত unit বা ব্যর্থ শর্ত, বোঝায় আপনি সেখানে পৌঁছেছেন; এই ত্রুটিটি বোঝায় আপনি পৌঁছাননি।

WSL: systemd চালু করা একটি কনফিগ পরিবর্তন

পরবর্তী সংস্করণগুলোতে WSL-এ systemd সমর্থন এসেছে, তবে বৈশিষ্ট্যটি প্রতিটি ডিস্ট্রিবিউশনের জন্য আলাদাভাবে চালু হয় এবং কেবল যেখানে ইনস্টল করা WSL সংস্করণ এটি সমর্থন করে সেখানেই কাজ করে। wsl --version Windows-এর দিকে দেখায় আপনার কাছে কী আছে, আর ডিস্ট্রিবিউশনের /etc/wsl.conf ফাইলে থাকে [boot] বিভাগ, যাতে রয়েছে systemd=true। ইতিমধ্যে থাকা বিভাগগুলো না ফেলে সেই ফাইলটি সম্পাদনা করুন, তারপর পরিবর্তনটি কার্যকর হতে WSL ইনস্ট্যান্সটি পুনরায় চালু করুন। wsl --shutdown চলমান প্রতিটি ডিস্ট্রিবিউশন বন্ধ করে, তাই আগে কাজ সংরক্ষণ করুন।

আবার খোলার পর OpenVPN unit-এ হাত দেওয়ার আগে ম্যানেজারটি নিশ্চিত করুন: ps -p 1 -o comm= দেখানো উচিত systemd। systemd চালু করলে কোনও প্রোফাইল, কোনও ক্রেডেনশিয়াল আর কোনও ইনস্ট্যান্সের নাম পাওয়া যায় না, তাই পরের ত্রুটিটি PID 1 নয়, এগুলোর কোনও একটি নিয়ে হবে।

কন্টেইনার তাদের এন্ট্রিপয়েন্ট চালায়, unit নয়

সাধারণ কন্টেইনার তার এন্ট্রিপয়েন্ট বা কমান্ড যা বলে সেটিই চালু করে, আর আপনি যে প্যাকেজই ইনস্টল করুন না কেন, এটি systemd-বুট করা মেশিন নয়। ইমেজে systemctl যোগ করলে এমন একটি ক্লায়েন্ট পান যার সঙ্গে সংযোগ করার কিছু নেই। Community OpenVPN-এর জন্য সমর্থিত ধরনটি সাধারণত ফোরগ্রাউন্ড প্রসেস, openvpn --config /path/to/client.conf, যা এন্ট্রিপয়েন্ট চালু করে এবং বাইরে থেকে তদারকি করা হয়। সেই মালিকই স্টার্টআপ, সিগন্যাল ও শাটডাউন সামলায়, আর টানেল পরিচালনা করা উচিত কেবল তারই।

যে এন্ট্রিপয়েন্ট ইতিমধ্যে ওই টানেল পরিচালনা করে তার পাশে কখনও ইন্টারঅ্যাকটিভ কপি চালাবেন না, কারণ দুটি প্রসেস ডিভাইস ও রুট নিয়ে লড়াই করবে। কন্টেইনারের ভেতরে ন্যূনতম একটি init প্রসেস চাইল্ড সংগ্রহ করে ও সিগন্যাল এগিয়ে দেয়; এটি ইমেজটিকে unit-সহ হোস্টে পরিণত করে না।

কোনও ডিপ্লয়মেন্ট সত্যিই কন্টেইনারের ভেতরে systemd চাইলে তার জন্য সচেতনভাবে নকশা করা ইমেজ দরকার, systemctl অভিযোগ করা বন্ধ না করা পর্যন্ত অতিরিক্ত বিশেষাধিকার যোগ করা নয়।

ম্যানেজার থাকলে পরের ত্রুটিটি পড়ুন

একটি সত্যিকারের ম্যানেজার সেবাটি চালু করলে তখনই কাজে লাগার মতো ত্রুটিগুলো শুরু হয়। ডিভাইস অনুমতির ব্যর্থতা, কনফিগ পার্সের ত্রুটি, অনুপস্থিত ক্রেডেনশিয়াল আর নাগালের বাইরে থাকা পিয়ার — এগুলো চারটি আলাদা সমস্যা, যা PID 1 বার্তা কখনও পরীক্ষা করেনি। unit যে ক্রমে এগুলো তৈরি করেছে সেই ক্রমে পড়ুন, journalctl -u openvpn-client@office -n 50 দিয়ে systemd হোস্টে, অথবা যেখানে ম্যানেজার নেই সেখানে ক্লায়েন্টটি ফোরগ্রাউন্ডে চালিয়ে। ফোরগ্রাউন্ডে চালানোই প্রোফাইলটি নিজে কাজ করে কি না তা নিশ্চিত করার দ্রুততম উপায়।

আপনার নোটে দুটি পরিবেশ আলাদা রাখুন: যে হোস্ট টানেল চালায়, আর যেখানে আপনি কমান্ড টাইপ করেন।