Comment 1 for bug 1912120

So for the first snap, which is a `daemon-scope: user` snap service, it's because snapd runs as root and executes:

systemctl show --property=Id,ActiveState,UnitFileState,Type snap.keybase.kbfs.service

which doesn't return anything because there is no root user session.

For the other snap, somehow via `snap try`ing various snaps, I managed to get a snap mounted at /snap/ubiquiti-unifi/current but the snap.yaml therein says the name of the snap is ubiquiti-unifi2, so some snapd state got messed up there and indeed the name of the systemd service is ubiquiti-unifi2, but snapd thinks it is ubuiquiti-unifi, and that's a very different problem. Not sure if I will be able to reproduce that one, but if I can, then I will file a separate bug there.

This bug here I think should be about snapd failing when a user session service is installed and `snap services` is executed. I think that:

1. if there is (somehow) a root session, then `snap services` should include the status of the root session service
2. if there is not a root session, then we just skip this service in snap services output calculation
3. snap services (and the REST API) should gain an --user option, which then operates only on user session services