বুটিনের পরে দীর্ঘ বিলম্ব - upower.service এর 26s প্রয়োজন


11

আমি বুটিংয়ের পরে বিলম্বের মূল কারণটি নির্ধারণ করার চেষ্টা করছি। বর্তমানে উবুন্টু 16.10 এলটিএস ব্যবহার করছে তবে পূর্ববর্তী সংস্করণগুলিতে 14 এ একই সমস্যা দেখা দিয়েছে।

30 সেকেন্ডের মতো লাগে এমনটির জন্য সিস্টেমটি লগইন স্ক্রিনে স্তব্ধ হয়ে যায়। মাউস কার্সার এবং স্ক্রিন সম্পূর্ণ হিমশীতল। এর পরে সিস্টেমটি স্বাভাবিকভাবে কাজ করে।

এর শীর্ষ আউটপুটটি systemd-analyze blameহ'ল ...

   26.653s upower.service
   6.890s NetworkManager-wait-online.service

গুগলিং আপওয়ার্স সার্ভিস দেখে মনে হচ্ছে বেশিরভাগ লোকেরা 2-এর কম দেখছে seeing আমি কীভাবে নির্ধারণ করতে পারি যে আপওয়ার্স.সার্ভিস বুটআপে এত দীর্ঘ সময় নিচ্ছে কেন?

ধন্যবাদ!

উত্তর:


1

systemd-analyzeযুক্ত হওয়া কমান্ডটি ব্যবহার করে আরও আউটপুট দেখতে আরও একটি পদক্ষেপ নিন critical-chain। এই কমান্ডটি "ইউনিটগুলির সময়-সমালোচনা শৃঙ্খলার একটি গাছ মুদ্রণ করে" বলে মনে হয়।

systemd-analyzeকমান্ডগুলি থেকে আউটপুট উদাহরণ , যা প্রাসঙ্গিক upower.service:

$ systemd-analyze blame | grep upower
           486ms upower.service

$ systemd-analyze critical-chain upower.service
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

upower.service +486ms
└─basic.target @16.023s
  └─sockets.target @16.023s
    └─snapd.socket @15.921s +55ms
      └─sysinit.target @15.920s
        └─apparmor.service @6.264s +9.629s
          └─local-fs.target @6.147s
            └─run-user-108.mount @36.705s
              └─local-fs-pre.target @6.147s
                └─systemd-remount-fs.service @6.051s +93ms
                  └─system.slice @2.394s
                    └─-.slice @2.389s

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

systemctlকমান্ডের আউটপুট উদাহরণ , যা প্রাসঙ্গিক upower.service:

