[Installation] Really slow startup

[jserafin]

I just recently installed Kubuntu, but startup to login is really long, and everything in general (like starting up programs), which I think is unusual for a clean install. I don't know for sure, but I think it might have something to do with this message I got for restarting the computer after installation (pic below).

https://imgur.com/a/C0fDesZ

I have the latest stable version, 19.04. Let me know if you need anything else.

[claydoh]

There could be all sorts of reasons, but I don't think what you see on the screen is necessarily related to to the slowdown; it might just be what was in the terminal when a slowdown was happening, as things are loaded in parallel.

Try using systemd to see what is slowing things down:
https://wiki.archlinux.org/index.php...ystemd-analyze

Here is my last reboot:

claydoh@claydoh-ideapad:~$ systemd-analyze blame          
    1min 52.532s fstrim.service
         30.083s NetworkManager-wait-online.service
          1.407s dev-mapper-neon\x2d\x2dvg\x2droot.device
          1.373s networkd-dispatcher.service
          1.050s keyboard-setup.service
          1.034s ModemManager.service
          1.000s udisks2.service
           731ms minidlna.service
           716ms systemd-resolved.service
           715ms accounts-daemon.service
           675ms loadcpufreq.service
           646ms systemd-journal-flush.service
           626ms mono-xsp4.service
           618ms grub-common.service
           601ms snapd.service
           581ms bluetooth.service
           580ms alsa-restore.service
           572ms avahi-daemon.service
           572ms gpu-manager.service
           571ms pppd-dns.service
           571ms thermald.service
           571ms rsyslog.service
           545ms apt-daily.service
           545ms NetworkManager.service
           522ms apt-daily-upgrade.service
           377ms lvm2-monitor.service
           348ms systemd-logind.service
           336ms systemd-udevd.service

Note I have a couple of slow points, one of which is not a common bootup activity (fstrim is doing a regular cleanup of my SDD iirc), and the other has an external networking issue I know about., but am too lazy and don't care if I fix or not. But you get the idea of what the output is like. You can also get an svg image graph of the bootup, but the command line puts the slow points right up front.


I don't even remember it taking that long to boot, but IU seldom reboot, so maybe I just didn't notice.

[jserafin]

Could you make some recommendations if I post my systemd-analyze output? I don't know what's necessary, and what I could live without.

[claydoh]

Post the top few lines, the longest ones are the important ones, and offer a place to research. Probably anything longer than a second. You probably need most things, it is just seeing what part is slow, and finding out why.

The NetworkManager-wait-online.service taking some time is a somewhat common occurrence, and that may be one that could be disabled if you are seeing this, if necessary. On my system it is because my 5ghz wifi has for some reason become slow to connect, and happens on multiple systems, including phones and Chromebooks, so it is a router issue for me.

[jserafin]

This is all the processes longer than a second.

          
        8.021s mpd.service
        7.752s NetworkManager-wait-online.service
        6.593s dev-sda2.device
        5.706s networkd-dispatcher.service
        5.433s ModemManager.service
        4.711s udisks2.service
        4.389s NetworkManager.service
        4.145s accounts-daemon.service
        3.232s gpu-manager.service
        3.099s wpa_supplicant.service
        3.098s grub-common.service
        2.973s apport.service
        2.308s upower.service
        2.273s rsyslog.service
        2.268s avahi-daemon.service
        2.243s bluetooth.service
        2.231s thermald.service
        2.229s iio-sensor-proxy.service
        2.197s systemd-logind.service
        2.150s pppd-dns.service
        1.534s polkit.service
        1.523s systemd-journal-flush.service
        1.231s systemd-tmpfiles-setup.service
        1.148s apparmor.service
        1.024s snapd.service

[claydoh]

what sort of system specs do you have?
*Everything* seems slow, so it may not be software.
The top one is mpd (Media Player Daemon), which I *think* is used by cantata. You might try ditching both and trying a different music player, that does not run as a service. if you have a lower spec system, or a slow network, it might be overkill flor normal desktop use.

Also, I forgot to ask for the simple output of systemd-analyze to see total boot time to login, as even though those times you posted are long, they are run in parallel.

[jserafin]

Here is the specs and the output of "systemd-analyze"

jserafin@jserafin-Q502LAB:~$ sudo lshw -short
H/W path       Device     Class          Description
====================================================
                        system         Q502LAB (ASUS-NotebookSKU)
