کوئی چیز مسلسل OpenVPN یونٹ شروع کر رہی ہے: ماخذ تلاش کریں

OpenVPN کی مثال بوٹ کے وقت ایسے نام سے آتی ہے جو آپ نہیں پہچانتے، اور اسے روکنا اگلی ری بوٹ تک کام کرتا ہے۔ یہ نمونہ بتاتا ہے کہ آپ نے عمل ہٹا دیا ہے مگر فعالیت نہیں۔ یہ دو مختلف اشیاء ہیں، اور ان میں سے صرف ایک اسٹیٹ اسکرین پر نظر آتی ہے۔ فعالیت تلاش کرنے کے لیے چار صرف پڑھنے والے کمانڈ اور ایک فیصلہ درکار ہے۔

پہلے اصل یونٹ کا نام لیں

پروفائل فائل کے نام کی بجائے journal میں یونٹ کے نام سے شروع کریں۔ مثال openvpn@، openvpn-client@، openvpn-server@ یا تقسیم سے مخصوص کوئی چیز کہلا سکتی ہے، اور نام کا اندازہ لگانا آپ کو غلط سانچے تک لے جاتا ہے۔ اسٹیٹ آؤٹ پٹ اسی یونٹ کا نام لیتی ہے جو واقعی چلا، اور یہاں صرف یہی نام اہم ہے۔ اسے بالکل ویسا ہی نقل کریں، بشمول کوئی لاحقہ۔

درج ذیل کمانڈز اس یونٹ کو کچھ بدلے بغیر بیان کرتے ہیں۔ systemctl show فریگمنٹ کا راستہ، ماخذ کا راستہ، یونٹ فائل کی حالت، کوئی بھی drop-in اور اسے کس نے فعال کیا، بتاتا ہے۔ list-dependencies --reverse دکھاتا ہے کہ کون سے لوڈ شدہ یونٹ اس کی طرف اشارہ کرتے ہیں۔ دونوں صرف پڑھنے کے لیے ہیں، لہٰذا نظریہ بنانے سے پہلے انہیں چلائیں۔

مشاہدہ شدہ نام کو ہر جگہ بدلیں۔ نقل شدہ مثالی نام غلط سروس کی تحقیق کا سب سے عام طریقہ ہے، اور یہ ایسے یونٹ کے بارے میں پراعتماد جوابات دیتا ہے جو کبھی نہیں چلا۔

فائل کا نام جاننے کے لیے سانچہ پڑھیں

مثال کا یونٹ سانچے کی توسیع ہے، اور سانچہ طے کرتا ہے کون سی کنفیگریشن فائل پڑھی جاتی ہے۔ مثال کے لیے مخصوص پلیس ہولڈر پر ختم ہونے والی کمانڈ لائن مثال کے نام اور لاحقے میں حل ہوتی ہے۔ اگر لاحقہ .conf ہو اور مثال کا نام old ہو، تو فائل old.conf ہے۔ اگر مثال کا نام old.conf رکھیں، تو وہی سانچہ old.conf.conf مانگے گا۔

یہ تفصیل نقلوں کی ایک قسم کی وضاحت کرتی ہے۔ کوئی غلط نام کے تحت دوسری مثال شامل کرتا ہے، پہلی چلتی رہتی ہے، اور میزبان دو ٹنل اور ایک الجھا ہوا لاگ لے کر رہ جاتا ہے۔

موثر سانچہ پڑھیں، نہ کہ وہ فائل جو آپ کو یاد ہے کہ آپ نے ترمیم کی۔ drop-in کمانڈ لائن بدل سکتا ہے، اور بوٹ کے وقت وہی متبادل چلتا ہے۔

سراغ لگائیں کہ یہ بوٹ ٹرانزیکشن میں کیسے داخل ہوتا ہے

تین راستے عام ہیں: ہدف سے wants ربط، دوسرے یونٹ سے تقاضا، یا پیکیج جنریٹر کا بنایا ہوا یونٹ۔ معکوس انحصارات کی فہرست پہلے دو کو لوڈ شدہ گراف اندراجات کے طور پر ڈھانپتی ہے۔ یہ ٹائمر، ہک یا بیرونی درخواست کو نہیں ڈھانپتی، اسی لیے فہرست مکمل آڈٹ نہیں بلکہ ثبوت ہے۔

/run/systemd/generator کے تحت پیدا شدہ آؤٹ پٹ مصنوع ہے، ماخذ نہیں۔ اس میں ترمیم صرف اگلی تخلیق تک رہتی ہے، اسی لیے وہاں لگائی گئی اصلاح کامیاب دکھتی ہے اور پھر واپس آ جاتی ہے۔

جنریٹر کہاں سے پڑھتا ہے یہ فرض کرنے سے پہلے پیکیج کے دستاویزی ان پٹ کی جانچ کریں۔ ڈائریکٹری کی غیر دستاویزی اسکیننگ ہی عام وجہ ہے کہ یونٹ فعالیت کے ربط کے بغیر نمودار ہوتا ہے۔

فعالیت ہٹائیں، صرف عمل نہیں

اگر مثال براہ راست فعال ہے اور واقعی متروک ہے، تو systemctl disable --now اسے روکتا ہے اور بوٹ ربط ایک ہی قدم میں ہٹا دیتا ہے۔ پہلے جانچیں کہ یہ ٹنل میزبان تک آپ کا واحد انتظامی راستہ نہیں۔ کمانڈ زندگی کے دورانیے کی مثال ہے، مشین پر ہر VPN روکنے کی تجویز نہیں۔ جانچ کمانڈ سے پہلے کریں، بعد میں نہیں۔

دونوں نصف الگ ہو سکتے ہیں اور اکثر الجھ جاتے ہیں۔ غیر فعال کرنا چلتی سروس کو نہیں روکتا، اور روکنا فعالیت نہیں ہٹاتا، لہٰذا جزوی کمانڈ ایسے مسئلے کی وضاحت کرتی ہے جو بوٹ پر واپس آتا ہے۔

غیر فعال یونٹ پھر بھی دوسرے یونٹ یا واضح درخواست سے شروع ہو سکتا ہے۔ جب جنریٹر فعالیت کا مالک ہو، تو اس کے آؤٹ پٹ کو غیر فعال کرنے کی بجائے اس کے ان پٹ کو درست کریں۔ چھپانا زیادہ راستے بند کرتا ہے مگر انحصارات توڑ سکتا ہے، لہٰذا یہ سمجھ کی جگہ نہیں لیتا۔

دوبارہ بوٹ سے تصدیق کریں، اسٹیٹ اسکرین سے نہیں

اگر یونٹ تعریفیں یا جنریٹر ان پٹ بدلے ہوں تو systemd دوبارہ لوڈ کریں، پھر نتیجے کی حالت کا معائنہ کریں۔ ڈیمن کا دوبارہ لوڈ چلتی ٹنل میں نیا پروفائل نہیں دھکیلتا، لہٰذا دونوں جانچیں الگ ہیں۔ ری بوٹ شیڈول کریں اور تصدیق کریں کہ مثال غائب رہتی ہے جبکہ مطلوبہ ٹنل اب بھی کام کرتی ہے۔

پرانا پروفائل اس وقت تک رکھیں جب تک اس کی ملکیت سمجھ نہ آ جائے، پھر اسے مطلوبہ عمل سے ریٹائر کریں۔ کامیابی ایک غائب یونٹ اور کام کرنے والا رسائی راستہ ہے، نہ کہ ایک ناکام یونٹ جو ایک اسکرین سے غائب ہو۔