প্রক্রিয়া হত্যার আগে Mac VPN হেল্পার শনাক্ত করুন

ইতিমধ্যে চলমান কোনো হেল্পার সম্পর্কে বার্তাকে জীবনচক্রের সূত্র হিসেবে ধরুন, প্রক্রিয়া হত্যা শুরু করার অনুমতি হিসেবে নয়। বিপজ্জনক ধাপটি থামানো নয়, বরং তার আগের শনাক্তকরণ, কারণ একটি Mac-এ একই রকম নামের একাধিক উপাদান থাকতে পারে এবং সংযোগের মালিক তাদের মধ্যে কেবল একটি। আগে পরিচয়ের রেকর্ড তৈরি করুন। তারপর ভাবুন, থামানো আদৌ সঠিক পদক্ষেপ কি না।

কাজ শুরুর আগে পরিচয়ের রেকর্ড গড়ুন

চারটি তথ্য একটি প্রক্রিয়াকে শনাক্তযোগ্য করে: বর্তমান PID ও তার শুরুর সময়, যে এক্সিকিউটেবল ও পণ্যের সঙ্গে এটি যুক্ত, যে ব্যবহারকারী বা সুবিধা-প্রেক্ষাপটে এটি চলে, এবং যেটি এটি চালু করেছে। ps -o pid,ppid,user,etime,command -p 1234 প্রথম তিনটি এক লাইনে দেয়, প্রক্রিয়াটি কতক্ষণ জীবিত আছে তা সহ। Activity Monitor একই তথ্য আরও বন্ধুত্বপূর্ণভাবে দেখায়। নিয়ন্ত্রকটি যোগ করুন, অর্থাৎ যে অ্যাপ্লিকেশন বা সেবা এটি চালু ও থামানোর জন্য দায়ী। এই চারটি নিয়ে প্রক্রিয়া আর কেবল একটি নাম থাকে না, তা এমন একটি বস্তু হয়ে ওঠে যার বিষয়ে আপনি যুক্তি করতে পারেন।

চারটির একটি অজানা হলে সেখানেই থামুন। অচেনা উপাদান প্রকাশক বা প্রশাসকের কাছে একটি প্রশ্ন, কোনো পরীক্ষা নয়।

পুরোনো লগের PID এখন অন্য কারও

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

আর কিছু স্পর্শ করার আগে ভূমিকাগুলো আলাদা করুন। একটি সংযোগের ক্লায়েন্ট, কয়েকটি অ্যাপ্লিকেশনকে সেবা দেওয়া একটি শেয়ার্ড হেল্পার, এবং অন্যের সেশন গ্রহণ করা একটি সার্ভার—সবই তালিকায় ব্যাকগ্রাউন্ড প্রক্রিয়ার মতো দেখায়। তাদের মধ্যে কেবল একটিকেই আপনি যেসব পরিণতি ভাবেননি সেগুলো ছাড়া থামানো যায়।

সিগন্যাল দিয়ে নয়, মালিকের মাধ্যমে থামান

যে নিয়ন্ত্রণটি জিনিসটির মালিক সেটি দিয়ে শুরু করুন: সংযোগের সংযোগ-বিচ্ছিন্ন বোতাম, সেবার সমর্থিত থামানোর কমান্ড, অথবা ব্যবস্থাপনা এজেন্টের নিজস্ব পদক্ষেপ। এই পথগুলো পণ্যটি যে ভাঙন প্রত্যাশা করে তা চালায়, যার মধ্যে রুট সরানো ও টানেল ডিভাইস বন্ধ করা অন্তর্ভুক্ত। সিগন্যাল এসব কিছু এড়িয়ে যায় এবং পেছনে অবস্থা রেখে দেয়।

পরে কী থাকে তা লক্ষ্য করুন। মেমরিতে থেকে যাওয়া প্রক্রিয়া হয়তো পরের সংযোগের অপেক্ষায় আছে, যা ব্যর্থ থামানো নয়, বরং একটি নকশা-সিদ্ধান্ত।

কেন সুপারভাইজার আপনার হত্যা করা প্রক্রিয়া আবার চালায়

কোনো লঞ্চ ডেমন বা অটো-কানেক্ট নীতি যদি টানেল চালু থাকার ইচ্ছা রাখে, তবে প্রক্রিয়া হত্যা কিছুই প্রকাশ করে না। সুপারভাইজার প্রস্থান দেখে আবার চালু করে, কখনো কখনো আপনি লগ পড়া শেষ করার আগেই।

সুপারভাইজারের সঙ্গে লড়াইয়ের আগে তাকে খুঁজে বের করুন। launchctl list লোড করা জব ও তাদের লেবেল দেখায়, আর কিপ-অ্যালাইভ সেটিংসহ জব নকশা অনুযায়ী প্রস্থানে পুনরায় চালু হয়। সেখানে সঠিক পদক্ষেপ হলো উদ্দেশ্য বদলানো: জব আনলোড করুন, অটো-কানেক্ট নীতি বন্ধ করুন, বা প্রশাসককে তা করতে বলুন। জোর করে বন্ধ করা ভিন্ন অর্থবহ ভিন্ন একটি সরঞ্জাম, আর তা আটকে যাওয়া প্রক্রিয়ার জন্য নথিভুক্ত পুনরুদ্ধার পদ্ধতির অংশ, নিয়মিত সংযোগ ব্যবস্থাপনার নয়।

হত্যা নয়, জীবনচক্রের ঘটনাটি লিপিবদ্ধ করুন

উপাদানের পরিচয়, ক্লায়েন্টের সংস্করণ, প্রথম প্রাসঙ্গিক জীবনচক্রের ঘটনা এবং আপনি কী করেছেন তা লিখে রাখুন। ঘটনাটি পদক্ষেপের চেয়ে বেশি গুরুত্বপূর্ণ, কারণ লগইনে দুটি ইনস্ট্যান্স দেখা দেওয়া একটি স্টার্টআপ-ক্রমের সমস্যা যা বারবার ফিরবে। এক্সিকিউটেবল ও তার নিয়ন্ত্রকের নাম উল্লেখ করা রেকর্ড পরের ব্যক্তিকে এটি পুনরুৎপাদন করতে দেয়।

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