VPN واچ ڈاگ لاگ کو لکھنے والے کو توڑے بغیر گھمائیں

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

گردش کی پالیسی سے پہلے منزل منتخب کریں

جو systemd اکائی پہلے ہی اپنا آؤٹ پٹ جرنل کو بھیجتی ہے وہ برقراری کو ایک ہی جگہ رکھتی ہے۔ journald SystemMaxUse اور MaxRetentionSec جیسی حدیں نافذ کرتا ہے، اس لیے وہاں لاگ کرنے والا واچ ڈاگ بغیر کسی اضافی کام کے حد حاصل کر لیتا ہے۔ اس کے ساتھ دوسری غیر محدود فائل شامل کرنا بغیر فائدے کے دیکھ بھال کو دگنا کر دیتا ہے۔

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

حصہ لکھنے والے کے مطابق لکھیں

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

/var/log/vpn-watchdog.log {
    daily
    rotate 7
    create 0600 root root
    missingok
    notifempty
}

logrotate کی کتابچہ گنتی کو رکھے گئے گھمائے گئے ورژنوں کی تعداد کے طور پر بیان کرتی ہے، سات دن کی تاریخ کی ضمانت کے طور پر نہیں، اور daily کا لفظ کام چلنے کے وقت جانچا جاتا ہے، خود شیڈیولر کے طور پر کام کرنے کی بجائے۔ بیشتر تقسیموں میں systemd ٹائمر یا cron اندراج پہلے ہی اس کال کا مالک ہے، اس لیے دوسرا شامل کرنے سے پہلے دیکھیں کہ کون سا موجود ہے۔ ملکیت کا میل کھانا برقراری کی تعداد سے زیادہ اہم ہے۔ صرف root کے لیے موڈ کو سروس اکاؤنٹ کی لکھی فائل پر کاپی کرنا اگلی گردش پر لاگنگ روک دیتا ہے، اور ناکامی گھنٹوں بعد غلطی کے طور پر نہیں بلکہ پرانی ٹائم اسٹیمپ کے طور پر ظاہر ہوتی ہے۔ کہیں اور سے حصہ کاپی کرنے سے پہلے لکھنے والے کے صارف کی تصدیق کریں۔

جو لکھنے والا کبھی دوبارہ نہیں کھولتا اسے دوسرا علاج چاہیے

طویل مدت تک چلنے والا عمل جو کھلا وضاحتی رکھتا ہے نام بدلی گئی inode میں لکھتا رہتا ہے۔ جگہ خالی نہیں ہوتی اور نظر آنے والی فائل بڑھنا بند کر دیتی ہے، جو inode جانچنے تک ٹوٹی گردش جیسی لگتی ہے۔ یا تو عمل کو دوبارہ کھولنا سکھائیں، یا گردش کو نام بدلنے کی بجائے کاپی اور کاٹنے دیں۔

دوبارہ کھولنے کا راستہ وہاں زیادہ صاف ہے جہاں سافٹ ویئر اس کی تائید کرتا ہے: دستاویزی سگنل بھیجیں یا دستاویزی کمانڈ چلائیں، اور عمل کو نئی فائل خود کھولنے دیں۔ متبادل copytruncate ہے، جو مواد کو گھمائے گئے نام پر کاپی کرتا ہے اور پھر اصل کو اسی جگہ کاٹ دیتا ہے، اس لیے وضاحتی درست رہتا ہے مگر کاپی اور کٹائی کے درمیان پڑنے والی تحریر ضائع ہو جاتی ہے۔

systemd کے شروع کردہ یونٹوں کے لیے StandardOutput کو جرنل یا فائل کی طرف موڑیں اور زندگی کا چکر یونٹ ہی کے پاس رہنے دیں۔ بغیر سائز کی حد کے tee -a کے ذریعے شامل کرنے والا shell لوپ وہی انتظام ہے جو خلل کے دوران تقسیم بھر دیتا ہے، کیونکہ ناکام جانچ صحت مند سے کہیں زیادہ لاگ کرتی ہے۔

ٹائمر کا انتظار کیے بغیر گردش جانچیں

ڈیبگ موڈ بتاتا ہے کیا ہوگا اور کچھ نہیں چھوتا، جو اسے ترمیم کے بعد پہلی محفوظ چلانے کے قابل بناتا ہے۔ مطمئن ہونے پر حقیقی گردش پر مجبور کریں، پھر تصدیق کریں کہ اگلی لاگ سطر نام بدلی فائل کی بجائے نئی فائل میں گرتی ہے:

logrotate -d /etc/logrotate.d/vpn-watchdog
logrotate -f /etc/logrotate.d/vpn-watchdog
ls -l /var/log/vpn-watchdog.log*
tail -n 3 /var/log/vpn-watchdog.log
df -h /var/log

آؤٹ پٹ اسی ترتیب میں پڑھیں۔ ڈیبگ مرحلے کو فائل اور ارادے والے اعمال کا نام لینا چاہیے؛ مجبور چلانے کو متوقع گھمایا نام پیدا کرنا چاہیے؛ tail کو لکھنے والے کے دوبارہ چلنے کے بعد نئی اندراج دکھانی چاہیے۔ بڑھتی df قدر اور سکڑتی نظر آنے والی فائل اوپر بیان کردہ وضاحتی مسئلے کا مطلب ہے۔

جب ورژن پہلے سے موجود ہوں تو برقراری کیسے برتاؤ کرتی ہے یہ دیکھنے کے لیے مجبور چلانا دو بار دہرائیں۔ سب سے پرانی فائل حذف کرنا متوقع نتیجہ ہے، اور حذف نہ ہونا عام طور پر یہ ظاہر کرتا ہے کہ گھمائے گئے نام میں تعداد یا وائلڈ کارڈ logrotate کی بنائی ہوئی سے میل نہیں کھاتے۔

رول بیک اور تحریری ریکارڈ رکھیں

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

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

آخر میں، لاگ کا فیصلہ بحالی کے فیصلے سے الگ رکھیں۔ ناکام جانچ کو کنکشن کی اپنی بحالی پالیسی کی پیروی کرنی چاہیے، logrotate کے اندر چھپے اصول کی نہیں، اور کوئی بھی لاگ انتظام چلتی سرنگ کو دوبارہ شروع کرنے کا سبب نہیں بننا چاہیے۔