/0                        bus            Q502LAB
/0/0                      memory         64KiB BIOS
/0/e                      memory         32KiB L1 cache
/0/f                      memory         32KiB L1 cache
/0/10                     memory         256KiB L2 cache
/0/11                     memory         3MiB L3 cache
/0/12                     processor      Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
/0/14                     memory         8GiB System Memory
/0/14/0                   memory         4GiB SODIMM DDR3 Synchronous 1600 MHz (0
/0/14/1                   memory         4GiB SODIMM DDR3 Synchronous 1600 MHz (0
/0/100                    bridge         Broadwell-U Host Bridge -OPI
/0/100/2                  display        HD Graphics 5500
/0/100/3                  multimedia     Broadwell-U Audio Controller
/0/100/4                  generic        Broadwell-U Processor Thermal Subsystem
/0/100/14                 bus            Wildcat Point-LP USB xHCI Controller
/0/100/14/0    usb1       bus            xHCI Host Controller
/0/100/14/0/3             input          USB Receiver
/0/100/14/0/4             communication  Bluetooth wireless interface
/0/100/14/0/5             multimedia     USB2.0 HD UVC WebCam
/0/100/14/0/7             input          SiS HID Touch Controller
/0/100/14/0/8             generic        USB2.0-CRW
/0/100/14/1    usb2       bus            xHCI Host Controller
/0/100/16                 communication  Wildcat Point-LP MEI Controller #1
/0/100/1b                 multimedia     Wildcat Point-LP High Definition Audio C
/0/100/1c                 bridge         Wildcat Point-LP PCI Express Root Port #
/0/100/1c.2               bridge         Wildcat Point-LP PCI Express Root Port #
/0/100/1c.2/0  enp2s0     network        RTL8111/8168/8411 PCI Express Gigabit Et
/0/100/1c.3               bridge         Wildcat Point-LP PCI Express Root Port #
/0/100/1c.3/0  wlp3s0     network        Wireless 7260
/0/100/1f                 bridge         Wildcat Point-LP LPC Controller
/0/100/1f.2               storage        Wildcat Point-LP SATA Controller [AHCI M
/0/100/1f.3               bus            Wildcat Point-LP SMBus Controller
/0/100/1f.6               generic        Wildcat Point-LP Thermal Management Cont
/0/1           scsi0      storage        
/0/1/0.0.0     /dev/sda   disk           1TB ST1000LM048-2E71
/0/1/0.0.0/1   /dev/sda1  volume         511MiB Windows FAT volume
/0/1/0.0.0/2   /dev/sda2  volume         931GiB EXT4 volume

jserafin@jserafin-Q502LAB:~$ systemd-analyze
Startup finished in 5.840s (firmware) + 1.722s (loader) + 5.610s (kernel) + 23.088s (userspace) = 36.262s 
graphical.target reached after 23.071s in userspace

[claydoh]

That's not terribly slow, imo, not from a spinning 5400 rpm drive, I don't think. Most of the time is spent getting to the desktop, which is sort of a quirk of Plasma, but also maybe the mpd spooling up, too, depending on when it loads. The svg output option of systemd-analyze can graphically show when and how long bits are taking

Though I have the same cpu and a similar spinning drive, but I boot off an inexpensive nvme SSD. I'll try rebooting after I finish some tasks and see how long mine takes with a clean reboot.

[oshunluvr]

Wow Claydoh, 1 min 53 secs to run fstrim as a service? Why not as a cron job instead?

[oshunluvr]

Wow Claydoh, 1 min 53 secs to run fstrim as a service? Why not as a cron job instead?

Actually, it might just have been a timing thing. Seems that trim is enabled by systemd as a weekly event. So maybe it was just "your time." :-)

[claydoh]

Wow Claydoh, 1 min 53 secs to run fstrim as a service? Why not as a cron job instead?

Dunno, it just happened automatically.

[claydoh]

Actually, it might just have been a timing thing. Seems that trim is enabled by systemd as a weekly event. So maybe it was just "your time." :-)

Looks that way. I don't normally reboot at all unless there is a kernel update. I also don't run fstrim very often either, it sorta shows
Anyhoo:

claydoh@claydoh-ideapad:~$ systemd-analyze
Startup finished in 2.641s (firmware) + 3.653s (loader) + 11.515s (kernel) + 6.878s (userspace) = 24.689s
graphical.target reached after 6.407s in userspace

and

claydoh@claydoh-ideapad:~$ systemd-analyze blame
          6.974s apt-daily.service
          2.966s systemd-journal-flush.service
          2.859s dev-mapper-neon\x2d\x2dvg\x2droot.device
          1.912s snapd.service
           768ms dev-loop5.device
           763ms dev-loop1.device
           759ms networkd-dispatcher.service
           757ms apt-daily-upgrade.service
           742ms NetworkManager.service
           710ms dev-loop7.device
           704ms dev-loop2.device
           700ms dev-loop6.device
           683ms dev-loop10.device
           667ms udisks2.service
           652ms dev-loop4.device
           519ms systemd-udevd.service
           470ms lvm2-monitor.service
           446ms tlp.service

[jserafin]

Wait, I disabled mpd.service and the boot time only slightly went down? How come I didn't get the full 8s?

[claydoh]

Wait, I disabled mpd.service and the boot time only slightly went down? How come I didn't get the full 8s?

Because things are not loaded one-at-a-time, they start in parallel. if you use the svg image output option for systemd-analyze, you can see how many things are starting simultaneously.

[claydoh]

Also, running systemd-analyze critical-chain might help shed some light as it shows which things are bottlenecking other startup items