একটি VPN স্বাস্থ্য পরীক্ষা যা প্রতি মিনিটে এক লাইন যোগ করে, নিঃশব্দে দ্বিতীয় একটি দায়িত্ব তৈরি করে: ওই লাইনগুলি কীভাবে ডিস্ক ছাড়বে তা ঠিক করা। টানেল মেরামত করলে সেই দায়িত্বের কিছু হয় না, আর ফাইলের নাম বদলালে এমন প্রক্রিয়া পুনর্নির্দেশিত হয় না যার হাতে এখনও পুরনো ডেসক্রিপ্টর আছে। আগে গন্তব্যের প্রশ্নের উত্তর দিন, তারপর ঘূর্ণনকে লেখকের ফাইল খোলার ধরনের সঙ্গে মিলিয়ে দিন।

ঘূর্ণন নীতির আগে গন্তব্য বেছে নিন

যে systemd ইউনিট ইতিমধ্যে তার আউটপুট জার্নালে পাঠায়, সে ধরে রাখার সময়সীমা এক জায়গায় রাখে। journald SystemMaxUse ও MaxRetentionSec -এর মতো সীমা প্রয়োগ করে, তাই সেখানে লগ করা ওয়াচডগ কোনো বাড়তি কাজ ছাড়াই একটি সীমা উত্তরাধিকার পায়। তার পাশে দ্বিতীয় একটি অসীম ফাইল যোগ করলে লাভ ছাড়াই রক্ষণাবেক্ষণ দ্বিগুণ হয়।

নিবেদিত ফাইল তখনই নিজের জায়গা পায় যখন অন্য কিছু তা পড়ে: একটি পার্সার, একটি অডিট এক্সপোর্ট, বা এমন পৃষ্ঠা যা স্থির পথ আশা করে। সেই সিদ্ধান্ত হয়ে গেলে ফাইলটির একটি মালিক, একটি মোড এবং একটি ঘূর্ণন নীতি একসঙ্গে লিখিতভাবে দরকার, কারণ তিনটিই কেবল একটি সেট হিসেবেই সঠিক। যে পথ যে কেউ তৈরি করতে পারে, সে পথ যে কেউ প্রতিস্থাপনও করতে পারে, তাই ডিরেক্টরির অনুমতিও একই নোটে থাকা উচিত। সবটা পরীক্ষার পাশে লিখে রাখুন, পরের সম্পাদনা একই তথ্য থেকে শুরু হবে।

লেখকের সঙ্গে মিলিয়ে অংশটি লিখুন

এমন লেখক দিয়ে শুরু করুন যে প্রতিটি ডাকলেই পথ খোলে, এক লাইন যোগ করে এবং বেরিয়ে যায়। এই ধরনটি প্রক্রিয়ার কোনো সহযোগিতা ছাড়াই ঘূর্ণন টিকে যায়, কারণ পরের বার ওই পথে তখন যে ফাইল আছে সেটিই খোলে। নিচের অংশটি এক সপ্তাহের সংস্করণ রাখে এবং লেখকের প্রয়োজনীয় মালিক ও মোড দিয়ে ফাইলটি আবার তৈরি করে:

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

logrotate নির্দেশিকা সংখ্যাটিকে রাখা ঘোরানো সংস্করণের সংখ্যা হিসেবে সংজ্ঞায়িত করে, নিশ্চিত সাত দিনের ইতিহাস হিসেবে নয়, আর daily কীওয়ার্ডটি নিজে সময়সূচি হিসেবে কাজ না করে কাজ চালানোর সময় মূল্যায়িত হয়। বেশিরভাগ ডিস্ট্রিবিউশনে একটি systemd টাইমার বা cron এন্ট্রি ইতিমধ্যে ওই ডাকলের মালিক, তাই দ্বিতীয়টি যোগ করার আগে কোনটি আছে দেখে নিন। মালিকানা মেলানো ধরে রাখার সংখ্যার চেয়ে বেশি জরুরি। শুধু root-এর মোড একটি সার্ভিস অ্যাকাউন্টের লেখা ফাইলে কপি করলে পরের ঘূর্ণনে লগ বন্ধ হয়ে যায়, আর ব্যর্থতা ঘণ্টা পরে ত্রুটি হিসেবে নয়, বাসি টাইমস্ট্যাম্প হিসেবে দেখা যায়। অন্য জায়গা থেকে অংশ কপি করার আগে লেখকের ব্যবহারকারী নিশ্চিত করুন।

যে লেখক কখনও আবার খোলে না, তার অন্য সমাধান দরকার

দীর্ঘকাল চলা প্রক্রিয়া খোলা ডেসক্রিপ্টর ধরে রেখে নাম বদলানো ইনোডে লেখা চালিয়ে যায়। জায়গা মুক্ত হয় না এবং দৃশ্যমান ফাইল বাড়া থামে, যা ইনোড না দেখা পর্যন্ত ভাঙা ঘূর্ণনের মতো দেখায়। হয় প্রক্রিয়াকে আবার খোলা শেখান, নয়তো নাম বদলের বদলে ঘূর্ণনকে কপি ও ছাঁটাই করতে দিন।

পুনরায় খোলার পথটিই পরিষ্কার, যেখানে সফটওয়্যার তা সমর্থন করে: নথিভুক্ত সংকেত পাঠান বা নথিভুক্ত কমান্ড চালান, এবং প্রক্রিয়াকেই নতুন ফাইল খুলতে দিন। বিকল্পটি হল 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-এর ভিতরে লুকানো নিয়ম নয়, এবং কোনো লগ ব্যবস্থাই চলমান টানেল পুনরায় চালু করার কারণ হওয়া উচিত নয়।

সম্পর্কিত নিবন্ধ