apt purge نے VPN ہٹا دیا، پھر بھی سروس بوٹ پر شروع ہوتی ہے

apt purge کہتا ہے کہ پیکیج چلا گیا، پھر بھی ہر آغاز پر ایک سرنگ دوبارہ اٹھتی ہے۔ journal بڑھتا رہتا ہے، راستے واپس آتے ہیں، اور مشین ایسے برتاؤ کرتی ہے جیسے کچھ ہٹایا ہی نہ گیا ہو۔ وینڈر کا انسٹالر ایسی فائلیں لکھ سکتا ہے جو پیکیج منتظم نے کبھی درج نہیں کیں، اس لیے پیکیج ہٹانا اور مصنوع ہٹانا دو الگ کام ہیں۔ نیچے دیا گیا runbook دونوں ریکارڈ الگ کرتا ہے اور ہٹانے کا کام جان بوجھ کر مکمل کرتا ہے۔

دو انسٹالر، دو الگ ریکارڈ

Debian پیکیجز فائلوں کی فہرست رکھتے ہیں، اور purge ٹھیک وہی مٹاتا ہے جو وہ فہرست نام دیتی ہے، نیز پیکیج کی ترتیب۔ shell انسٹالر یا .run بنڈل ایسی فہرست نہیں رکھتا؛ وہ جہاں چاہے لکھتا ہے، عام طور پر /opt، /usr/local اور /etc/systemd/system میں۔ ان میں سے کوئی راستہ کسی پیکیج کی فائل فہرست میں نظر نہیں آتا، اس لیے dpkg نہ انہیں جانتا ہے نہ رپورٹ کرتا ہے۔ آخر میں ایک ہی فائل سسٹم پر انسٹالیشن کے دو مالک ہوتے ہیں، اور ان میں سے صرف ایک حساب رکھتا ہے۔

مٹانے سے پہلے اس مخصوص راستے کے بارے میں dpkg سے پوچھیں۔ جو راستہ وہ مسترد کرتا ہے وہ آپ کے ہٹانے کا ہے، اور وہی جواب بتاتا ہے کہ بعد کی اپ گریڈ اسے واپس لائے گی یا نہیں۔

dpkg -S /etc/systemd/system/acmevpn.service
systemctl list-unit-files | grep -i acmevpn

unit اور اس کا wants لنک الگ فائلیں ہیں

فعال کرنا نصب کرنے سے الگ عمل ہے۔ unit اپنے [Install] حصے میں ہدف تعلقات کا اعلان کرتا ہے، اور systemctl enable ان اعلانات کو ہر ہدف کی .wants/ ڈائریکٹری میں علامتی لنک بناتا ہے۔ اب دو راستے ہیں: unit فائل، اور وہ لنک جو اسے بوٹ ہدف میں کھینچتا ہے۔ صرف فائل مٹائیں تو لنک کہیں اشارہ نہیں کرتا، جس سے بوٹ پر شکایت پیدا ہوتی ہے؛ صرف لنک مٹائیں تو unit نام سے چلنے کے قابل رہتا ہے۔ دونوں کو جانا ہے۔

انہیں ترتیب سے ہٹائیں اور پھر دوبارہ لوڈ کریں، تاکہ systemd پرانی تعریفیں یادداشت میں رکھنا بند کرے۔

systemctl disable --now acmevpn.service
systemctl show -p FragmentPath -p ExecStart acmevpn.service
sudo rm /etc/systemd/system/acmevpn.service
sudo rm /etc/systemd/system/multi-user.target.wants/acmevpn.service
systemctl daemon-reload

مقام کا اندازہ لگانے کے بجائے FragmentPath پڑھیں، کیونکہ وینڈر نے /etc کی بجائے /usr/lib/systemd/system یا /lib/systemd/system میں لکھا ہو سکتا ہے۔ متوقع نقل مٹانے سے مؤثر نقل چلتی رہتی ہے، اور اگلی دوبارہ لوڈنگ تک درستی کامیاب لگتی ہے۔ لوڈنگ ختم ہونے پر unit فائلیں دوبارہ فہرست کریں اور تصدیق کریں کہ نام اب نظر نہیں آتا۔

