अधिकतम समय जिसके लिए लिनक्स पीसी यूपी हो सकता है? [बन्द है]

Question

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

जाँच करना चाहता था कि क्या लिनक्स को भी कुछ समय के बाद मशीन को रिबूट करने की आवश्यकता होती है ताकि इस प्रकार की खरपतवार त्रुटियों से बचने के लिए जो कि दोहराए जाने योग्य न हो।

हम पीसी को बनाए रखने का अधिकतम समय क्या है? यदि रिबूट के बिना हमारे पास वर्ष या उससे अधिक के लिए एक प्रणाली है तो क्या कुछ अन्य समस्याएं हो सकती हैं?

Comments

मुझे नहीं लगता कि एक स्थैतिक सीमा है, क्योंकि कंप्यूटर अभी जागने और इतने लंबे समय तक चलने के लिए नहीं हैं। कोई रेटेड सीमा नहीं है; आपका कंप्यूटर कितनी देर तक टिक सकता है। आप कभी-कभार रिबूट क्यों नहीं करना चाहेंगे।

— द वेंडर

@ Zacharee1 उम, आप रिबूट क्यों करना चाहते हैं? जब तक यह बिजली की खपत नहीं है, तब तक वास्तव में इसका एक कारण नहीं है। वास्तव में, यह बेहतर है यदि आप नहीं करते हैं। हार्डवेयर आम तौर पर पिछले साल, प्रति वर्ष X वर्ष। आइए सादगी के लिए कहते हैं कि एक्स सार्वभौमिक रूप से 10 है (यह या तो दूर नहीं होने वाला है) - यह आमतौर पर 10 निरंतर वर्षों का उपयोग होता है। यह सामान्य उपयोग है। यदि आप रिबूट करते हैं जो निरंतर उपयोग नहीं करता है, लेकिन आप अगली बार मशीन के बूट में हार्डवेयर को मार रहे हैं। यदि आप इसे छोड़ देते हैं - अधिकांश घटक नीचे स्पिन करते हैं, तो खपत कम करें और वैसे भी पहनें।

— 20

यह स्पष्ट रूप से मामला है कि जब उपयोग में अधिक भागों से गुजरना पड़ता है। हालांकि, रिबूट करना (सिस्टम को बंद करने से अलग) घटकों पर पहनने को कम नहीं करता है, यह इसे बढ़ाता है। इसके अलावा, आप मूलभूत रूप से गलत समझते हैं कि कैश कैसे काम करता है अगर आपको लगता है कि रैम में कैश्ड डेटा आपके कंप्यूटर को धीमा कर देता है।

— user6053

यदि आप लिनक्स पर एक वेब सर्वर चला रहे हैं (जैसे LAMP) तो आप रिबूट से जितना संभव हो उतना बचना चाहते हैं क्योंकि ऐसा करने से सिस्टम को वापस आने में लगने वाले समय के लिए आपकी वेब साइट्स नीचे आ जाएगी। मुझे नहीं लगता कि मैं कभी एक साल गया लेकिन निश्चित रूप से कई महीने बिना रिबूट किए।

— tcrosley

@ Zacharee1 RAM में बहुत कुछ भी आपके कंप्यूटर को धीमा नहीं करेगा। यदि किसी एप्लिकेशन में मेमोरी लीक है, तो वह 60% RAM कह सकता है और सिस्टम जल्द ही स्वैप करना शुरू कर देगा, जो कि धीमा है, हालाँकि, एप्लिकेशन को पुनरारंभ करना है, OS नहीं। मशीन को बंद करने से घटकों का पहनना बंद हो जाता है, लेकिन आप उन्हें जल्द से जल्द बदल देंगे क्योंकि वे आमतौर पर ज्यादातर मामलों में पहनते हैं। और इसके अलावा, जैसा कि मैंने बताया, हार्डवेयर घटक पहले से ही पहनने में कमी करते हैं। बस सिस्टम बेकार छोड़कर।

— वीएलए

Answer 1

