চলমান লিনাক্স সিস্টেম আপডেট করা সমস্যাযুক্ত নয় কেন?


25

কয়েক বছর ধরে আমি লিনাক্স সিস্টেমগুলি প্রতিদিন ব্যবহার করি এবং কোন সিস্টেম চলাকালীন আপডেট করার মাধ্যমে আমার কখনই বড় সমস্যা হয়নি, তবে এখনও কেন আমি সম্ভাবনাবোধ করছি তা ভাবছি।

আমাকে একটি উদাহরণ দিন।

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

লাইভ সিডি বা অন্য কিছু অনুরূপ পদ্ধতির সাহায্যে কেউ কেন তাদের সিস্টেম আপডেট করে না?


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

উত্তর:


23

ইউজারল্যান্ড আপডেট করা খুব কমই একটি সমস্যা

আপনি প্রায়শই লাইভ সিস্টেমে প্যাকেজ আপডেট করতে পারেন কারণ:

  1. ভাগ করা লাইব্রেরিগুলি মেমরির মধ্যে সংরক্ষণ করা হয়, প্রতিটি কলের ডিস্ক থেকে পড়া হয় না, সুতরাং অ্যাপ্লিকেশনটি পুনরায় আরম্ভ না করা অবধি পুরানো সংস্করণগুলি ব্যবহারে থাকবে।
  2. ওপেন ফাইলগুলি ফাইলের নাম থেকে নয়, ফাইল-বর্ণনাকারী থেকে পঠিত হয় , তাই সেক্টরগুলি ওভার-লিখিত না হওয়া বা ফাইল বর্ণনাকারী বন্ধ না হওয়া পর্যন্ত সরানো / পুনরায় নামকরণ / মুছে ফেলা সত্ত্বেও ফাইল সামগ্রীগুলি চলমান অ্যাপ্লিকেশনগুলিতে উপলব্ধ থাকে।
  3. প্যাকেজগুলির পুনরায় লোডিং বা পুনরায় চালু করার প্রয়োজন হয় প্যাকেজটি যদি ভালভাবে নকশা করা থাকে তবে প্যাকেজ ম্যানেজার সঠিকভাবে পরিচালনা করে। উদাহরণস্বরূপ, যখনই libc6 আপগ্রেড করা হবে তখন ডেবিয়ান নির্দিষ্ট পরিষেবাগুলি পুনরায় চালু করবে।

সাধারণত, আপনি নিজের কার্নেল আপডেট না করে এবং ksplice ব্যবহার না করা না হলে আপডেটের সুবিধা নেওয়ার জন্য প্রোগ্রাম বা পরিষেবাগুলি পুনরায় চালু করা দরকার। তবে ইউজারল্যান্ডে কিছু আপডেট করার জন্য খুব কমই সিস্টেমকে পুনরায় বুট করার দরকার রয়েছে, যদিও ডেস্কটপগুলিতে এটি ব্যক্তিগত পরিষেবাগুলি পুনরায় চালু করার চেয়ে মাঝে মাঝে সহজ occasion

আরো দেখুন

http://en.wikipedia.org/wiki/Ring_%28computer_security%29#Supervisor_mode


তবে কি হবে, যদি আপনার সমস্ত ক্যাশে-স্মৃতি দরকার হয়? সেক্ষেত্রে ভাগ-লাইব্রেরিগুলি আবার ডিস্ক থেকে লোড করতে হবে ...
নিলস

3
আসলে # 1 এর বর্ণনাটি এত পরিষ্কার ছিল না। পুরানো লাইব্রেরি ফাইলের বিষয়বস্তু পৃথক (মূল) ইনোডের নীচে থেকে যায়, যদিও এর সাথে লিঙ্কযুক্ত সমস্ত নামগুলি চলে যায়, যতক্ষণ না কোনও প্রক্রিয়া ফাইল খোলে, বা এর বিষয়বস্তু ম্যাপ করা হয়, ততক্ষণ ডেটা আলাদা রাখা হয় (এবং ফাইল সিস্টেমটি পারে না ফাইলের লিঙ্কমুক্ত না হওয়া অবধি r / o পুনঃস্থাপন করা হবে)। মূল ফাইলটি ম্যাপ করা প্রক্রিয়াটিতে এখনও মূল বিষয়বস্তুতে মেমরি ম্যাপিং রয়েছে।
স্কেপেরেন

@ নীল আমি কোনও বিশেষজ্ঞ নই, তবে আপনি যদি ক্যাশে থেকে সরে যান তবে কী সেখান থেকে অদলবদল ও পুনরায় পড়তে হবে না? যদি এটি পূর্ণ থাকে তবে অন্য প্রক্রিয়াটি ইতিমধ্যে এটি ব্যবহার করা থেকে স্মৃতি দূরে নেওয়ার আগে কিছু প্রক্রিয়া সম্ভবত অবরুদ্ধ হয়ে যেত।
জো

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

4

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

বেশিরভাগ ক্ষেত্রে, প্রক্রিয়াটি চলাকালীন একাধিকবার পড়া হওয়া ডেটা হ'ল ব্যবহারকারী / পরিবর্তনশীল ডেটা এবং এটি কোনও প্যাকেজ আপগ্রেডের সময় পরিবর্তিত হবে না। এছাড়াও যেহেতু ডেটা পরিবর্তনশীল, তাই তাদের ডান মনের যে কোনও প্রোগ্রামার এটি নিশ্চিত করে যে প্রোগ্রামটি এটি পড়তে শুরু করে পরেরটিতে পরিবর্তন করতে পারে।


