snap services output broken when daemon-scope: user is used
Bug #1912120 reported by
Ian Johnson
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snapd |
Confirmed
|
Medium
|
Unassigned |
Bug Description
For example:
$ snap services
error: cannot get status of services of app "kbfs": cannot get unit status: empty field "Type" in
‘systemctl show’ output
This is because there is a `daemon-scope: user` service installed (kbfs is a user session service).
Changed in snapd: | |
assignee: | nobody → Ian Johnson (anonymouse67) |
description: | updated |
Changed in snapd: | |
assignee: | Ian Johnson (anonymouse67) → nobody |
To post a comment you must log in.
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