सिस्टम प्रशासक के रूप में कार्य करना, मैं रिबूट के बिना 700-800 दिनों के लिए लिनक्स सर्वर देखता हूं, इसलिए कोई अपटाइम सीमाएं नहीं हैं; आपको जो त्रुटियां मिली हैं वे लिनक्स (कर्नेल) से संबंधित नहीं हैं।

बहुत सारी सेवाओं को फिर से शुरू किया जा सकता है और अधिकांश त्रुटियों को उत्पादन प्रणालियों पर हल किया जा सकता है।

Comments

इसकी पुष्टि कर सकते हैं। मेरे एक सर्वर पर वर्तमान अपटाइम: ~ $ uptime 00:13:15 883 दिन, 9:00, 1 उपयोगकर्ता, लोड औसत: 0.00, 0.01, 0.05 Ubuntu 12.04.4 LTS। कुछ भी अपडेट करने की आवश्यकता नहीं है क्योंकि यह कुछ महत्वपूर्ण नहीं चल रहा है।

— मिन्थोस

मैंने सफलतापूर्वक 3+ वर्षों के लिए एक एम्बेडेड लिनक्स उदाहरण को सफलतापूर्वक रखा है।

— राफेल Cieślak

Answer 2

एक निश्चित समयावधि के बाद आपके कंप्यूटर को पुनरारंभ करने की कोई तकनीकी आवश्यकता नहीं है। मैंने महीनों तक (incl। कर्नेल मॉड्यूल अपडेट) कुछ निलंबन (रैम और डिस्क के बीच) के बीच में किया है।

ऐसे मौके हैं जहां

• कर्नेल अपडेट की तरह रिबूट करना बिल्कुल आवश्यक है (लेकिन वे कई स्थितियों में जरूरी नहीं हैं, और कुछ मामलों में आप एक जीवित कर्नेल को एक नए सिस्टम के साथ बदल सकते हैं। kexec और Ksplice देखें )
• केवल एक विशेष (उप) सिस्टम के बजाय पूरे सिस्टम को पुनः आरंभ करना आसान हो सकता है।

कुछ समस्याएं हो सकती हैं जो समय के साथ "बदतर हो जाती हैं" (जैसे हार्डवेयर ड्राइवर मुद्दे, टपकी प्रक्रियाएं), लेकिन उन लोगों को कीड़े माना जाता है और अक्सर एक सॉफ़्टवेयर अपग्रेड के साथ तय किया जा सकता है या उस विशेष उप-प्रणाली के पुनः लोड / पुनरारंभ द्वारा काम किया जा सकता है (भी ऊपर देखो)।

Comments

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

— पीटर कॉर्डेस

मैं पीटर से सहमत हूं। इसलिए मैंने इस संदर्भ में लाइव पैचिंग का उल्लेख नहीं किया, क्योंकि चीजों को अधिक जटिल नहीं बनाया गया था; अफसोस कि किसी ने मेरा जवाब संपादित किया।

— डेविड फ़ॉस्टर

Answer 3

जब मैं निश्चित हूं कि उच्च अपटाइम वाले सर्वर हैं, मैं निम्नलिखित में से एक से एक उदाहरण प्रस्तुत करता हूं कि क्या संभव है:

# uptime
04:58:44 up 2186 days, 23:15,  1 user,  load average: 0.02, 0.02, 0.00

यह सर्वर DC के लाइव होने के तुरंत बाद स्थापित किया गया था और तब से बंद नहीं किया गया है। इस प्रकार अब तक यह खुशी से जारी रहा है जो मूल रूप से इसका उद्देश्य था और जब वह उद्देश्य एक अलग सर्वर पर चला जाता है तो मैं वहां पर कुछ डालूंगा सिर्फ अपटाइम की निगरानी के लिए और यह तब तक रहेगा जब तक मैं इसे जीवित रखने का औचित्य नहीं बना सकता। अब किसी भी।

इस प्रकार मुझे लगता है कि "कोई अधिकतम नहीं है" निश्चित रूप से सही उत्तर है।

Answer 4

मुझे नहीं पता कि इससे सिस्टम की स्थिरता पर कोई प्रभाव पड़ता है, लेकिन उबंटू में दिखाया गया अधिकतम कर्नेल 3.19-xx के साथ 68,096259734982232-बिट मशीन 292471208677,8627पर वर्ष और 64-बिट मशीन पर वर्ष है।

