I have upgraded to 24.10 (Oracular Oriole) … but it is very very slow to start, and when I open the terminal it can take 3-5 minutes before the terminal is ready to type anything in.
suggestions are welcomed
Cheers
Please post the output from running the following command in Terminal -
systemd-analyze blame
systemd-analyze blame is producing long long list
the top.
systemd-analyze blame
1min 5.699s postgresql@16-main.service
1min 1.811s e2scrub_reap.service
53.680s plymouth-quit-wait.service
47.362s docker.service
37.791s containerd.service
32.784s postfix@-.service
26.907s snapd.seeded.service
24.961s snapd.service
22.059s preload.service
20.226s apport.service
17.870s dev-sdb2.device
16.856s networkd-dispatcher.service
15.363s tor@default.service
14.070s user@1000.service
13.904s udisks2.service
13.427s polkit.service
13.195s accounts-daemon.service
12.797s NetworkManager.service
10.815s systemd-journal-flush.service
well, you can see where the 3-4 minutes is being spent according to blame: postgresql, e2scrub, plymouth, docker, containerd.
- The long-ish e2scrub might indicate a problem with your filesystems…
- Does postgresql always have to start at boot?
- docker & container might be something to look at, but, all of these could be issues caused by a filesystem problem.
Are you running Windows (and/or one/more of the filesystems isn’t native to linux) on this platform as well?
I only have linux on the machine
Also a dmesg should give information about the kernel times.
sudo dmesg
Look for a quite big jump in times.
Adding -T might be preferred to add timestamps to the output.
sudo dmesg -T
1 Like
Yes, that’s an option. But, when look for time jumps in boot, I prefer the dmesg alone as it’s visually more direct showing only the start in relative seconds.
1 Like
sudo dmesg –reltime
…can also be helpful. But, also:
sudo systemctl status e2scrub_reap.service
If this doesn’t reveal anything and e2scrub_reap.service continues to be the top entry in the “blame” list, you might try running a full filesystem check manually.
from man e2scrub :
e2scrub attempts to check (but not repair) all metadata in a mounted ext[234] file system if the file
system resides on an LVM logical volume. The block device of the LVM logical volume can also be passed
in.
are you actually using LVM ?
Note that e2scrub_reap.service is not limited to Logical Volume Management (LVM) systems - it operates on ext2/ext3/ext4 filesystems regardless of whether they’re part of an LVM setup or traditional partition layout.
ogra@styx:~$ grep Description /lib/systemd/system/e2scrub_reap.service
Description=Remove Stale Online ext4 Metadata Check Snapshots
ogra@styx:~$
Not sure how you do snapshots on an ext[2,3,4] system if it is not on LVM …
less /sbin/e2scrub_all
Right, so this script calls two functions by default to determine which filesystems to reap, ls_scan_targets() and ls_reap_targets() to then operate on the returned filesystem list of these functions …
both of these functions run lvs as the very first thing to find devices … so on systems that do not have lvm2 installed at all (pretty much every desktop system that has not been installed with lvm involvement) this script and its service is a simple no-op …
If you do have lvm2 installed but are not using it, it will not be a no-op though and the lvs and lsblk calls it does might slow down booting…
There’s a test near the top of the script:
readlink -q -s -e /dev/mapper/*.e2scrub* > /dev/null
What if something odd was going on with this test? i.e. the filesystem was munged? Couldn’t readlink hang or fail slowly?
But, yes, on my system:
systemd-analyze blame | fgrep e2scrub
32ms e2scrub_reap.service
However, OP has:
1min 1.811s e2scrub_reap.service
So, if your assertions are correct, the OP must have LVMs … In any case, this is part of the default set of services run at boot and the blame output does indicate an issue. If the service is simply disabled, the bootup might run faster… Is this the suggestion?
Dunno if I’m at a point to make suggestions yet based on the amount of data we have up to now … but one idea would be to hack the script and put a set -x at the top and inspect the journal for the output after a fresh boot …
BTW, google revealed:
https://lore.kernel.org/all/9d83dc52-dda8-6241-40ae-8a4fec4bb9eb@molgen.mpg.de/t/
That indicates that the lsblk calls slow it down and that Ted was planning to remove that… looking at my 24.10 here it seems we do still ship a version that has the lsblk calls though …
Take a look at launchpad bug Bug #2042301 “Windows are slow to open shortly after login under...” : Bugs : nvidia-graphics-drivers-535 package : Ubuntu for a 45 second delay on display of windows contents after login. An xorg only problem, Wayland shows no such delay. Suggested fix in bug for altering a requisite on the gnome desktop startup.
1 Like