systemctl کہتا ہے کہ systemd PID 1 نہیں: پھر کیا؟

جب systemctl start openvpn-client@office چلایا جاتا ہے اور یہ پیغام ملتا ہے کہ نظام systemd کے ساتھ بوٹ نہیں ہوا، تو یہ سروس کی ناکامی جیسا لگتا ہے۔ یہ سروس کی ناکامی ہرگز نہیں: آپ نے جس systemctl کو پکارا، اسے بات کرنے کے لیے کوئی چلتا ہوا منتظم نہیں ملتا، اس لیے OpenVPN کے بارے میں کچھ بھی جانچا نہیں گیا۔ sudo منتظم نہیں بناتا، اور unit فائل نصب کرنے سے بھی وہ نہیں بنتا۔ حکم اور مشین دو مختلف جہانوں سے آتے ہیں، اور خرابی ہی واحد جگہ ہے جہاں یہ ظاہر ہوا۔

پہلے پوچھیں کہ حکم جہاں چلتا ہے وہاں PID 1 کس عمل کے پاس ہے، کیونکہ یہی جواب طے کرتا ہے کہ unit ہیں بھی یا نہیں۔

خرابی OpenVPN نہیں، ماحول کا نام لیتی ہے

systemctl ایک کلائنٹ ہے، منتظم نہیں۔ یہ socket کے ذریعے نظام کے منتظم سے جڑتا ہے، اور جب دوسرے سرے پر کوئی منتظم نہ ہو تو وہی پیغام چھاپتا ہے جو لوگ فورموں میں چسپاں کرتے ہیں۔ ps -p 1 -o pid=,comm= دکھاتا ہے کہ واقعی PID 1 کے طور پر کیا چل رہا ہے، اور جواب اکثر shell، 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 ہوسٹ پر، یا جہاں منتظم نہیں وہاں کلائنٹ کو سامنے چلا کر۔ سامنے چلانا پروفائل کے خود کام کرنے کی تصدیق کا تیز ترین طریقہ بھی ہے۔

اپنے نوٹوں میں دونوں ماحول الگ رکھیں: سرنگ چلانے والا ہوسٹ، اور وہ جگہ جہاں آپ احکام ٹائپ کرتے ہیں۔