وہ بائنری تلاش کریں جو یہ ترتیب زندہ رکھتی ہے

فعال unit پیکیج ڈیٹا بیس کو جو بھی لگے، ڈیمن شروع کرتا رہتا ہے۔ وہ عمل سرنگ واپس لا سکتا ہے، راستے دوبارہ شامل کر سکتا ہے یا kill-switch قاعدہ بحال کر سکتا ہے، اور ترتیب دیکھنے تک برتاؤ مافوق الفطرت لگتا ہے۔ ExecStart راستے کی پیروی کریں اور دیکھیں کہ بائنری اب بھی وہیں ہے، کیونکہ /opt کے نیچے چھوڑی گئی قابل عمل فائل ہی اس ترتیب کی پوری ضرورت ہے۔ unit مٹانے سے مقررہ آغاز رک جاتا ہے؛ یہ پروگرام نہیں مٹاتا۔

حالت کی ڈائریکٹریوں کے ساتھ بھی وہی احتیاط رکھیں۔ اکاؤنٹ ٹوکن، بنائے گئے پروفائل اور محفوظ شدہ سرور فہرستیں /var/lib کے نیچے یا گھریلو ڈائریکٹری میں رہتی ہیں، اور یہ اسناد ہیں، پھینکنے والا کیش نہیں۔ سروس بند ہونے کے بعد انہیں جان بوجھ کر ہٹائیں اور لکھیں کہ کیا لیا۔

sudo ls -l /opt/acmevpn /usr/local/bin/acmevpn
sudo find /var/lib -maxdepth 2 -iname "*acme*"
systemctl is-enabled acmevpn.service

بوٹ کا ایک مالک منتخب کریں اور آزمائیں

تین امیدوار بوٹ پر دعویٰ کر سکتے ہیں، اور تینوں نصب کرنا دوہری حفاظت کے بجائے دوڑ پیدا کرتا ہے۔ ڈیسک ٹاپ آٹو اسٹارٹ فائل کسی کے سائن ان کرنے کے بعد ہی چلتی ہے، systemd unit پہلے چلتا ہے مگر اسکرین کے بغیر چلنے والا کلائنٹ چاہیے، اور cron @reboot اندراج ایسے شیڈول پر چلتا ہے جو نیٹ ورک کلائنٹ کے لیے غلط ہو سکتا ہے۔ وینڈر کی CLI اضافی طور پر سرور دلیل مانگ سکتی ہے، کیونکہ بوٹ پر جاری رکھنے کے لیے پچھلا سیشن نہیں ہوتا۔ وہ امیدوار چنیں جو کلائنٹ کی تصدیق کے طریقے سے میل کھاتا ہے، اور باقی چھوڑ دیں۔

مشین دوبارہ بوٹ کر کے اور تین آزاد حقائق دیکھ کر آزمائیں: unit کی حالت، عمل کی فہرست، اور کسی قابل تصدیق چیز سے نیا رابطہ۔ جس کلائنٹ کو کی رنگ یا متعامل لاگ ان چاہیے وہ درست unit فائل کے باوجود بوٹ پر ناکام ہوتا ہے، اور صرف سروس کی حالت کے بجائے journal پڑھیں تو وہ ایسا کہتا ہے۔

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

لکھیں کہ اگلے purge کو کیا توقع رکھنی چاہیے

کسی بھی دستی ہٹانے کے بعد دو حقائق درج کریں: کس انسٹالر نے یہ ترتیب بنائی، اور اب کون مالک اسے شروع کرتا ہے۔ وہ نوٹ اگلے purge کو حیرت سے چیک لسٹ کی ایک شے بنا دیتا ہے، اور کام کرنے والے شخص سے زیادہ عرصہ رہتا ہے۔

اسے ذاتی ڈائریکٹری میں نہیں بلکہ سروس کی ترتیب کے پاس رکھیں اور تاریخ لگائیں، کیونکہ وینڈر کی اپ ڈیٹ آپ کا مٹایا ہوا unit بحال کر سکتی ہے۔ ہر چند ماہ بعد systemctl list-unit-files کا اس نوٹ سے موازنہ بحالی کو اس وقت پکڑتا ہے جب درستی اب بھی سستی ہے۔