उबंटू प्रणाली को रिबूट करना कब आवश्यक है?


25

किन परिस्थितियों में एक उबंटू प्रणाली का रीबूट आवश्यक है? मैं अक्सर जवाब में पढ़ता हूं कि सिस्टम में बदलाव के बाद सिस्टम को फिर से शुरू करना है, लेकिन क्या यह बिल्कुल आवश्यक है?

जवाबों:


22
  • कर्नेल घबराहट के बाद;
  • विभाजन या फाइलसिस्टम संशोधनों (अधिक विशेष रूप से, रूट विभाजन का आकार बदलने के बाद; मैं उस हार्ड ड्राइव के आकार से बचने की सलाह दूंगा, जिसमें आप सामान्य रूप से बूट होते हैं, विभाजन की परवाह किए बिना; यदि आप किसी बाहरी चीज़ का आकार बदल रहे हैं, जैसे कि एसडी कार्ड या यूएसबी, कोई रिबूट आवश्यक नहीं है );
  • कर्नेल उन्नयन और सुरक्षा पैच के बाद (हालांकि यह हमेशा आवश्यक नहीं हो सकता है );
  • सिस्टम जो भी कारण के लिए अनुत्तरदायी हो गया, और आपके पास जादू SYSRQ कुंजी या हार्ड रीसेट का उपयोग करने के अलावा कोई विकल्प नहीं है
  • कुछ dconf स्कीमा में परिवर्तन करने के बाद , जिस तरह से अनुप्रयोग विकसित किया गया है, उसके आधार पर। संबंधित उत्तर
  • आपका CPU ओवरहीट हो रहा है (आप उन कोरस को भूनना नहीं चाहते, क्या आप?)

विभाजन के बाद आपको उबंटू को रीबूट करने की आवश्यकता क्यों होगी?
UTF-8

@ UTF-8 आमतौर पर, डेटा हानि को रोकने के लिए एक अनमाउंट फाइल सिस्टम को विभाजित करने की सिफारिश की जाती है। इसलिए, यदि आप अपनी हार्ड ड्राइव को विभाजित करना चाहते हैं, तो आपको लाइव यूएसबी / डीवीडी डालने और रिबूट करने की आवश्यकता होगी; जब आपने विभाजन किया, तो हार्ड-ड्राइव पर वापस रिबूट करें।
सर्गी कोलोडियाज़नी

2
हां, लेकिन फिर रिबूट करना कुछ ऐसा है जो आप वैसे भी करते हैं। यदि आप कुछ विभाजन करते हैं, तो सिस्टम निर्भर नहीं करता है (डेटा विभाजन, अंगूठे ड्राइव, एसडी कार्ड, बाहरी HDD, फ़ाइल कंटेनर, जो भी हो), आपको रिबूट करने की आवश्यकता नहीं है। जब मैंने 2 घंटे पहले 2 डिवाइसेस के लिए एक नया पार्टीशन टेबल बनाया तो मैंने रिबूट नहीं किया।
UTF-8

@ UTF-8 मुझे लगता है कि मुझे अपने उत्तर में अधिक विशिष्ट होना चाहिए था। एक दूसरे में तय हो जाएगा :)
18g पर Sergiy Kolodyazhnyy

1
विभाजन की बात के साथ, कभी-कभी gparted आदि का कहना है कि 'कर्नेल plz को पुनः आरंभ करने की सूचना नहीं दे सकता'
Wilf

17

आमतौर पर दो स्थितियाँ होती हैं जहाँ एक रिबूट आमतौर पर आवश्यक होता है:

  1. कर्नेल उन्नत है।
  2. libc(बल्कि, glibc) उन्नत है।

पुनः आरंभ किए बिना कर्नेल को फिर से लोड करने के लिए एक तंत्र है ( मैं रिबूट किए बिना अपने सर्वर के कर्नेल को कैसे अपग्रेड कर सकता हूं? )। के साथ glibc, सबसे बड़ी समस्या init है। यह init को फिर से शुरू करना संभव है ( सिस्टम को पुनः आरंभ किए बिना init को फिर से शुरू करना देखें )।

औसत उपयोगकर्ता के लिए, न तो अनुशंसित है, और पुनरारंभ करना आवश्यक है

जाहिर है, वहाँ एक तीसरा मामला मौजूद है:

  1. dbusअपग्रेड किया गया है। dbus-daemonजाहिरा तौर पर पुनः आरंभ करने में असमर्थ है (मैं इस LWN लेख पर चर्चा से क्या समझ सकता हूं )। और चूंकि बहुत सी चीजें डीबस पर निर्भर हैं ...

12

