Тривале затримка після завантаження - upower.service вимагає 26 с


11

Я намагаюся визначити першопричину затримки після завантаження. Наразі використовується Ubuntu 16.10 LTS, але така ж проблема виникала і в попередніх версіях ще до 14-ти.

Система висить на екрані входу протягом 30 секунд. Курсор миші та екран повністю заморожені. Після цього система працює нормально.

Найвищий вихід systemd-analyze blame...

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

Гугл уповер.сервіс здається, що більшість людей бачать менше 2-х. Як я можу визначити, чому Upower.service так довго запускається під час завантаження?

Спасибі!

Відповіді:


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. Ця команда надрукує, чи працює сервіс в даний час чи ні, а також надрукує відповідний журнал з останнього завантаження.

Приклад виведення 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.

Проста перевірка : чи є якісь додаткові пристрої, які без видимих ​​причин залишаються підключеними до комп'ютера? Будь-який невинний пристрій, наприклад смартфон, підключений до порту USB, може сповільнити або навіть перешкодити процесу завантаження комп'ютера.

Система висить на екрані входу протягом 30 секунд. Курсор миші та екран повністю заморожені. Після цього система працює нормально.

Точка зміни : вищезазначене запитання виявляло лише симптоми, які навряд чи говорять окрім повільності завантаження системи.

Замість того, щоб описувати затримку, спробуйте задати собі будь-яке з наступних питань:

  • Коли процес завантаження почав сповільнюватися?

  • Що нещодавно змінилося з моїм комп’ютером? Такі як оновлення або налаштування BIOS.

  • Я встановив додаткове обладнання? Наприклад, новий драйвер пристрою.

  • Я встановив додаткові пакети чи оновив певні пакети?

  • Який тип обладнання використовується? Чи обладнання викликає проблеми?

Питання не містило жодної з цих відомостей, що означає неможливе визначення першопричини того, чого ми не знаємо. Брак інформації - це гріх для будь-яких спроб вирішення проблеми.


0

Відредагуйте /etc/journald.confта додайте постійне сховище. Це збереже ваші журнали від попередніх збірок.

Якщо це ввімкнено, ви зможете перевірити журнали попередніх чобіт на службу спокура:

journalctl -b -1 -u upower.service

Можливо, ви захочете вимкнути постійний журнал, коли ви закінчите, оскільки він буде використовувати велику кількість дискового простору.


Очевидно, що це не буде робити журнали з чобіт, перш ніж ви включили цю опцію, це не магія.
Амія

0

У мене була така ж проблема з upower.service, який вимагав 63 секунди. Оскільки у мене є налаштування подвійної завантаження і потрібні часті перемикання, це зводило мене з розуму. Читання на веб-сайті upower.freedesktop не виявило жодних підказок щодо того, що відбувається.

Мені вдалося вирішити проблему, хоч і ненавмисно. systemd-analyze blameтепер виводи:

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

Тож час мого завантаження зараз дуже швидкий. По-перше, я знову встановив upower (який нічого не змінив). Потім я перевстановив драйвери nvidia і я також знову встановив плазму - і це, здається, вирішило проблему. Я помітив, що налаштування подвійного монітора спочатку повільно завантажувався, плазма (я використовую Kubuntu 16.04) часто забуває про налаштування. Якщо ви перебуваєте в google 'ubuntu slow boot nvidia', ви отримуєте досить багато звернень, і це змусило мене зняти це.

Я пишу цю відповідь, сподіваючись, що це може допомогти іншим повторити успіх. Для перевстановлення upower я дотримувався цього керівництва: натисніть

#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

ОП не заявив, чи є у нього карта Nvidia або Radeon чи ні. А якщо карта Nvidia, він не пережив, якщо він використовує бінарні файли або відкритий код. Я пропоную, що ваша відповідь стосується вашої платформи, яка може не мати нічого спільного з його. Тільки запитавши його, що це за його платформа, ми дізнаємось точно.
WinEunuuchs2Unix
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.