Snaps Impact on Ubuntu?

[oshunluvr]

FYI, those things run concurrently, not in sequence. This just shows you what takes longest to complete.

[oshunluvr]

and you can remove snap completely. AFAIK there's only a couple in use and there are replacements.

[selectiveduplicate]

Have any of you guys completely removed the snaps? By completely, I mean the whole snap thing (every snap application removed, unmounting the snap devices, purging snapd etc.)
I'm curious what made such boot time difference, since I used snaps, more than what I have installed (I only have the core18 and snapd installed now on Kubuntu), when I used Ubuntu MATE. And the network manager is also taking up time.

[Don B. Cilly]

Quite a few of us have.
If I can manage to install an Ubuntu ISO I have (install failed, like six times))·: I'll try to do some comparisons/analysis on boot times.

I'll probably still want to keep them removed anyway, they really annoy me.

[oshunluvr]

Have any of you guys completely removed the snaps? By completely, I mean the whole snap thing (every snap application removed, unmounting the snap devices, purging snapd etc.)
I'm curious what made such boot time difference, since I used snaps, more than what I have installed (I only have the core18 and snapd installed now on Kubuntu), when I used Ubuntu MATE. And the network manager is also taking up time.

A resounding YES. It reduced the processes running at boot time, but bootup is not that big of a deal to me really.

[selectiveduplicate]

Well I removed everything related to snap, and my boot time has improved comparatively (2 secs only!)...

Startup finished in 3.096s (kernel) + 15.947s (userspace) = 19.043s 
graphical.target reached after 15.938s in userspace

7.075s networkd-dispatcher.service                                                              
4.852s udisks2.service                                                                          
4.596s dev-sda6.device                                                                          
4.451s NetworkManager-wait-online.service                                                       
4.288s accounts-daemon.service                                                                  
4.099s systemd-journal-flush.service                                                            
2.887s polkit.service                                                                           
2.753s avahi-daemon.service                                                                     
2.751s NetworkManager.service                                                                   
2.651s gpu-manager.service                                                                      
2.463s thermald.service                                                                         
2.459s systemd-logind.service                                                                   
2.456s wpa_supplicant.service                                                                   
2.178s grub-initrd-fallback.service                                                             
2.104s grub-common.service                                                                      
1.788s ModemManager.service                                                                     
1.787s ufw.service                                                                              
1.784s systemd-resolved.service                                                                 
1.656s apport.service                                                                           
1.460s e2scrub_reap.service                                                                     
1.205s systemd-udevd.service

Still it should be faster in my experience...

[selectiveduplicate]

A resounding YES. It reduced the processes running at boot time, but bootup is not that big of a deal to me really.

I don't mind that much either, but the "troubleshooter" in me wants to knock around a few things!

I checked the boot.log too for any suspicious things but found none.

[verndog]

.. m.2 ssd and a very current i5 laptop...

Same for me. Not too interested in boot times. In the blink of an eye, its booted.

[Don B. Cilly]

Still out of curiosity.

If I run:

~$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @8.797s
└─multi-user.target @8.796s
└─postfix.service @8.782s +7ms
 └─postfix@-.service @7.290s +1.462s
   └─network-online.target @7.288s
     └─systemd-networkd-wait-online.service @966ms [COLOR="#A52A2A"]+6.320s[/COLOR]
       └─systemd-networkd.service @852ms +108ms
         └─systemd-udevd.service @720ms +125ms
           └─systemd-tmpfiles-setup-dev.service @670ms +38ms
             └─kmod-static-nodes.service @466ms +135ms
               └─systemd-journald.socket @433ms
                 └─system.slice @384ms
                   └─-.slice @353ms

is it still pretty meaningless as to actual boot times because "they run in parallel anyway"?
Because from this, it really looks like: it goes really fast (966ms) up to - and including - systemd-networkd-wait-online.service, then takes 6.320 for network-online.target to run, and another 1.462s for postfix@-.service.
After which it zooms again to graphical.target.

Would this be a fair assessment or am I getting this wrong too?

[Don B. Cilly]

So - just to try and get some sense of this, mind you,
considering that
a) I'm assuming things that maybe I shouldn't
b) these outputs seem to vary quite a bit with... atmospheric pressure? Planet alignments? I mean, on the same system as before, I now have
graphical.target @6.754s
compared to
graphical.target @8.797s
of two hours ago... it's not as if I changed anything... two seconds difference...

Anyway. I managed to install Ubuntu. On the same SSD. (there too, 20.04 is a lot better than the 19.10 I tried last).

The critical-chain there says:

 graphical.target @13.569s
└─multi-user.target @13.568s
└─kerneloops.service @13.509s +58ms
└─network-online.target @13.504s
 └─NetworkManager-wait-online.service @5.463s +8.040s
   └─NetworkManager.service @4.956s +443ms
     └─dbus.service @4.943s
       └─basic.target @4.873s
         └─sockets.target @4.870s
           └─[COLOR="#FF0000"]snapd.socket @4.812s +7ms[/COLOR]
             └─sysinit.target @4.736s
               └─swap.target @4.733s
                 └─dev-disk-by\x2duuid-c988060d\x2dc444\x2d430e\x2db5cd\x2>
                   └─dev-disk-by\x2duuid-c988060d\x2dc444\x2d430e\x2db5cd\>

At third boot, mind you, at first boot it was
graphical.target @2min 41.340s

But - to the point of the topic - snap impact (on a clean install) is... drum roll... +7ms? There's no other mention of snaps...
There is a kerneloops.service (yeah, well, 58ms).
Now, of course df -h is a mess. But... df -h has become quite a mess anyway, lately. Even without snap loops, is has tmpfs stuff splashed all over it (bleagh).

So... are we maybe having... much ado about snapthings?

[NoWorries]

Have any of you guys completely removed the snaps? By completely, I mean the whole snap thing (every snap application removed, unmounting the snap devices, purging snapd etc.)
I'm curious what made such boot time difference, since I used snaps, more than what I have installed (I only have the core18 and snapd installed now on Kubuntu), when I used Ubuntu MATE. And the network manager is also taking up time.

The only application that I have installed when I do a search in Muon with "snapd" is snapd-glib. If I use "snap" for the search nothing comes up. If I try to purge snapd-glib, it would remove my kubuntu-desktop as well as pulseaudio packages! So I leave this package installed.

As far as boot time, I did not look into that as I was only focused on getting snap out of my system.

[mr_raider]

Other than chromium, are there any other .deb files that surreptitiously install snaps?

[chimak111]

Not that I know. It's just the one so far. Something to do with MAAS (?) maybe next.