दरअसल, यह निर्भर करता है कि आप क्या हासिल करना चाहते हैं:

  • यदि आप करते हैं apt-get dist-upgradeऔर एक नया कर्नेल आता है, और आप इसे सक्रिय करना चाहते हैं, तो आपको रिबूट की आवश्यकता है।

  • अगर फ़ायरफ़ॉक्स का नया संस्करण आता है, तो आप स्पष्ट रूप से नहीं जानते हैं।

और उन दो चरम सीमाओं के बीच में 50 शेड ग्रे हैं:

यहाँ छवि विवरण दर्ज करें

;-)


1
वास्तव में 50 शेड्स :)
एबी

1
50 शेड्स का यह रिस्पॉन्स कमाल का है! :)
टेरेंस

1
मैं इस एसई पर एक खाता बनाया बस इस उत्तर को उभारने के लिए ... और हां, 50 रंगों के ग्रे के लिए।
CD19

9

मेरे पास वास्तव में आज पहले की स्थिति थी जो यह साबित करती है। कभी-कभी, व्यवस्था में बदलाव के बाद अवशिष्ट चीजें बच जाती हैं। उदाहरण के लिए, मेरे पास एक उपयोगकर्ता था /dev/dspजो उपयुक्त समूहों में जोड़े जाने के बावजूद उपयोग करने में सक्षम नहीं था । पहले उपयोगकर्ता द्वारा इसे एक्सेस करने वाले लॉक पर रखा गया था। हालांकि, उस उपयोगकर्ता को मारने के बाद भी, लॉक अभी भी था और दूसरा उपयोगकर्ता इसे एक्सेस नहीं कर सका। हालाँकि, रिबूट के बाद, दोनों उपयोगकर्ता /dev/dspबिना किसी संघर्ष के एक साथ उपयोग करने में सक्षम थे । रिबूट करना किसी भी अवशिष्ट चीजों को जारी करता है जो परिवर्तनों को ठीक से प्रभावी होने से रोक सकता है।


ठीक है, पुनरारंभ ने वांछित प्रभाव लाया, लेकिन क्या यह वास्तव में आवश्यक था।
एबी

हां, क्योंकि ossमैं जिस प्रक्रिया के साथ काम कर रहा था , उसे मारना इसे कुछ हद तक असंगत स्थिति में छोड़ने के लिए दिखाया गया है जहां यह हमेशा बाद में काम नहीं करता है।

9

मैं ऐसी किसी भी स्थिति के बारे में नहीं सोच सकता जहाँ रिबूट बिल्कुल आवश्यक हो

वास्तव में, आप उबंटू को अनिश्चित काल के लिए छोड़ सकते हैं। यह मैलवेयर हो सकता है (क्योंकि कर्नेल और libc अपडेट लागू नहीं होते हैं) और यह घबरा सकता है या दुर्घटनाग्रस्त हो सकता है ... लेकिन जो लोग वास्तव में आपके लिए क्या करने जा रहे हैं, वे इससे बच रहे हैं?

जीवन की जटिलताओं को देखते हुए, कंप्यूटर की निरंतर मांगों को नजरअंदाज करना और अन्य तरीकों से खुद को बनाए रखना अधिक आवश्यक हो सकता है। जैसे सांस लेना, खाना, प्यार करना ... जीना।

लेकिन फिर भी, क्या वे बिल्कुल आवश्यक हैं? क्या इस विमान पर आपका अस्तित्व आवश्यकता की पूर्ण परिभाषा के भीतर है? मैं ईमानदारी से नहीं जानता। पूछने के लिए एक अजीब सा सवाल।


दो बड़े-मोटे-मजाक-बिगाड़ने वालों के लिए जिन्होंने इस पोस्ट को डाउनवोट किया और जो इसे फॉलो करते हैं,

यह सवाल अधूरा था, या कम से कम खुला हुआ था। जब आप आवश्यक जैसे शब्दों को चारों ओर फेंकते हैं , तो आपको एक संदर्भ देने की आवश्यकता होती है।

कई उत्तरों ने पहले ही मान लिया था कि ओपी का मतलब अत्यधिक वांछनीय था (तकनीकी अर्थ में), इसलिए पोस्ट किए गए उत्तर जो आपके कंप्यूटर के क्रैश होने पर हैक होने या आवश्यक होने से बचने के लिए आवश्यक जैसे फिट संदर्भ देते हैं । वे अच्छे जवाब हैं। एक और जोड़ना वास्तव में वारंट नहीं था।

लेकिन वे कहते हैं कि धारणाएँ सभी प्रकार के अप की माँ हैं (या वैसे भी कुछ) तो मैंने इसे पूरी आवश्यकता के लिए वापस छील दिया । यदि आप 10.10 की पुरानी कॉपी का उपयोग करने पर जोर देते हैं, तो टाइम और स्पेस उनकी जीत के समान होगा।

