I am trying to determine the root cause of a delay after booting. Currently using Ubuntu 16.10 LTS, but the same issue was occurring on previous versions back to 14.

The system hangs at the login screen for what seems like 30 seconds. The mouse cursor and screen are completely frozen. After that the system works normally.

The top output of systemd-analyze blame is ...

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

Googling upower.service seems like most people are seeing less than 2s. How can I determine why upower.service is taking so long on bootup?

thanks!

share|improve this question
    
+1 This question is quite challenging. Running man upower in Terminal will present a very short manual page, then one will soon notice this: TODO: not fully documented in both 14.04 and 16.04 releases. – clearkimura Sep 19 '16 at 14:43

Take a step further to see more output using systemd-analyze command that is appended with critical-chain. This command supposedly "prints a tree of the time-critical chain of units".

Example output from systemd-analyze commands, which are relevant to 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

Related command to check

If above output still doesn't give any hint to you, use another command systemctl status SERVICE to see related output for target SERVICE. This command will print whether the SERVICE is currently running or not, and also print relevant log from the last boot.

Example output of systemctl command, which is relevant to 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.

What if that device...

A simple check: Is there any additional device that remain connected to your computer for no apparent reason? Any innocent device, such as a smartphone connected to USB port, may slow down or even interfere the boot process of your computer.

The changing point

The system hangs at the login screen for what seems like 30 seconds. The mouse cursor and screen are completely frozen. After that the system works normally.

In the question above, only the symptoms were revealed, which hardly tells anything other than the slowness of loading the system.

Instead of describing the delay, consider asking yourself any of the following questions:

  • When the boot process started to slow down?

  • What did recently change with my computer? (i.e. BIOS update or customization)

  • Did I install additional hardware? (i.e. new device driver)

  • Did I install additional packages or upgrade particular packages?

  • What type of hardware is used? Is the hardware causing issues?

The question had none of these information, which means impossible to determine the root cause for something we don't know. Lack of information is a pitfall to any attempts of problem solving.

share|improve this answer

Edit your /etc/journald.conf and add persistent storage. This will preserve your logs from previous builds.

With this enabled you can then examine the logs from previous boots for the upower service:

journalctl -b -1 -u upower.service

You might want to disable persistent logging once you have finished as it will use up a lot of diskspace.

share|improve this answer
    
obviously this wont make logs from boots before you enabled this option appear, its not magic. – Amias Sep 19 '16 at 10:47

I had the same problem with upower.service requiring 63 seconds. Because I have a dualboot setup and require frequent switching, this drove me insane. Reading up on the upower.freedesktop website did not reveal any clues as to what is going on.

I managed to solve the problem, albeit inadvertently. systemd-analyze blame now outputs:

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

So my boot-time is very fast now. First, I re-installed upower (which did not change anything). Then I reinstalled the nvidia drivers & I also re-installed plasma- and this seems to have solved the problem. I had noticed that the dual-monitor setup was slow to load at the beginning, with plasma (I use Kubuntu 16.04) frequently forgetting the setup. If you google 'ubuntu slow boot nvidia' you get quite a lot of hits, and that led me to give it a shot.

I write this answer in the hope that it may help others to replicate the success. For re-installing upower I followed this guide: click

#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
share|improve this answer
    
The OP hasn't stated if he has a Nvidia card or Radeon or neither. And if Nvidia card he hasn't sated if he is using binaries or open source. I suggest your answer applies to your platform which might have nothing to do with his. Only asking him what his platform is will we find out for sure. – WinEunuuchs2Unix Sep 21 '16 at 3:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.