Also remember that systemd isn’t generally doing this in series, waiting for each unit before starting the next. It’s firing off a bunch of units and then continuing what it does. If it were measuring the actual time that a unit takes without including the fact that it’s waiting for resources that other units are using, it’s highly unlikely that bare, which is basically empty, would take longer than massive snaps like Firefox and the GNOME content snaps.
Theoretically with a huge number of snaps and slow enough storage media this could have a noticeable effect, but in practice that case is highly unlikely.
Let’s ignore all the anti-consumer bs (like selling user data to Amazon) and just focus on snaps.
apt get install firefoxfor example)How so? How much impact are we talking? First I’ve heard of this
It needs to mount virtual directories for each snap. If I remember correctly it does a part of the job on boot and part on login.
Not really noticed it tbh:
1.951s snapd.seeded.service
1.673s snapd.service
Seems to be a lot longer than the mounts themselves but even then pretty minimal impact:
$ systemd-analyze blame | grep snap | grep mount 86ms snap-bare-5.mount 85ms snap-blanket-49.mount 84ms snap-btop-813.mount 83ms snap-btop-814.mount 82ms snap-chromium-3010.mount 82ms snap-chromium-3025.mount 80ms snap-core18-2829.mount 79ms snap-core18-2846.mount 78ms snap-core20-2379.mount 77ms snap-core20-2434.mount 76ms snap-core22-1663.mount 76ms snap-core22-1722.mount 75ms snap-core24-609.mount 74ms snap-core24-716.mount 73ms snap-cups-1067.mount 72ms snap-firefox-5600.mount 71ms snap-firefox-5647.mount 70ms snap-firmware\x2dupdater-127.mount 69ms snap-firmware\x2dupdater-147.mount 68ms snap-gnome\x2d3\x2d28\x2d1804-198.mount 67ms snap-gnome\x2d3\x2d38\x2d2004-140.mount 66ms snap-gnome\x2d3\x2d38\x2d2004-143.mount 65ms snap-gnome\x2d42\x2d2204-172.mount 64ms snap-gnome\x2d42\x2d2204-176.mount 63ms snap-gnome\x2d46\x2d2404-66.mount 62ms snap-gnome\x2d46\x2d2404-77.mount 61ms snap-gtk\x2dcommon\x2dthemes-1534.mount 60ms snap-gtk\x2dcommon\x2dthemes-1535.mount 59ms snap-libreoffice-330.mount 58ms snap-libreoffice-334.mount 57ms snap-mesa\x2d2404-143.mount 56ms snap-mesa\x2d2404-44.mount 55ms snap-nvtop-171.mount 54ms snap-pinta-33.mount 53ms snap-pinta-37.mount 52ms snap-snap\x2dstore-1244.mount 51ms snap-snap\x2dstore-1248.mount 50ms snap-snapd-23258.mount 49ms snap-snapd-23545.mount 48ms snap-snapd\x2ddesktop\x2dintegration-247.mount 47ms snap-snapd\x2ddesktop\x2dintegration-253.mount 46ms snap-surfshark-51.mount 44ms snap-telegram\x2ddesktop-6489.mount 43ms snap-transmission-100.mount 42ms snap-youtube\x2ddl-4630.mount 41ms snap-youtube\x2ddl-4806.mount 40ms var-snap-firefox-common-host\x2dhunspell.mount 24ms snap-telegram\x2ddesktop-6495.mountAlso remember that systemd isn’t generally doing this in series, waiting for each unit before starting the next. It’s firing off a bunch of units and then continuing what it does. If it were measuring the actual time that a unit takes without including the fact that it’s waiting for resources that other units are using, it’s highly unlikely that
bare, which is basically empty, would take longer than massive snaps like Firefox and the GNOME content snaps.Theoretically with a huge number of snaps and slow enough storage media this could have a noticeable effect, but in practice that case is highly unlikely.
What’s the total without the second grep?
Using mistral to calculate this but looks close enough
1921 + 1673 + 242 + 85 + 84 + 84 + 83 + 82 + 81 + 80 + 79 + 77 + 77 + 75 + 74 + 73 + 72 + 71 + 70 + 69 + 68 + 68 + 67 + 66 + 65 + 64 + 63 + 62 + 61 + 60 + 59 + 58 + 57 + 56 + 55 + 54 + 53 + 52 + 52 + 51 + 50 + 48 + 48 + 47 + 46 + 45 + 44 + 43 + 41 + 21 + 18 = 7264ms
So, the total sum of all the time values is 7264 milliseconds, or 7.264 seconds
Removing the snapd services: 7264ms - 3836ms = 3428ms
Do they start at the same time or waiting for one to finish before doing the next?
start at the same time, lots of overlap on starting services