आप ध्यान दें कि मैं उस स्थिति की सिफारिश नहीं कर रहा हूँ ।


2
रीबूटिंग पर खाने को प्राथमिकता देने के लिए +1 और एक व्यापक मुस्कान! : डी
बाइट कमांडर

मैलवेयर? आओ, कर्नेल अपडेट और libc अपडेट का यहां कोई लेना-देना नहीं है। ठीक है, शायद कर्नेल एक भूमिका निभा सकता है, लेकिन यह सब इंटरनेट पर निर्भर करता है, और लिनक्स में भी संक्रमित होने का जोखिम कम होता है। उबंटू में ऑटो-अपडेट भी है। लिनक्स सुपर स्थिर भी है, लेकिन मैं मानता हूं कि जोखिम है। नहीं तो कुदोस।
3

5

प्रश्न को वास्तव में मुख्य रूप से आधारित राय के रूप में बंद किया जाना चाहिए ।

तथ्य यह है, यह इस बात पर निर्भर करता है कि क्या अपडेट किया गया था, आपका सिस्टम खुले इंटरनेट से कैसे जुड़ा है, और आपके पास कौन सी सिस्टम सेवाएं हैं / चलाने की आवश्यकता है।

बस पैकेज के नए संस्करणों को स्थापित करने से संबंधित सेवाओं और अनुप्रयोगों को फिर से शुरू नहीं किया जाता है। उदाहरण के लिए, यदि आप इसके लिए एक अद्यतन पैकेज स्थापित करते समय फ़ायरफ़ॉक्स चला रहे हैं, तो आपको ब्राउज़र में सूचित किया जाएगा जब आप इसे वापस स्विच करते हैं, कि अपडेट स्थापित होने के बाद इसे फिर से चालू करना होगा। इसी तरह, कर्नेल को "अपडेट" करने की आवश्यकता होती है, जब इसके लिए अपडेट लागू किए जाते हैं। क्योंकि कर्नेल हार्डवेयर से ऊपर का सबसे निचला स्तर है, आपको नए कर्नेल को लोड करने के लिए सिस्टम को रिबूट करने की आवश्यकता है। अन्य सेवाओं के लिए, उन्हें रिबूट किए बिना फिर से शुरू किया जा सकता है। एकता के लिए एक अद्यतनया पर्यावरण की सेवाओं द्वारा उपयोग किए जाने वाले अंतर्निहित पुस्तकालय, आपको उन्हें पुनः आरंभ करने के लिए लॉग आउट और वापस करने की आवश्यकता होगी। सिस्टम सेवाओं के लिए, अपडेट लागू होने के बाद उन्हें मैन्युअल रूप से पुनरारंभ करना संभव हो सकता है, लेकिन यदि आप सिस्टम का उपयोग करने का प्रयास कर रहे हैं, तो स्वचालित रूप से ऐसा करना बहुत विघटनकारी हो सकता है।

एक निश्चित कार्रवाई करने के लिए बिल्कुल निश्चित रूप से जानने का एकमात्र तरीका है, यह जानना कि परिवर्तन क्या हैं, और आपका जोखिम उस कार्रवाई को नहीं करने के लिए है। सुरक्षा सुधारों को स्पष्ट रूप से अन्य चीजों के लिए सरल परिवर्तनों की तुलना में अधिक अचानक कार्रवाई की आवश्यकता होती है, जो आपको कभी सीधे सामना नहीं कर सकते हैं। आपका कंप्यूटर जितना अधिक इंटरनेट से जुड़ा होगा, उतना ही जोखिम भी होगा। आपको सभी चर पर विचार करना होगा, और जब आप अपडेट इंस्टॉल करते हैं, तो यह निर्णय लेना है कि अभी या बाद में रिबूट करना है या नहीं।


5

उबंटू प्रणाली को रिबूट करना कब आवश्यक है?

एक रनिंग मशीन और एक अपडेट / अपग्रेड करते समय सख्ती से? शायद कभी नहीं (लेकिन पढ़ते हैं)। लिनक्स सिस्टम को इस तरह से सेट किया जाता है कि आपके द्वारा सिस्टम को अपडेट करने के बाद जहां उसे नई सुविधाओं को सक्रिय करने के लिए रिबूट की आवश्यकता होगी (यानी, कर्नेल को बदल दिया गया है। अपाचे में परिवर्तन, mysql को केवल सेवा को पुनरारंभ करने की आवश्यकता है) हमेशा चालू स्थिति के साथ काम करना जारी रख सकता है।

