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.
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.
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 …
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 ?
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.
It’s not about being rich, since when 8 seconds is considered a good boot time? I remember when I installed manjaro, I had 2 seconds boot time on an SSD, this is 4x slower.
I want snap to allow me to do what I want, I want myself to control if it should use it on boot time, during login, or fall back to older ways, just start process when user actually starts an application.