I updated on August 3rd, 2024, and ever since when I restart it ALWAYS takes several times longer to start from when the word KUBUNTU appears on the splash screen to when the desktop appears. Where are the logs so I can post them to my Pastebin account or somewhere else so you can see them?
Announcement
Collapse
No announcement yet.
Kubuntu takes a long time to start after update
Collapse
X
-
Open Konsole and run the command systemd-analyze, and/or systemd-analyze blame, and systemd-analyze critical-chain to see some interesting boot info.
Copy/paste each ones output in your reply (put the output between CODE tags (the # icon)Windows no longer obstructs my view.
Using Kubuntu Linux since March 23, 2007.
"It is a capital mistake to theorize before one has data." - Sherlock Holmes
- Top
- Bottom
- Likes 1
-
Originally posted by Snowhog View PostOpen Konsole and run the command systemd-analyze, and/or systemd-analyze blame, and systemd-analyze critical-chain to see some interesting boot info.
Copy/paste each ones output in your reply (put the output between CODE tags (the # icon)
Just to remind users and devs that Ubuntu and its flavors have a long way to go to be as usr friendly as they should be.
http://www.kubuntu.org/getkubuntu
- Top
- Bottom
Comment
-
vince@steven-tobefilledbyoem:~$ systemd-analyze
Startup finished in 10.085s (firmware) + 30.462s (loader) + 1.907s (kernel) + 1min 33.031s (userspace) = 2min
15.488s
graphical.target reached after 1min 33.018s in userspace.
vince@steven-tobefilledbyoem:~$ systemd-analyze blame
2min 43.518s fstrim.service
1min 25.682s systemd-udev-settle.service
8.200s apt-daily.service
5.437s NetworkManager-wait-online.service
2.512s fwupd.service
2.496s apt-daily-upgrade.service
2.191s thermald.service
1.118s NetworkManager.service
1.004s home-vince-Mount-Steam1.mount
824ms dev-sdc2.device
647ms man-db.service
586ms apport.service
555ms snapd.seeded.service
479ms snapd.service
435ms apparmor.service
424ms dev-loop1.device
405ms dev-loop2.device
363ms e2scrub_reap.service
359ms systemd-journal-flush.service
341ms accounts-daemon.service
336ms logrotate.service
335ms systemd-tmpfiles-setup.service
335ms systemd-binfmt.service
325ms plymouth-read-write.service
321ms udisks2.service
319ms console-setup.service
310ms ufw.service
303ms dev-loop5.device
299ms dev-loop6.device
298ms dev-loop4.device
286ms rsyslog.service
281ms power-profiles-daemon.service
278ms apport-autoreport.service
275ms smartmontools.service
272ms polkit.service
262ms dev-loop3.device
234ms avahi-daemon.service
233ms user@1000.service
231ms gpu-manager.service
211ms grub-common.service
200ms dbus.service
190ms dev-loop7.device
183ms systemd-udev-trigger.service
177ms dev-loop10.device
175ms switcheroo-control.service
169ms systemd-logind.service
168ms systemd-modules-load.service
157ms update-notifier-download.service
152ms dev-loop0.device
142ms plymouth-quit.service
133ms ModemManager.service
128ms sysstat.service
127ms dev-loop8.device
120ms upower.service
111ms systemd-resolved.service
109ms sysstat-summary.service
107ms keyboard-setup.service
104ms fwupd-refresh.service
102ms dev-loop9.device
94ms systemd-journald.service
88ms systemd-udevd.service
83ms wpa_supplicant.service
71ms snapd.apparmor.service
61ms lvm2-monitor.service
61ms dpkg-db-backup.service
57ms nvidia-persistenced.service
57ms systemd-timesyncd.service
56ms grub-initrd-fallback.service
52ms systemd-random-seed.service
48ms snap-bare-5.mount
47ms snap-core22-1380.mount
44ms snap-firefox-4630.mount
43ms systemd-fsck@dev-disk-by\x2duuid-1ECC\x2d72A0.service
41ms plymouth-start.service
40ms snap-firefox-4650.mount
39ms snap-firmware\x2dupdater-127.mount
38ms dev-hugepages.mount
37ms dev-mqueue.mount
37ms snap-gnome\x2d42\x2d2204-176.mount
37ms sys-kernel-debug.mount
36ms systemd-tmpfiles-clean.service
36ms systemd-tmpfiles-setup-dev.service
35ms snap-gtk\x2dcommon\x2dthemes-1535.mount
34ms sys-kernel-tracing.mount
33ms systemd-remount-fs.service
29ms kerneloops.service
28ms snap-snapd-21465.mount
28ms modprobe@drm.service
28ms kmod-static-nodes.service
27ms cups.service
26ms modprobe@fuse.service
25ms snap-snapd-21759.mount
25ms systemd-tmpfiles-setup-dev-early.service
25ms modprobe@configfs.service
24ms snap-thunderbird-490.mount
23ms home.mount
21ms snap-thunderbird-497.mount
20ms alsa-restore.service
19ms boot-efi.mount
18ms var-snap-firefox-common-host\x2dhunspell.mount
17ms rtkit-daemon.service
17ms update-notifier-motd.service
16ms proc-sys-fs-binfmt_misc.mount
16ms tmp.mount
14ms sys-fs-fuse-connections.mount
14ms user-runtime-dir@1000.service
14ms swap-swapfile.swap
11ms systemd-update-utmp.service
11ms systemd-update-utmp-runlevel.service
11ms swap.mount
9ms systemd-sysctl.service
9ms sys-kernel-config.mount
8ms setvtrgb.service
7ms modprobe@efi_pstore.service
7ms systemd-user-sessions.service
7ms snapd.socket
6ms modprobe@loop.service
5ms sysstat-collect.service
4ms motd-news.service
3ms modprobe@dm_mod.service
3ms sddm.service
22us blk-availability.service
vince@steven-tobefilledbyoem:~$ ^[[200~systemd-analyze critical-chain~
systemd-analyze: command not found
vince@steven-tobefilledbyoem:~$
Just to remind users and devs that Ubuntu and its flavors have a long way to go to be as usr friendly as they should be.
http://www.kubuntu.org/getkubuntu
- Top
- Bottom
Comment
-
Big typo in that third command. You copied and pasted it from the browser rather than typing it.
This will never run: ^[[200~systemd-analyze critical-chain~
This will: systemd-analyze critical-chain
The "fstrim" service is taking a very long time. Usually, it settles downs after completing a full run on the device.
If not, you could turn off the service if it does this every boot. Then manually run trim using a cron job or adding "discard" option to fstab.
- Top
- Bottom
Comment
-
Originally posted by oshunluvr View PostBig typo in that third command. You copied and pasted it from the browser rather than typing it.
This will never run: ^[[200~systemd-analyze critical-chain~
This will: systemd-analyze critical-chain
The "fstrim" service is taking a very long time. Usually, it settles downs after completing a full run on the device.
If not, you could turn off the service if it does this every boot. Then manually run trim using a cron job or adding "discard" option to fstab.The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @1min 32.239s
└─multi-user.target @1min 32.239s
└─kerneloops.service @1min 32.213s +24ms
└─network-online.target @1min 32.202s
└─NetworkManager-wait-online.service @1min 27.523s +4.679s
└─NetworkManager.service @1min 26.351s +1.164s
└─dbus.service @1min 26.199s +108ms
└─basic.target @1min 26.186s
└─sockets.target @1min 26.186s
└─snapd.socket @1min 26.178s +7ms
└─sysinit.target @1min 26.168s
└─systemd-udev-settle.service @508ms +1min 25.658s
└─systemd-udev-trigger.service @330ms +174ms
└─systemd-udevd-kernel.socket @294ms
└─system.slice @269ms
└─-.slice @269ms
vince@steven-tobefilledbyoem:~$
Last edited by Snowhog; Aug 08, 2024, 07:21 AM.Just to remind users and devs that Ubuntu and its flavors have a long way to go to be as usr friendly as they should be.
http://www.kubuntu.org/getkubuntu
- Top
- Bottom
Comment
-
A Google search has me thinking a user service is set up as a system service. I haven't changed anything lately so possibly a bad update. Could it have something to do with the Linux firmware?Just to remind users and devs that Ubuntu and its flavors have a long way to go to be as usr friendly as they should be.
http://www.kubuntu.org/getkubuntu
- Top
- Bottom
Comment
-
Originally posted by steve7233 View PostA Google search
What does it being a user vs system service have to do with it?
The only thing that is taking time is the running of fstrim
All the other things that add significant time (the red + numbers) are related to this (systemd-udev-settle.service is waiting for the trim to finish iirc)
Is this running with every boot?
If so, it may be worth disabling the fstrim service as oshunluvr mentions.
Or maybe look at why it needs to trim very often. Lot and lots of large file deletes, etc?
Lots of snapshot rollbacks to points where a trim is scheduled/necessary?
Just random guesses.
The issue is not *buntu specific, and I wonder if it could be a drive issue.Last edited by claydoh; Aug 08, 2024, 03:03 AM.
- Top
- Bottom
Comment
-
Originally posted by claydoh View PostNo link or evidence that support this? We can't give hints related to this without info. Sigh.
What does it being a user vs system service have to do with it?
The only thing that is taking time is the running of fstrim
All the other things that add significant time (the red + numbers) are related to this (systemd-udev-settle.service is waiting for the trim to finish iirc)
Is this running with every boot?
If so, it may be worth disabling the fstrim service as oshunluvr mentions.
Or maybe look at why it needs to trim very often. Lot and lots of large file deletes, etc?
Lots of snapshot rollbacks to points where a trim is scheduled/necessary?
Just random guesses.
The issue is not *buntu specific, and I wonder if it could be a drive issue.Just to remind users and devs that Ubuntu and its flavors have a long way to go to be as usr friendly as they should be.
http://www.kubuntu.org/getkubuntu
- Top
- Bottom
Comment
-
How do I turn off a service at boot time?Just to remind users and devs that Ubuntu and its flavors have a long way to go to be as usr friendly as they should be.
http://www.kubuntu.org/getkubuntu
- Top
- Bottom
Comment
-
I did a Google search. Is the following command correct for Kubuntu 24.04? systemctl disable service
Source _= https://superuser.com/questions/2038...-auto-startingLast edited by steve7233; Aug 08, 2024, 02:43 PM.Just to remind users and devs that Ubuntu and its flavors have a long way to go to be as usr friendly as they should be.
http://www.kubuntu.org/getkubuntu
- Top
- Bottom
Comment
-
Originally posted by claydoh View Postsystemctl disable service
But also
systemctl mask service.Just to remind users and devs that Ubuntu and its flavors have a long way to go to be as usr friendly as they should be.
http://www.kubuntu.org/getkubuntu
- Top
- Bottom
Comment
-
You need to use both to prevent other services from running or calling the disabled service as a dependency.
Disabling just prevents it from running automatically on its own during boot.
Here's a better description
https://askubuntu.com/questions/8162...temctl-disable
- Top
- Bottom
Comment
-
Yesterday's update seems to have fixed this. I am guessing since I use BTRFS then one or more of the BTRFS fixes must have fixed this issue.Just to remind users and devs that Ubuntu and its flavors have a long way to go to be as usr friendly as they should be.
http://www.kubuntu.org/getkubuntu
- Top
- Bottom
Comment
Comment