Длительная задержка после загрузки - upower.service требует 26 секунд

10

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

Система зависает на экране входа в систему, что похоже на 30 секунд. Курсор мыши и экран полностью заморожены. После этого система работает нормально.

Верхний вывод systemd-analyze blame равен ...

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

Googling upower.service кажется, что большинство людей видят менее двух. Как я могу определить, почему upower.service занимает так много времени при загрузке?

спасибо!

    
задан vanboom 01.05.2016 в 16:32
источник

3 ответа

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)

  • Я установил дополнительное оборудование? (то есть новый драйвер устройства)

  • Я установил дополнительные пакеты или обновил определенные пакеты?

  • Какое оборудование используется? Проблемы с аппаратным обеспечением?

В вопросе не было ни одной из этих данных, что означает невозможность определить первопричину для чего-то, чего мы не знаем. Отсутствие информации - это ошибка для любых попыток решения проблем.     

ответ дан clearkimura 21.09.2016 в 17:16
0

Измените /etc/journald.conf и добавьте постоянное хранилище. Это сохранит ваши журналы из предыдущих сборников.

С помощью этой функции вы можете затем просмотреть журналы из предыдущих загрузок для службы upower:

journalctl -b -1 -u upower.service

Вы можете отключить постоянное ведение журнала, как только закончите, поскольку оно будет использовать много дискового пространства.     

ответ дан Amias 16.09.2016 в 13:35
0

У меня была такая же проблема с обслуживанием upower.service, требующим 63 секунды. Потому что у меня есть настройка с двойной загрузкой и требуется частая переключение, это сводило меня с ума. Чтение на сайте upower.freedesktop не выявило каких-либо признаков того, что происходит.

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

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

Итак, мое время загрузки очень быстро. Во-первых, я снова установил upower (который ничего не изменил). Затем я переустановил драйверы nvidia & amp; Я также снова установил плазму, и это, похоже, решило проблему. Я заметил, что установка с двумя мониторами была медленной для загрузки в начале, с плазмой (я использую 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
    
ответ дан marts 17.09.2016 в 20:51