$ systemctl status upower.service
● upower.service - Daemon for power management
   Loaded: loaded (/lib/systemd/system/upower.service; disabled; vendor preset: 
   Active: active (running) since Wed 2016-09-21 23:33:23 MYT; 1min 35s ago
     Docs: man:upowerd(8)
 Main PID: 967 (upowerd)
    Tasks: 3 (limit: 512)
   CGroup: /system.slice/upower.service
           └─967 /usr/lib/upower/upowerd

Sep 21 23:33:22 HOSTNAME systemd[1]: Starting Daemon for power management...
Sep 21 23:33:23 HOSTNAME systemd[1]: Started Daemon for power management.

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

30 সেকেন্ডের মতো লাগে এমনটির জন্য সিস্টেমটি লগইন স্ক্রিনে স্তব্ধ হয়ে যায়। মাউস কার্সার এবং স্ক্রিন সম্পূর্ণ হিমশীতল। এর পরে সিস্টেমটি স্বাভাবিকভাবে কাজ করে।

পরিবর্তনের পয়েন্ট : উপরের প্রশ্নটি কেবল লক্ষণগুলি প্রকাশ করেছে, যা সিস্টেম লোড করার ownিলেটি ছাড়া খুব কমই অন্য কিছু বলে।

বিলম্ব বর্ণনা করার পরিবর্তে, নিম্নলিখিত প্রশ্নগুলির নিজেকে জিজ্ঞাসা করুন:

  • বুট প্রক্রিয়াটি কমে যেতে শুরু করল কবে?

  • আমার কম্পিউটারের সাহায্যে সম্প্রতি কী পরিবর্তন হয়েছে? যেমন BIOS আপডেট বা কাস্টমাইজেশন।

  • আমি কি অতিরিক্ত হার্ডওয়্যার ইনস্টল করেছি? যেমন নতুন ডিভাইস ড্রাইভার।

  • আমি কি অতিরিক্ত প্যাকেজ ইনস্টল করেছি বা নির্দিষ্ট প্যাকেজগুলি আপগ্রেড করেছি?

  • কোন ধরণের হার্ডওয়্যার ব্যবহার করা হয়? হার্ডওয়্যার সমস্যা সৃষ্টি করে?

প্রশ্নটির মধ্যে এগুলির কোনও তথ্য ছিল না, যার অর্থ আমরা জানি না এমন কোনও কারণে এর মূল কারণ নির্ধারণ করা অসম্ভব। তথ্যের অভাব সমস্যা সমাধানের যে কোনও প্রয়াসের জন্য একটি সমস্যা।


0

আপনার সম্পাদনা করুন /etc/journald.confএবং অবিরাম স্টোরেজ যুক্ত করুন। এটি পূর্ববর্তী বিল্ডগুলি থেকে আপনার লগগুলি সংরক্ষণ করবে।

এই সক্ষম দ্বারা আপনি অত্যাধুনিক পরিষেবার জন্য পূর্ববর্তী বুটগুলির লগগুলি পরীক্ষা করতে পারেন:

journalctl -b -1 -u upower.service

একবারে কাজ শেষ করার পরে আপনি অবিচ্ছিন্ন লগিংটি অক্ষম করতে চাইতে পারেন কারণ এটি প্রচুর ডিস্কস্পেস ব্যবহার করবে।


স্পষ্টতই এই বিকল্পটি সক্ষম করার আগে বুটগুলি থেকে লগ তৈরি করা যাবে না, এটি যাদু নয়।
অমিয়াস

0

Up৩ সেকেন্ডের জন্য আপওয়ার.সওয়ারিসের আমার একই সমস্যা ছিল। যেহেতু আমার ডুয়াল বুট সেটআপ রয়েছে এবং ঘন ঘন স্যুইচিংয়ের প্রয়োজন হয়, এটি আমাকে উন্মাদ করে তুলেছিল। আপওয়ার.ফ্রিডেস্কটপ ওয়েবসাইটে পড়ার পরে কী চলছে তা সম্পর্কে কোনও ধারণা খুঁজে পাওয়া যায়নি।

অজান্তেই আমি সমস্যাটি সমাধান করতে পেরেছি। systemd-analyze blameএখন ফলাফল:

800ms snapd.firstboot.service
696ms wicd.service
...
250ms upower.service

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

আমি এই উত্তরটি এই আশায় লিখছি যে এটি অন্যকে সাফল্যের প্রতিরূপ করতে সহায়তা করতে পারে। পুনরায় ইনস্টল আপওয়ারের জন্য আমি এই গাইডটি অনুসরণ করেছি: ক্লিক করুন

#re-installing nvidia drivers
sudo apt-get purge nvidia-*
sudo apt-get install nvidia-current nvidia-settings

#uninstalling plasma
sudo apt-get purge kubuntu-desktop plasma-desktop
sudo apt-get autoremove

#installing plasma    
sudo apt-add-repository ppa:kubuntu-ppa/backports
sudo apt update && sudo apt full-upgrade -y

ওপি তার কাছে এনভিডিয়া কার্ড বা র‌্যাডিয়ন বা না থাকলেও তা জানায় না। এবং এনভিডিয়া কার্ড যদি সে বাইনারি বা ওপেন সোর্স ব্যবহার করে তবে সে সেট করেনি। আমি প্রস্তাব দিচ্ছি যে আপনার উত্তরটি আপনার প্ল্যাটফর্মে প্রযোজ্য যার সাথে তার কোনও সম্পর্ক নেই। তাঁর প্ল্যাটফর্মটি কী তা কেবল তাকে জিজ্ঞাসা করা আমরা নিশ্চিতভাবে খুঁজে বের করব।
WinEunuuchs2Unix
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.