ऐसा इसलिए है क्योंकि सिस्टम का वर्तमान अपटाइम, जिसे sysinfo()syscall द्वारा लौटाया जाता है__kernel_long_t , एक प्रकार के रूप में लौटाया जाता है , जिसे 32-बिट कर्नेल में और 64-बिट कर्नेल में एक के रूप में घोषित किया जाता हैlong ;long long

एक long32-बिट मशीन पर की एक अधिकतम मूल्य है 2147483647;

एक long long64-बिट मशीन पर की एक अधिकतम मूल्य है 9223372036854775807;

गणित कर रहा है, 2147483647s= 68,0962597349822वर्ष और 9223372036854775807s= 292471208677,8627वर्ष।

एक बार जब यह मान अपने प्रकार की क्षमता से अधिक हो जाता है, तो एक अंकगणितीय अतिप्रवाह होता है और यह इसके प्रकार (दोनों मामलों में ऋणात्मक संख्या) द्वारा अनुमत सबसे छोटे मान पर सेट होता है: यह इस पर निर्भर कार्यक्रमों के लिए एक मुद्दा हो सकता है।

Comments

ओपी अधिकतम अपटाइम के लिए नहीं कह रहा है कि सिस्टम सटीक रूप से लॉग इन कर सकता है, वह पूछ रहा है कि क्या उसे कुछ स्थिरता / आदि के कारण नियमित रूप से अपने सिस्टम को रिबूट करने की आवश्यकता होगी। सीमा।

— बोलुक पपुकोग्लू

@BolucPapuccuoglu देखें अगर आपकी राय में यह इस प्रारूप में बेहतर फिट बैठता है, तो अंतिम भाग। मैंने स्पष्ट रूप से बताया कि समस्या क्या हो सकती है। अगर आपको अभी भी लगता है कि यह नहीं है, तो मैं अपना उत्तर हटा दूंगा।

— कोस

Answer 5

मैं एक वर्ग में एक बार एक sysadmin था जिसने दावा किया था कि उसके पास एक linux सर्वर था जो एक दशक से अधिक रिबूट के साथ नहीं चल रहा था। कोई अंतर्निहित कारण नहीं है कि एक प्रणाली को नियमित रूप से रिबूट करने की आवश्यकता है। यह केवल कर्नेल अपडेट जैसे सीमित उदाहरणों में आवश्यक है।

एफडब्ल्यूआईडब्ल्यू, मैं आमतौर पर अपने विंडोज होम कंप्यूटर को चालू रखता हूं। यह आमतौर पर रिबूट किए बिना हफ्तों तक ठीक चलेगा।

Comments

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

— tcrosley

@tcrosley वैसे भी स्वचालित अपडेट की आवश्यकता किसे है? यह उन मशीनों में बंद होने वाली पहली चीजों में से एक है। मैं तय करूंगा कि अपने कंप्यूटर का उपयोग कैसे किया जाए, कुछ स्वचालित सेवा नहीं।

— मस्त

@tcrosley क्या आपको यकीन है कि विंडोज सुरक्षा अपडेट आमतौर पर हर हफ्ते डाउनलोड किए जाते हैं? मेरी समझ, Microsoft की अद्यतन रिलीज़ नीतियों और Windows का उपयोग करने के व्यक्तिगत अनुभव से, यह है कि अद्यतन आम तौर पर प्रति माह लगभग एक बार जारी किए जाते हैं। मस्त: जब आप निश्चित रूप से स्वत: अपडेट को अक्षम करने के लिए स्वतंत्र होते हैं, तो मुझे नहीं पता कि इसके परिणामस्वरूप लंबे समय तक सुधार क्यों होगा। संभवतः - उम्मीद है! - आप मैन्युअल रूप से अद्यतन कर रहे हैं, कम से कम सुरक्षा सुधारों के लिए। दूसरी ओर, स्वत: अद्यतन को अक्षम यह आसान नियंत्रित करने के लिए कर सकते हैं जब से अन्तराल होता है।

