सॉफ्टवेयर और अपडेटर Ubuntu 16.04 में 100% CPU खपत करता है

Question

मैंने अपना लैपटॉप (लेनोवो Z50-70) अपग्रेड किया है जिसमें 15.10 से i7 सीपीयू और 8 गीगाहर्ट्ज रैम उबंटू 16.04 है। मैं लगातार अपडेट इंस्टॉल कर रहा हूं। मैं Gnome डेस्कटॉप वातावरण (GDM) के साथ ubuntu का उपयोग कर रहा हूं।

हाल ही में मैं एक अजीब समस्या का सामना कर रहा हूं, मेरे सीपीयू (सभी 4 कोर सहित) 100% कुछ प्रक्रियाओं द्वारा उपयोग किए जाते हैं जैसे gnome-software(ग्नोम सॉफ्टवेयर) और fwupd(फर्मवेयर अपडेट डेमॉन)। इससे मेरा काम कम हो जाता है। अगर मैं उन प्रक्रियाओं को मार भी दूं, तो वे फिर से शुरू कर रहे हैं।

क्या इन प्रक्रियाओं का कोई समाधान मेरे CPU के 100% का उपयोग नहीं करने के लिए है। और मैं cpulimitउन प्रक्रियाओं के लिए सीपीयू की राशि का प्रावधान करने के लिए उपयोगिता का उपयोग करते हुए जवाब नहीं चाहता हूं । मुझे उबंटू में यह एक मुख्य समस्या लगती है, मुझे समस्या के वास्तविक समाधान की उम्मीद है।

मैंने अब तक जो भी कोशिश की है, वह उन पीपीए को हटा रहा है जो अपडेट की जाँच के लिए आधिकारिक पीपीए को छोड़कर जोड़ा गया है। यह काम नहीं किया! htopइन प्रक्रियाओं की स्क्रीन का एक स्क्रीनशॉट संलग्न ।

Comments

शायद एक बग रिपोर्ट दर्ज करनी चाहिए।

— मिखावतवर

@mikewhatever मैं उम्मीद कर रहा हूँ कि मुझे कुछ संकेत या सुझाव आकर पूछ सकते हैं, अगर मैं बग रिपोर्ट दर्ज नहीं करने जा रहा हूँ या शायद कुछ विकल्प आज़माऊं।

— kisanme

dmesgएक कमांड है जो आप टाइप करेंगे जो लॉग आउटपुट करेगा।

— डोरियन

आपको /var/log/apt/history.logउस निर्देशिका में अन्य लॉग फ़ाइलों की भी जाँच करनी चाहिए जैसे कि /var/log/apt/term.logया /var/log/dpkg.logसभी जगह जो सुराग और त्रुटियों की तलाश में हैं।

— डोरियन

एक बग पोस्ट किया गया है जो संबंधित हो सकता है: बग्सलाउंचपड.नेट

— +

Answer 1

एक समान मुद्दा था।

जैसा कि अन्य उत्तर में उल्लेख किया गया है - समस्या को देखते हुए निर्धारित करना संभव है /var/log/syslog।

मेरे लॉग के भीतर gnome-settings निम्नलिखित रिपोर्ट कर रहा था:

(gnome-settings-daemon:3584): dconf-CRITICAL **: unable to create file '/home/USER/.cache/dconf/user': Permission denied.

इसे ठीक करने के लिए मैंने निम्नलिखित कमांड चलाई, USER को अपने उपयोगकर्ता नाम से बदलें:

sudo chown USER /home/USER/.cache/dconf

Answer 2

मैं वास्तव में एक ही मुद्दा था, एक ही प्रक्रिया CPU का 100% ले रही है। मेरे Ubuntu (16.04) में सॉफ्टवेयर को अपग्रेड करने के लिए मेरे लिए क्या काम किया गया था:

sudo apt-get update
sudo apt-get upgrade

उसके बाद मैंने अपने पीसी को रिबूट किया और अब यह मुद्दा समाप्त हो गया है।

Answer 3

मैं इसे syslog ( /var/log/syslog) की जाँच करके हल करने में कामयाब रहा । यह पागलों की तरह लॉग कर रहा था कि यह फाइल नहीं बना सके /home/<my user>/.cache/dconf/user। जब मैंने इस फ़ोल्डर को सही अनुमतियाँ दीं, तो यह इस CPU का उपयोग करना बंद कर दिया।

Comments