ফাইলটির ম্যাপিংয়ের ফলে মেমরির কোনও পরিবর্তন না হলে ফাইলটি "ব্যাকিং স্টোর" হিসাবে পুনরায় পড়তে পারা যায় (যা অন্যথায় ব্যাকিং স্টোরটি যদি পাওয়া যায় তবে অদলবদল করে বদলে দেবে), এবং অন্যান্য চাহিদা চাপের কারণে মেমরি অনুলিপিটি বাতিল হয়ে যায় use স্মৃতি. তবে এটি কোনও সমস্যা নয় কারণ আসল ফাইলটি এখনও খোলা বা ম্যাপ করা আছে। প্রতিস্থাপন গ্রন্থাগারটি একটি নতুন এবং ভিন্ন ফাইল যা পুরানো প্রক্রিয়াটি খোলেনি।
স্কেপেরেন

1
@ স্কেকেরেন আমি ধরে নিচ্ছি আপনি মেমরি-ম্যাপযুক্ত ফাইলগুলির বিষয়ে কথা বলছেন। প্যাকেজ আপগ্রেড করার সময় এগুলি সমস্যা হয় না। সমস্ত প্যাকেজ পরিচালক তাদের পুরানো ফাইলগুলি ওভাররাইট করার পরিবর্তে নতুন ফাইলগুলি তৈরি করে। বাস্তবে এটিই করার একমাত্র উপায় কারণ চলমান এক্সিকিউটেবলকে পরিবর্তন করা যায় না, এটি কেবল লিঙ্কমুক্ত করা যেতে পারে।
প্যাট্রিক

4

ধরুন ফাইল সিস্টেমটিতেও "বি" প্রতিস্থাপন করা হয়েছে। এখন "এ" কে কোনও কারণে আবার "বি" পড়তে হবে। প্রশ্নটি হল: "এ" "বি" এর কোনও বেমানান সংস্করণ এবং ক্রাশ বা অন্য কোনও উপায়ে ক্রিয়া বা ত্রুটি খুঁজে পাওয়া সম্ভব?

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

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

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

লাইভ সিডি বা অন্য কিছু অনুরূপ পদ্ধতির সাহায্যে কেউ কেন তাদের সিস্টেম আপডেট করে না?

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

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


0

কিছু সমস্যা আছে যেখানে এই সমস্যাটি রয়েছে:

  • জাভা-ভিএম চলাকালীন জেডিকে আপগ্রেড: আমি মাইসেলভকে একই প্রশ্নটি জিজ্ঞাসা করেছি যে আপনি পেয়েছিলেন - আমার একটি চলমান টমক্যাট ছিল যা জাভা ব্যবহার করে। এখন জেডিকে একটি প্যাচ-আপডেটের পরে এটি এখনও সমস্যা ছাড়াই চলে - তাই দেখে মনে হয়েছিল।

এখন ব্যাখ্যাটি ক্যাশে-স্মৃতি। ঠিক আছে - সমস্ত উপলভ্য র‍্যাম ব্যবহারের জন্য আমি একটি মেমরি-হগ-প্রোগ্রাম শুরু করেছি - এবং তারপরে টমক্যাট ক্র্যাশ হয়ে গেছে (আমি সেখানে চালিত অ্যাপ্লিকেশনটি অ্যাক্সেস করার পরে)।

  • SuSE- সিস্টেমে কার্নেল-আপগ্রেড: SuSE- এ পুরানো কার্নেল এবং এর মডিউলগুলি কার্নেলের প্যাচ-আপগ্রেড করার পরে ডিলিট হয়ে যায়। তারপরে আপনি যদি নতুন কোনও কিছু ব্যবহার করতে চান তবে এর জন্য কার্নেল-মডিউল প্রয়োজন, যেটি এখনও অবধি লোড করা হয়নি, পরিষেবাটি ব্যর্থ হবে।

2
টমক্যাটের কিছু টুকরা (গুলি) এর মতো শব্দগুলি আবার শুরু হয়েছে, বা ডায়ামিক লাইব্রেরিগুলি জাভা স্তরের নীচে ব্যবহার করা হয়েছিল (যেমন: ড্লোপেন () এবং এর মতো) যা সরাসরি API এর মিশ্রণে শেষ হতে পারে।
স্কেপেরেন

@ স্ক্যাসেরেন এমনকি ভাগ করা লাইব্রেরিগুলি ব্যবহার করার সময় - যদি কোনও প্রোগ্রাম ব্যবহারের পরে বন্ধ হয়ে যায় তবে ক্যাশে খুব কম দেখা দিলে সমস্যা হওয়া উচিত ...
নিলস

1
একটি মুক্ত ফাইল বর্ণনাকারীর একটি ডিরেক্টরিতে ফাইলের নাম হিসাবে ডিস্কের ডেটা ধরে রাখতে একই ক্ষমতা থাকে। যতক্ষণ না ডিস্কের একটি হার্ড লিঙ্ক বা একটি খোলা ফাইল বিবরণী রয়েছে ততক্ষণ মূল ইনোড মুছে ফেলা হবে না । ক্যাশে এর সাথে কিছু করার নেই। এখন, কিছু প্রোগ্রাম তাদের ফাইল বর্ণনাকারী যখন তারা বিশ্বাসীদেরকে ব্যবহার করছেন না বন্ধ করুন এবং যে দেওয়া যাবে ডেটা দূরে যান।
dmckee

@ ডিএমকেকে রাইট আমরা কোর কাছাকাছি হয়। সুতরাং "সাধারণ" প্রোগ্রামটির জন্য কী সাধারণ: গ্রন্থাগারটি খুলুন এবং এটি উন্মুক্ত রাখুন, বা লাইব্রেরিটি লোড করুন এবং পরে এটি বন্ধ করুন?
নীল
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.