— एलियाह कगन

@EliahKagan मेरे पास न केवल सुरक्षा सुधारों को डाउनलोड करने के लिए मेरा मशीन सेटअप है, बल्कि एप्लिकेशन, ड्राइवरों आदि के लिए अपडेट भी है। मैं सप्ताह में एक बार होने के बारे में गलत हो सकता हूं, लेकिन यह निश्चित रूप से महीने में एक बार से अधिक है। यह हर सुबह 3:00 बजे अपडेट के लिए जाँच करता है। मैं सुबह आऊंगा, और पाऊंगा कि मेरा सिस्टम रिबूट हो गया है, और लॉग ऑन करने के बाद, एक संदेश है "अपडेट्स इंस्टॉल करने के लिए आपका सिस्टम रिबूट किया गया था।"

— tcrosley

Answer 6

जब प्रोग्राम से बाहर निकलते हैं तो लिनक्स (कर्नेल) संसाधनों को मुक्त करने में बहुत अच्छा होता है। जीएनयू / लिनक्स, संपूर्ण ओएस, आमतौर पर अनिश्चित काल तक चलने के लिए ठीक है। अद्यतन करने के बाद उपयोगकर्ता-अंतरिक्ष कार्यक्रमों को फिर से शुरू करना आम तौर पर एक अच्छा विचार है, और अक्सर अपडेट glibcका उपयोग करके सब कुछ प्राप्त करने का सबसे आसान तरीका सिस्टम को रिबूट करना है।

ड्राइवर बग (आमतौर पर ग्राफिक्स ड्राइवर बग, आमतौर पर बाकी सब कुछ ठोस है) के साथ सिस्टम पर, आपको कभी-कभी अजीब व्यवहार मिलता है जो जल्दी ही रिबूट नहीं होने पर अजीब हो जाता है। यदि आप अपने dmesgआउटपुट में एक कर्नेल OOPS देखते हैं , तो आपको सुविधाजनक होते ही रिबूट करना चाहिए, और इसे रिपोर्ट करें (या समान हार्डवेयर पर समान समस्याओं वाले अन्य लोगों के लिए Google के आसपास, यह एक ज्ञात समस्या है)। डिस्ट्रोस ग्राफिक्स स्टैक के बहुत नवीनतम देव संस्करणों को शिप नहीं करते हैं, इसलिए कभी-कभी बग पहले से ही ऊपर की ओर तय हो जाता है, और आपके ग्राफिक्स कार्ड आपके द्वारा स्थिर होने के लिए चलाए जा रहे डिस्ट्रो संस्करण पर ड्राइवरों के लिए बहुत नया है। उस स्थिति में, मीसा / डीआरएम / एक्सजीआर के अद्यतन बिल्ड के साथ पीपीए की तलाश करें। (मुझे यकीन नहीं है कि ब्लीडिंग एज ग्राफिक्स स्टैक के साथ उबंटू चलाने के लिए सबसे अच्छा विकल्प एटीएम क्या है)।

वैसे भी, ड्राइवर या अन्य कर्नेल कीड़े को छोड़कर, लिनक्स मेमोरी को विखंडन या उसके बाद कुछ भी साफ़ करने के लिए रिबूट की आवश्यकता के बिना अनिश्चित काल तक चल सकता है।

मेरे पास एक लिनक्स राउटर / फ़ायरवॉल / मेलस्वर / शेल बॉक्स (P3 450MHz, OCed to 500MHz) है जो नियमित रूप से सैकड़ों दिनों के अपटाइम को देखता है। मैं केवल बिजली डोरियों को पुनर्व्यवस्थित करने, या एक असफल बिजली आपूर्ति को बदलने के लिए रीबूट करता हूं। यह शायद एक ही सीपीयू / रैम / हार्ड ड्राइव के साथ 15 वर्षों से स्थिर हो रहा है। मुझे कभी रिबूट नहीं करना पड़ा "क्योंकि यह अस्थिर हो रहा था"। यह हमेशा एक विशिष्ट कारण के लिए था, जैसे बिजली की आपूर्ति में विफलता, या कर्नेल अपग्रेड, या पावर आउटेज और मेरी यूपीएस बैटरी लगभग सूखा हुआ था (साथ में ऑटो शटडाउन चालू करना apcupsd)।

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

