How do I stop snaps mounting during boot on Ubuntu 18.04?

snapd
1

Booting my very capable PC has become a fingers-on-chalkboard-grating slow nightmare because of snap. It’s gone from 5-10 seconds to login screen after GRUB to now 30-45 seconds, sometimes up to a minute or more.

This is absurd.

I’d prefer to not remove every single snap on my machine, but I’m prepared to do that. How do I defeat snap mounts on boot and regain my sanity, without having to scorch the earth?

Specifically looking for an answer to this: how do I modify individual snaps so that they do not mount during boot?

$ systemd-analyze blame
          8.812s plymouth-quit-wait.service
          6.256s NetworkManager-wait-online.service
          5.042s bolt.service
          3.008s snap-spotify-42.mount
          2.994s snap-gnome\x2dlogs-93.mount
          2.917s snap-discord-115.mount
          2.525s snap-chromium-1399.mount
          2.515s snap-gnome\x2dlogs-100.mount
          2.416s snap-gtk2\x2dcommon\x2dthemes-13.mount
          2.392s snap-gnome\x2dcharacters-550.mount
          2.224s snap-gnome\x2d3\x2d34\x2d1804-36.mount
          2.214s snap-gtk\x2dcommon\x2dthemes-1513.mount
          2.174s snap-gnome\x2d3\x2d28\x2d1804-145.mount
          2.170s snap-gnome\x2dcalculator-748.mount
          2.149s snap-postman-128.mount
          1.953s snap-storage\x2dexplorer-17.mount
          1.946s snap-core18-1885.mount
          1.749s systemd-fsck@dev-disk-by\x2duuid-db865690\x2db43f\x2d485b\x2d8bab\x2d808735a403a8.service
          1.725s unifi-video.service
          1.632s dev-loop3.device
          1.632s dev-loop2.device
          1.575s dev-loop5.device
          1.557s dev-loop6.device
          1.555s dev-loop7.device
          1.464s dev-loop9.device
          1.452s dev-loop8.device
          1.441s snap-gnome\x2dcharacters-570.mount
          1.426s snap-core-10185.mount
          1.409s snap-spotify-43.mount
          1.400s snap-libreoffice-196.mount
          1.384s snap-gtk2\x2dcommon\x2dthemes-9.mount
          1.380s snap-gnome\x2d3\x2d34\x2d1804-60.mount
          1.370s snap-postman-129.mount
          1.214s dev-loop10.device
          1.135s dev-loop11.device
          1.132s dev-loop1.device
          1.089s dev-loop21.device
          1.072s snap-vlc-1620.mount
          1.070s dev-loop19.device
          1.054s dev-loop18.device
          1.041s dev-loop20.device
           981ms dev-loop12.device
           975ms dev-loop14.device
           968ms systemd-logind.service
           944ms dev-loop4.device
           903ms dev-loop13.device
           902ms dev-loop17.device
           901ms dev-loop16.device
           881ms dev-loop22.device
           834ms snap-core18-1932.mount
           809ms snap-chromium-1411.mount
           681ms nvidia-persistenced.service
           678ms snap-gnome\x2d3\x2d28\x2d1804-128.mount
           669ms dev-loop15.device
2

This is a great question. It would be great if snaps could mount on demand (although that would slow down their startup even further) or have delayed mount until some other trigger, such as the desktop being launched. Some might auto-launch (like snap-store) and need to be launched earlier, whereas another like Spotify, which only launches when you click the icon could be mounted later.

Certainly worth investigation!

1 Like
3

I just cannot understand how this is considered acceptable behavior for snap.

4

given that probably (a guessed) 50% or more of snaps are server and IoT stuff that would be awful

5

“Such as” meaning “for example” as one factor. Other factors could include whether it’s a core or classic system, whether it’s a kiosk or not etc

6

well, i think a good start would be if only the actually running revision would be mounted :wink: (mounting the others during revert/refresh only) …

deciding based on the underlying system doesnt seem like such a good idea but basing on “its a service”, it should go into early boot vs “it doesnt ship any service” it can go late into systemd’s multi-user-target would appear better to me and require also less cleverness from snapd and the packaging system itself IMHO.

PS: actually if disabling the snap would unmount it, that would already be a massive improvement (and could actually help the original issue) :slight_smile:

7

So @mborzecki looked into this a while ago and there seem to be some kernel bugs surrounding mounting many squashfs’s at the same time, resulting in inefficient clashing with multiple mount units trying to use the same device mapper, one of them wins the other fails and tries to find another one and fails, etc. etc.

See Snapd causing lengthy boot time?

8

Yes, there need to be decent heuristics. snap-store would fail your example. It’s not a service, but does have a background daemon/server, and is launched on desktop login.

9

based on my above heuristics (doesnt define daemon in snapcraft.yaml) it would be mounted while/after gdm starts in i.e. graphical-target, i think that would be totally fine …

10

Hi Rob.

Did you generate a graph of service dependencies, to check if Snaps are really the culprit? I may be wrong, but I believe the number shown in analyze are “unordered” - I mean, systemd parallelizes a lot and, even though they’re really big, they might not really be the cause of such slowness (but they might be, of course).

I think the command to do so is:

$ systemd-analyze plot > file.svg

Then you can use any SVG viewer to see what is really happening. There’s also a more “elaborate” version of command above:

systemd-analyze dot [PATTERN] > file.dot

You can the use graphviz tools to format and visualize the output.

Just my two cents…

11

I guess there’s no working in this matter? It would be very useful if the developer could set in the yaml file whether the application requires automount or if it can be mounted on demand. I also don’t think it’d be very complicated to add to the description file (if no key is set, then consider it must be automonted, for backward compatibility purposes).

12

Some time ago, I dug a little on this subject. Fount out (at the time) that it would be possible to use kernel automount features to avoid (minimize?) this problem. Think it wasn’t up to the task, though.

1 Like
13

I made my own tests. Snaps seem to consume around 4 and 5 mb of RAM when mounted (or rather, SquashFS do, which is the foundation for snaps).

This is very little for a few snaps, but can go up quite a lot when you start installing lots of apps through snap (which could easily be a preferred way).

I kindly request the team to have an option for those snaps that opt-in, for example, to be mounted on demand rather than during startup. It would also be nice if the user could force this behavior. Not everyone uses Ubuntu on powerful machines. Lubuntu users have low spec PCs which may have 4gb of RAM or less, and the raspberry pi and other SBCs are limited too. I’d really appreciate if the team could work on this, it shouldn’t be too difficult to do.