Is there a way I make Snap not load at boot but after the user have logged in?

Or do I have to make a feature request about this?
I don’t want to purge Snap, and probably not others too if there is a way to make snap services automatically lunch its boot time scripts after user login to his/her computer.

Snap has a significant impact on PC startup and its app startup.
I can bear what app startup is right now, but that doesn’t mean, I have to bear Snap lag in boot time too.

I know I can just run sudo systemctl disable snapd.service but it is annoying to enable them if needed. Going back and forth.

I hope snap improve in “near” future, but I think its a really good idea to provide the user an option about how snap can launch itself. Give us an option.

1 Like

This sounds like you’re asking to work around an issue. Let’s try and fix the actual problem. Do you have some metrics for what boot speed on your system looks like with snapd service disabled, and enabled? Perhaps use systemd-analze blame and systemd-analyze plot > bootchart.svg and compare them?

Sorry for hijacking your post but I wanted to add some info from my own system.

First it seems that disabling the snapd.service doesn’t really do much. The service still loads. Also there are other snapd related services and snapd.socket.

On my system there is generally no difference in boot time between snapd disabled and enabled.

$ snap --version
snap 2.44.3+20.04
snapd 2.44.3+20.04
series 16
ubuntu 20.04
kernel 5.6.10-xanmod1

I have Ryzen 5 3600 and SSD NVMe disk so boot takes only about 8 seconds. Although sometimes I get up to 16 seconds as reported by systemd-analyze.

$ systemctl status snapd.service
● snapd.service - Snap Daemon
     Loaded: loaded (/lib/systemd/system/snapd.service; disabled; vendor preset>
     Active: active (running) since Sun 2020-05-10 17:25:51 CEST; 19s ago
TriggeredBy: ● snapd.socket
   Main PID: 1410 (snapd)
      Tasks: 25 (limit: 19084)
     Memory: 60.4M
     CGroup: /system.slice/snapd.service
             └─1410 /usr/lib/snapd/snapd

$ systemd-analyze
Startup finished in 3.229s (kernel) + 13.381s (userspace) = 16.611s 
graphical.target reached after 6.931s in userspace
$ systemd-analyze blame 
3.769s snapd.seeded.service                                                    >
3.717s snapd.service                                                           >
3.272s plymouth-quit-wait.service                                              >
2.397s snap-snap\x2dstore-436.mount                                            >
2.391s snap-solarus-15.mount                                                   >
2.334s snap-gnome\x2d3\x2d34\x2d1804-33.mount                                  >
2.327s snap-qt551-28.mount                                                     >
2.288s snap-dosbox\x2dstaging-31.mount                                         >
2.270s snap-solarus-16.mount                                                   >
2.195s snap-inkscape-7627.mount                                                >
2.132s snap-openra-236.mount                                                   >
2.089s snap-odio-5.mount                                                       >
2.034s snap-minetest-1521.mount                                                >
2.033s snap-ohmygiraffe-3.mount                                                >
2.028s snap-snap\x2dstore-439.mount                                            >
1.982s snap-gtk\x2dcommon\x2dthemes-1506.mount                                 >
1.846s snap-chromium-1135.mount                                                >
1.784s snap-canonical\x2dlivepatch-95.mount                                    >
1.781s snap-chromium-1143.mount                                                >
1.735s snap-auryo-197.mount                                                    >
1.672s snap-inkscape-7601.mount                                                >
1.599s dev-loop3.device                                                        >
1.499s snap-fast-4.mount

Not every Linux user in the planet is rich like u.
If I had the hardware like that, I wouldn’t be complaining here.

systemd-analyze plot > bootchart.svg

See here and copy the output in a file named bootchart.svg to see image format.

systemd-analaze blame

See it here.

Can you also add the output of systemd-analyze critical-chain ?

1.846s snap-chromium-1135.mount
1.781s snap-chromium-1143.mount

Why snaps are mounted twice (two last revisions)? I also see this behavior on my system.

to make snap revert .... work nicely and allow you to go back to the former version … i think there was an open bug somewhere to only keep the current revision mounted and mout the one rolled back to dynamically when needed …

output of systemd-analyze critical-chain

See it here.

I have no idea, why its like that.
If there is something I can do about it, please do tell me.

Snaps definitely slow down the startup time in low-end hardware

2 Likes

That’s what I have been trying to tell them.

If only there is a way to automatically launch SNAP after we login, then it would have been easier.

there are thousands of server snaps in the store … how would these start ?

would you require to have appliances (i.e. a TV based on Ubuntu Core) have to always have a user created and logged in to make their payload app run ?

snaps are used a lot in industrial automation, do you think in a factory someone could go around every morning to log in to the industrial controllers of the 5000 production machines they control in the hall ?

That doesn’t mean ‘Snap-devs should NOT give rights to configure Snap so that it start after log-in’ when it is directly increasing boot time.

I tried to investigate the problem of mounts taking longer than expected, left some notes right here: Snapd causing lengthy boot time? It’s not clear why the there is anything in the IO queue of the device at this point.

The mounts are carried out by systemd by invoking mount, which does automatic allocation of a loopback device and associated files with newly obtained /devloop*. Last time I investigated this, I concluded that if there are multiple loopback mounts happening in parallel, there will be quite a lot of contention and respective mounts could end up stealing devices from each other, making the other mount process request a new device and so on. Meaning, that if you try to mount a bunch of files via loopback devices, you will quite likely see the same slowdown.

That being said, automount on demand would be nice, however, the last time I discussed it, there were reliability concerns. I was told that snapd (then snappy?) started with automounted snap images, but that got abandoned due to instability of the software stack. Now, years have passed and many bugs were fixed in systemd, kernel, libmount and snapd itself, so maybe things could actually be improved now.