«सही अनुमतियाँ» यह एक अच्छा विचार है कि आपको कौन सी अनुमतियाँ शामिल हैं और उन्हें जारी करने के लिए आपने जो आदेश जारी किया है।

— एंड्रिया लज्जाज़ारो

वह फ़ोल्डर मेरी मशीन पर भी मौजूद नहीं है।

— एलेक्सिस विल्के 22

Answer 4

मेरे लिए अनुमति समस्या।

देखना:

$ cat /var/log/syslog

(सूक्ति-सॉफ़्टवेयर: ३ )१२): dconf-CRITICAL **: फ़ाइल बनाने में असमर्थ '/home/कैलूसरप्रोडक्शंस/.cache/dconf/user': Permiso denegado। dconf ठीक से काम नहीं करेगा।

इस आदेश को निष्पादित करने से समस्या हल हो गई।

$ sudo chown {user} /home/{user}/.cache/dconf

Answer 5

एक मामला हो सकता है जब सेवा से संबंधित कुछ भी नहीं होता है, जिस स्थिति में आप बस इसे पुनः आरंभ करना चाहते हैं। सेवाओं को देखने और उन्हें मैन्युअल रूप से मारने से बचने के लिए, आप बस उपयोग कर सकते हैं systemctl:

sudo systemctl restart fwupd

Comments

इसने मेरे लिए काम किया। मेरे पास /home/[user]/.cacheऊपर सूचीबद्ध फ़ोल्डर समस्याएँ नहीं थीं।

— मेवप्लप

Answer 6

fwupdमेरे साथ यह समस्या आज एक कंप्यूटर पर हुई। मेरे पास gnome-softwareदौड़ने के दो उदाहरण भी थे । सभी में, 2 सीपीयू 100% पर क्लैंप किए गए थे।

उस तबाही को जल्दी से रोकने के लिए, मैं सिर्फ उन 3 प्रक्रियाओं को मार सकता था:

ps -ef | less
(find processes in the list, record their PID)

kill <pid1>
kill <pid2>
kill <pid3>
...

(आप भी कोशिश कर सकते हैं killall gnome-softwareऔर killall fwupd, मुझे लगता है कि killallकमांड खतरनाक है ... अन्यथा, htopआप बस F9 का उपयोग कर सकते हैं। पुष्टि करने से पहले, सुनिश्चित करें कि सही प्रक्रिया का चयन किया गया था!)

अब, @belacqua ने हमें लॉन्चपैड पर निम्नलिखित बग रिपोर्ट की ओर इशारा किया:

https://bugs.launchpad.net/ubuntu/+source/appstream-glib/+bug/1591868

मुझे टिप्पणी 18 विशेष रूप से दिलचस्प लगी:

https://bugs.launchpad.net/ubuntu/+source/appstream-glib/+bug/1591868/comments/18

व्यक्ति कहता है कि समस्या प्रजनन योग्य नहीं है, लेकिन अगर आपको apt-get (as, सॉफ़्टवेयर अपडेट / इंस्टॉलेशन) के साथ समस्या थी, तो इसकी वजह से यह बहुत अच्छी तरह से हो सकता है। और वास्तव में, मेरे पास apt कैश में कई फाइलें थीं जो कुल बकवास थीं (यानी मेरा इंटरनेट कनेक्शन कुछ दिनों पहले विफल हो गया था और कुछ कैश फ़ाइलों में अपेक्षित पैकेज सूचियों के बजाय HTTP 302 त्रुटि शामिल थी।) मुझे यह विशिष्ट टिप्पणी मिली। दिलचस्प है क्योंकि एक बग अभी भी है, लेकिन यमल फ़ाइल के कारण नहीं है जैसा कि वहां निर्दिष्ट है। मेरे मामले में, मुझे कहीं भी कोई यमल फ़ाइल नहीं मिली।

मैं शर्त लगाता हूं कि कैश को ठीक करकेapt-get , मैंने समस्या को ठीक कर दिया है। ऐसा लगता है कि कोड कुछ समय पहले ही तय हो गया था। मुझे केवल यह पुष्टि करने के लिए एक रिबूट की आवश्यकता है कि यह 100% सीपीयू उपयोग फिर से नहीं होता है।

Answer 7

मेरे साथ भी यही समस्या है, इसने मेरी प्रणाली को भी अवरुद्ध कर दिया है।

परिवर्तन के स्वामी के बाद /home/{user}/.cache/dconf/user, यह सामान्य दिखता है।