Comment 20 for bug 1983528

I ran some tests to understand what could have triggered the snapd activation, and I believe that snapd-desktop-integration is not responsible for this. What I did:

    sudo systemctl stop snapd.service
    # At this point the snapd socket is still active and managed by systemd

    # Now simulate the case where the mount units have not been loaded
    sudo umount /snap/snapd-desktop-integration/14

    systemctl --user start snap.snapd-desktop-integration.snapd-desktop-integration.service

After running this, snapd is still not started.

Still, it's very likely that snapd was activated by a connection on its socket (probably via snapctl), but it's not something easy to establish (I looked at systemd options for socket unit files, and I didn't find a way to increase verbosity). But maybe it's not even something that we need to know: the idea that snapd could be woken up at random moments is always a possibility, and we should cope with it. What is critical here is that snapd removes all the snap connections because it sees that the snaps are not mounted, so it assumed that they have been removed.

The solution in the PR linked above works by activating all the snap mount units when the default boot target is reached, and should help in this case. Another option, which I'm going to investigate, is making snapd not disconnect all the connections if the mount unit is not active but the corresponding snap binary file still exists in /var/lib/snapd/snaps/.