हार्डवेयर समस्याओं के लिए जाँच करने के लिए मेरा गो-संस्मरण mtest86 + बूट करना है। ( aptitude install memtest86+) उस पूर्ण मार्ग को चलाने दें, या रात भर चलाएं। यह एक स्थिर प्रणाली की गारंटी नहीं देता है, क्योंकि स्पाइक लोड पर बिजली की आपूर्ति वोल्टेज इन दिनों सीपीयू के साथ हो सकती है, और मेम्नेस्ट इस नियम को खारिज नहीं करेंगे। न ही यह आपके सीपीयू को प्राइम 95 की तरह गर्म करेगा।

Answer 7

मेरी मशीन केवल 15.04 के लिए फिर से शुरू हुई, 11 दिनों तक बिना किसी अजीब त्रुटियों के रहने के बाद, जिसे मैं याद कर सकता हूं। यदि आप किसी सिस्टम पर भारी काम और विकास कर रहे हैं, तो यह कभी-कभी रिबूट करने का एकमात्र विकल्प हो सकता है, लेकिन यह केवल कभी जरूरत के आधार पर होता है।

Comments

वास्तव में आप सही हैं! मैं 16.04 को कुछ महीनों के लिए विकसित कर रहा हूं। ठंड के कारण मैं अपना कंप्यूटर आमतौर पर हर दिन पुनः आरंभ करता हूं। लेकिन मुझे यकीन है कि कारण वही है जो मैंने स्थापित किया है और मैं और ड्राइवरों आदि का उपयोग करता हूं

— एफफेकन

Answer 8

तकनीकी रूप से इसकी कोई सीमा नहीं है। आपको बस इसे सोने या बंद नहीं करने के लिए सेट करना होगा।

Comments

क्या आप कृपया अपना उत्तर स्पष्ट और विस्तृत कर सकते हैं? विशेष रूप से इस लाइन you just have to set it to not sleep or shut down।

— heemayl

"तकनीकी रूप से कोई सीमा नहीं है" एक संक्षिप्त उत्तर, संक्षिप्त और सही के रूप में पर्याप्त होता।

— लीओ लैम

Answer 9

व्यक्तिगत रूप से मैं अपने लैपटॉप या पीसी को रिबूट करने या इसे बंद करने के दिनों के लिए नहीं चलाना चाहता।

केवल इसलिए कि गर्मी उत्पन्न करने वाले मुख्य घटक एमबी पर पहनने और आंसू को गति दे सकते हैं।

(यदि आपके पास उचित शीतलन और वेंटिलेशन नहीं है)

Comments

अगर यह एसर या एचपी जैसा उपभोक्ता-ग्रेड कचरा है, लेकिन बिजनेस-ग्रेड थिंकपैड या डेल अक्षांश लैपटॉप आमतौर पर बेहतर होते हैं; मेरे पास व्यक्तिगत रूप से अभी एक वर्ष से अधिक समय के लिए 24x7 चलने वाला अक्षांश है, यह मेरे ठीक बगल में है और अभी भी पूरी तरह से काम करता है।

@kingtoor ऐसा क्यों है बेहतर होगा कभी के साथ एक अपर्याप्त ठंडा मशीन को चलाने के लिए 24x7 रिबूट यह रिबूट के बिना 24/7 चलाने के लिए की तुलना में? (या यह कि आप क्या कहने का मतलब नहीं है?)

— एलियाह कागन

जब नीचे एक लैपटॉप पर उपयोग किया जाता है, जो 24/7 से चालू रहता है, तो गर्म हो जाता है। यह रिबूट करने के लिए असंबंधित है (बिना समय व्यतीत किए) बनाम निरंतर।

— पीटर कॉर्डेस

मेरा जवाब मेरी टिप्पणी में है।

— किंग्टूर 2:15

