Snapd should not start if there are no Snaps installed

Since there is a snapd.socket unit, if snapd is stopped, it can correctly autostart on invocation of the 'snap' command. So this seems like a reasonable change to remove memory pressure from snapd when it's not in use.

I don't think systemd lets you express this, so it'd have to be logic inside snapd itself.

Status changed to 'Confirmed' because the bug affects multiple users.

This impacts the memory footprint of all Ubuntu installs in 18.04, including e.g. lxd containers which ship no snaps by default. This should be prioritized for fixing in 18.04 (via SRU if needed).

Yes, this will need to be implemented in snapd directly; snapd will be started on boot and should cleanly shut itself down if it's idle and has no snaps installed.

If someone has no snaps installed when they shut down a system, are they expected to have the same amount of snaps (0) on the next startup?

One thing that could be explored, if possible, is to not start the snapd daemon at all on boots after that (disabling the service) and if snaps are installed it could be re-enabled.

It could make boot time slightly faster, although I'm unsure by how much.

This also impacts Ubuntu minimal so we need it fixed for release and shouldn't wait to SRU post release.

It's way too late for that behavior right now. Many features expect snapd to be live to work. Seeding happens the first time snapd runs, which means a new system will by default start without any snaps installed. The data for command-not-found is acquired by snapd while running as well. We also cannot trivially start and then stop because there's no obvious control point for when snapd is done doing what needs to get done.

So, yeah, we can look for good solutions for this problem, but changing the behavior now would be reckless in terms of stability.

I understand this is committed in snapd 2.36.

This was fixed in snapd 2.36. 2.37 is now in disco and bionic-updates, and will land in trusty,xenial,cosmic soon.