अब यदि आप इन नई सुविधाओं को सक्रिय करना चाहते हैं तो ऐसा करना सबसे आसान तरीका है। लेकिन हम सब के लिए आप इस मशीन पर काम करते रहते हैं और अगले सप्ताहांत या उसके बाद के सप्ताहांत में इसे रिबूट करते हैं। या अगले क्रिसमस। क्या यह स्मार्ट है? शायद नहीं। लेकिन आपको ऐसा करने से कोई नहीं रोक रहा है। यदि सर्वर अभी तक रिबूट नहीं हुआ है तो सिस्टम अगले अपडेट को स्वीकार नहीं करने के लिए पर्याप्त स्मार्ट है।

मेरे लिए एकमात्र कारण जहां रिबूट आवश्यक है, पहली बार इंस्टॉल करने के बाद या रखरखाव करते समय जहां एकल उपयोगकर्ता की आवश्यकता होती है (विभाजन विभाजन जैसी चीजों पर विचार करें, हार्ड डिस्क की त्रुटियों को ठीक करें) या जब कुछ बेवकूफों ने प्रसिद्ध कांटा बम को चलाया (हालांकि वह तय किया जा सकता था) सिस्टम से ही)।

अन्य सभी रिबूट के लिए प्रशासक की कृपा है। और मैं उस "आवश्यक" को नहीं कह सकता।


4

सबसे पहले, मैं इस सवाल की सराहना करता हूं क्योंकि यह हमेशा चालू रहेगा।
अन्य उत्तर सही हैं और बहुत विस्तृत हैं - यही कारण है कि मैं कम जाता हूं।

ऐसे परिदृश्य हैं जहां एक रिबूट आवश्यक है, जैसे कि नया कर्नेल स्थापित करने के बाद।
ऐसे परिदृश्य हैं जहां इसकी सिफारिश की जाती है, जैसे कि एक नया डेस्कटॉप स्थापित करने के बाद।

अधिकांश परिदृश्यों में, जैसे कि सॉफ़्टवेयर रीबूटिंग को स्थापित या अपग्रेड करने के बाद आवश्यक नहीं है।
जब भी आपको संदेह होता है, मैं पुनः आरंभ करने की सलाह देता हूं, इसलिए आप सुरक्षित पक्ष पर हैं।


2
माना। यह हमेशा सुरक्षित पक्ष पर रहने के लिए बेहतर होता है
सर्गी कोलोडाज़नी

"ऐसे परिदृश्य हैं जहां इसकी सिफारिश की जाती है, जैसे कि एक नया डेस्कटॉप स्थापित करने के बाद।" उस मामले के लिए लॉग आउट और बैक पर्याप्त नहीं होगा?
एलिया कागन

@ एलियाकगन हाँ, आमतौर पर यह निश्चित रूप से लॉगआउट करने के लिए पर्याप्त होना चाहिए और जब आप एक नया डेस्कटॉप वातावरण स्थापित करते हैं तो वापस आ जाते हैं, लेकिन मैंने ऐसे कई मामले देखे हैं जहां कुछ गलत हुआ और इसलिए मैंने कहा, यह अनुशंसित है । :)
सीएल-नेटबॉक्स

2

पैकेज स्थापित करें debian-goodies:

sudo apt-get install debian-goodies

और कमांड चलाएं

sudo checkrestart

आपको सेवाओं की एक सूची दिखाई देगी और अब आपके पास विकल्प होगा:

  • प्रत्येक सेवा को पुनरारंभ करें

या

  • अपने सिस्टम को रिबूट करें

$ checkrestart
Found 20 processes using old versions of upgraded files
(15 distinct programs)
(14 distinct packages)

Of these, 12 seem to contain init scripts which can be used to restart them:
The following packages seem to have init scripts that could be used to restart them:
gpm:
        3044    /usr/sbin/gpm
rpcbind:
        2208    /sbin/rpcbind
bind9:
        8463    /usr/sbin/named
openssh-server:
        22124   /usr/sbin/sshd
ntp:
        4078    /usr/sbin/ntpd
tftpd-hpa:
        3417    /usr/sbin/in.tftpd
uptimed:
        2704    /usr/sbin/uptimed
cron:
        3019    /usr/sbin/cron
postfix:
        22145   /usr/lib/postfix/qmgr
        8892    /usr/lib/postfix/master
hddtemp:
        3174    /usr/sbin/hddtemp
autofs:
        2792    /usr/sbin/automount
openbsd-inetd:
        3254    /usr/sbin/inetd

These are the init scripts:
service gpm restart
service rpcbind restart
service bind9 restart
service ssh restart
service ntp restart
service tftpd-hpa restart
service uptimed restart
service cron restart
service postfix restart
service hddtemp restart
service autofs restart
service openbsd-inetd restart

These processes do not seem to have an associated init script to restart them:
isc-dhcp-client:
       3775    /sbin/dhclient
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.