जब तक कि उनके पास सर्वर नहीं है, तब तक मुझे औसत उपयोगकर्ता के लिए अपने पीसी को 24/7 चलाने का कोई कारण नहीं दिखता है। ऐसी मेरी राय है।

— किंग्तूर

Answer 10

उबंटू के लिए विशिष्ट नहीं है, लेकिन मुझे एक डेबियन-आधारित डिस्ट्रो चलाने वाला 1997 का विंटेज लैपटॉप (300 मेगाहर्ट्ज, 288 एमबी रैम) मिला है, जो एकल प्रोग्राम (प्लस सिस्टम स्टफ और कोन्की) चलाते हुए 60 दिनों तक अपटाइम करता है। साप्ताहिक अपडेट लोड करने के लिए टर्मिनल को छोड़कर अन्य सॉफ़्टवेयर को प्रारंभ और बंद नहीं करना। आखिरकार, यह अपडेट लोड करते समय दुर्घटनाग्रस्त हो गया, लगभग 63 दिनों में। इसके विपरीत, मेरा कुबंटु 14.04 डेस्कटॉप सिस्टम लगभग दो सप्ताह बाद स्क्रीन लॉक में फ्रीज हो जाएगा। मैं अन्य उत्तरों से सहमत हूं; यह इस बारे में अधिक है कि आप किस सॉफ़्टवेयर को चलाते हैं और लिनक्स के बारे में की तुलना में आप अन्य कार्यक्रमों को कितनी बार शुरू और बंद करते हैं।

Comments

अगर यह दुर्घटनाग्रस्त हो गया (मेरा मतलब है कि हार्ड क्रैश या फ्रीज, न कि केवल एक्स क्रैशिंग, जो रिबूट किए बिना फिक्स करने योग्य है), इसका मतलब है कि हार्डवेयर की समस्या है (ओवरहीटिंग, खराब रैम, आदि)। एक sysadmin के रूप में, मेरे पास कभी-कभी मेरे सर्वर रिबूट किए बिना महीनों तक चल रहे होते हैं, हालांकि मैं इससे बचना पसंद करता हूं क्योंकि आपको कर्नेल अपडेट लागू करने के लिए रीबूट करने की आवश्यकता होती है।

जब स्क्रीन लॉक काली स्क्रीन हो गया है, तो यह बताने के लिए कोई प्रभावी तरीका नहीं है कि क्या यह एक हार्ड सिस्टम लॉक या एक्स सर्वर विफलता है - और एक्स को पुनरारंभ करने के लिए कमांड लाइन (पासवर्ड दर्ज करने की क्षमता के बिना) का उपयोग करने का कोई तरीका नहीं है। यह हो सकता है। मुझे लगता है कि अगर दो सप्ताह लगते हैं, तो मुझे लगता है कि यह ज़्यादा गरम या खराब नहीं है।

— Zeiss Ikon

Ctrl + Alt + F1 काम नहीं करता है? और एक खराब ग्राफिक्स चालक अपराधी हो सकता है - उन्हें उच्च अपटाइम को ध्यान में रखते हुए परीक्षण नहीं किया जा सकता है, लेकिन लिनक्स निश्चित रूप से मुद्दों के बिना वर्षों तक चलने में सक्षम है।

मुझे सीटीएल-एएलटी-एफ 1 की कोशिश करनी होगी, अगर मैं इसे अगली बार याद कर सकता हूं तो मुझे स्क्रीन लॉक फ्रीज मिलेगा (मैं हार्ड रीसेट का उपयोग कर रहा हूं)। मुझे लगता है मैं तो startxएक्स सर्वर को पुनः आरंभ करने के लिए उपयोग करेंगे? या मुझे सेवा को पुनरारंभ करने के लिए एक विशेष कमांड का उपयोग करने की आवश्यकता है? मैं पुराने लिनक्स से अच्छी तरह से वाकिफ हूँ, कि "रेस्टार्ट कर्नेल अपग्रेड और हार्डवेयर इंस्टालेशन के लिए हैं।"

— ज़ीस आइकॉन

रूट के रूप में या एक सामान्य उपयोगकर्ता के रूप में लॉगिन करें और sudo का उपयोग करें, और इन निर्देशों