How to provide systemd user service

Hi all,

Couldn’t find in the docs a way to install a systemd user service using Snaps - unit files that go into /usr/lib/systemd/user or /etc/systemd/user , for instance. Is there such thing in snapcraft?

2 Likes

We have experimental code to support this, but it is not yet enabled by default. It can be enabled with:

sudo snap set system experimental.user-daemons=true

… and disabled with:

sudo snap unset system experimental.user-daemons

With the feature flag turned on, it is possible to install snaps that provide user services. On the snap side, this is achieved by adding daemon-scope: user to the app definition for the daemon. At present, Snapcraft does not understand this key (at least until PR #3129 is merged, which will probably happen after the feature is turned on by default), so it would need to be listed through a passthrough: section:

apps:
  svc:
    command: ...
    daemon: simple
    passthrough:
      daemon-scope: user

In most respects, you can use the same types of configuration as you would for system daemons. If you want to use socket activation, the socket locations must start with one of $SNAP_USER_DATA/, $SNAP_USER_COMMON/, or $XDG_RUNTIME_DIR/ (the last of which will be in the snap’s private version of the directory).

If you try to publish a snap using this feature, it will currently fail automated review and require manual approval. As mentioned above, it will only be installable by users who turn on the feature flag. I can’t give you a timeline on when the feature will be turned on by default, but it is important to us as it is a prerequisite for enabling D-Bus service activation support for the session bus (something that is obviously interesting to the desktop team).

7 Likes

Great, thanks for bringing this.

If having trouble getting this to work:

Could you help point me to what I’m doing wrong?

I’ve already sudo apt-get upgrade snap to try to make sure I’m on the latest version.

snap --version:

snap    2.46.1
snapd   2.46.1
series  16
ubuntu  16.04
kernel  4.15.0-1083-gcp

I enable snap experimental, as you describe, and it looks like it works, unless maybe I need to restart snap or something.

The problem is, when I run the script, and then use snap services, i get:

error: cannot get status of services of app "visshous": cannot get unit status: empty field "Type"
       in ‘systemctl show’ output

This is a bug with snap services I found a while ago and didn’t report yet unfortunately, but in the meantime just use systemctl status snap.$YOUR_SNAP*

So - I got this to work on Ubuntu, but it still is not working on Debian.

snap    2.46.1
snapd   2.46.1
series  16
ubuntu  16.04
kernel  4.15.0-1083-gcp
snap    2.46.1
snapd   2.46.1
series  16
debian  10
kernel  4.19.0-10-cloud-amd64

Both my snap versions looks exactly the same, both with system experimental.user-daemons=true.

However, on the Debian distro, it appears that the Snap never starts, or is unable to start after install. Journalctl is of not much help.

Here’s an example of what I can see with journalctl -r:

On Ubuntu:

Sep 17 17:27:18 ubuntu-xfce visshous.visshous[19217]: Watches established.
Sep 17 17:27:18 ubuntu-xfce visshous.visshous[19217]: Setting up watches.
Sep 17 17:27:18 ubuntu-xfce systemd[3246]: Started Service for snap application visshous.visshous.
Sep 17 17:27:18 ubuntu-xfce systemd[3246]: Reloading.
Sep 17 17:27:18 ubuntu-xfce systemd[3246]: Started snapd user session agent.
Sep 17 17:27:18 ubuntu-xfce systemd[3246]: Starting snapd user session agent...
Sep 17 17:27:18 ubuntu-xfce kernel: audit: type=1400 audit(1600363638.306:234): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.visshous.visshous" pid=19195 comm="apparmor_parser"
Sep 17 17:27:18 ubuntu-xfce audit[19195]: AVC apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.visshous.visshous" pid=19195 comm="apparmor_parser"
Sep 17 17:27:18 ubuntu-xfce kernel: audit: type=1400 audit(1600363638.226:233): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap-update-ns.visshous" pid=19194 comm="apparmor_parser"
Sep 17 17:27:18 ubuntu-xfce kernel: kauditd_printk_skb: 3 callbacks suppressed
Sep 17 17:27:18 ubuntu-xfce audit[19194]: AVC apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap-update-ns.visshous" pid=19194 comm="apparmor_parser"
Sep 17 17:27:18 ubuntu-xfce systemd[1]: Mounted Mount unit for visshous, revision x1.
Sep 17 17:27:18 ubuntu-xfce systemd[1]: Mounting Mount unit for visshous, revision x1...
Sep 17 17:27:18 ubuntu-xfce systemd[1]: Started ACPI event daemon.
Sep 17 17:27:18 ubuntu-xfce systemd[1]: [/etc/systemd/system/snap-visshous-x1.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
Sep 17 17:27:18 ubuntu-xfce systemd[1]: [/etc/systemd/system/snap-snapcraft-5407.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
Sep 17 17:27:18 ubuntu-xfce systemd[1]: [/etc/systemd/system/snap-snapd-9279.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
Sep 17 17:27:18 ubuntu-xfce systemd[1]: [/etc/systemd/system/snap-core-9993.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
Sep 17 17:27:18 ubuntu-xfce systemd[1]: [/etc/systemd/system/snap-core18-1885.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
Sep 17 17:27:18 ubuntu-xfce systemd[1]: [/etc/systemd/system/snap-lxd-16926.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
Sep 17 17:27:18 ubuntu-xfce systemd[1]: [/etc/systemd/system/snap-multipass-2531.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
Sep 17 17:27:18 ubuntu-xfce systemd[1]: [/etc/systemd/system/snap-lxd-17147.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
Sep 17 17:27:17 ubuntu-xfce systemd[1]: Reloading.
Sep 17 17:27:17 ubuntu-xfce systemd[1]: Started ACPI event daemon.
Sep 17 17:27:17 ubuntu-xfce systemd[1]: [/etc/systemd/system/snap-snapcraft-5407.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
Sep 17 17:27:17 ubuntu-xfce systemd[1]: [/etc/systemd/system/snap-snapd-9279.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
Sep 17 17:27:17 ubuntu-xfce systemd[1]: [/etc/systemd/system/snap-core-9993.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
Sep 17 17:27:17 ubuntu-xfce systemd[1]: [/etc/systemd/system/snap-core18-1885.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
Sep 17 17:27:17 ubuntu-xfce systemd[1]: [/etc/systemd/system/snap-lxd-16926.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
Sep 17 17:27:17 ubuntu-xfce systemd[1]: [/etc/systemd/system/snap-multipass-2531.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
Sep 17 17:27:17 ubuntu-xfce systemd[1]: [/etc/systemd/system/snap-lxd-17147.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
Sep 17 17:27:17 ubuntu-xfce systemd[1]: Reloading.
Sep 17 17:27:17 ubuntu-xfce sudo[19052]: pam_unix(sudo:session): session opened for user root by gWOLF3(uid=0)
Sep 17 17:27:17 ubuntu-xfce sudo[19052]:     root : TTY=pts/0 ; PWD=/home/gWOLF3/snap-craft/visshous ; USER=root ; COMMAND=/usr/bin/snap install visshous_0.1_amd64.snap --devmode

As you can see, the service gets started and all is working as expected.

With the exact same configuration for Debian, it seems like the service is completely unable to start:

Sep 17 18:28:27 debian-xfce sudo[5656]: pam_unix(sudo:session): session closed for user root
Sep 17 18:28:27 debian-xfce snapd[444]: snap.go:293: cannot get full app info for snap "visshous": cannot get status of services of app "visshous": cannot get unit status: empty field "Type" in ‘systemctl show’ output
Sep 17 18:28:26 debian-xfce kernel: audit: type=1400 audit(1600367306.808:89): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap-update-ns.visshous" pid=5794 comm="apparmor_parser"
Sep 17 18:28:26 debian-xfce kernel: audit: type=1400 audit(1600367306.804:88): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.visshous.visshous" pid=5795 comm="apparmor_parser"
Sep 17 18:28:26 debian-xfce audit[5794]: AVC apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap-update-ns.visshous" pid=5794 comm="apparmor_parser"
Sep 17 18:28:26 debian-xfce audit[5795]: AVC apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.visshous.visshous" pid=5795 comm="apparmor_parser"
Sep 17 18:28:26 debian-xfce systemd[1]: Mounted Mount unit for visshous, revision x1.
Sep 17 18:28:26 debian-xfce systemd[1]: Mounting Mount unit for visshous, revision x1...
Sep 17 18:28:26 debian-xfce systemd[1]: Reloading.
Sep 17 18:28:26 debian-xfce sudo[5656]: pam_unix(sudo:session): session opened for user root by gWOLF3(uid=0)
Sep 17 18:28:26 debian-xfce sudo[5656]:   gWOLF3 : TTY=pts/1 ; PWD=/home/gWOLF3/snap-craft/visshous ; USER=root ; COMMAND=/usr/bin/snap install visshous_0.1_amd64.snap --dangerous

Do you have any idea what might be the cause of the different behavior? The service to just seem not to start at all on Debian. Not only not showing in the logs, but I can confirm that it’s not running by testing.

Try running systemctl --user status snap.$snap_name.$app.service. User units do not show up under the system instance of systemd, since there is one for each logged in user on the system.

If you installed the snap from within a running session, it should have started the service automatically.

1 Like

This was the last piece I needed for a shairport-sync snap I’ve been working on. I just tried it out and it works great, so fantastic work all around!

Is there any estimate for when this feature will be generally available in snapd?

1 Like

I don’t think there is a timeline yet. I’m still in the process of trying to get D-Bus activation landed, which was the impetus for user daemons.

We (the Ubuntu Desktop team) would like to see both user daemons and D-Bus activation turned on by default, but I haven’t really pushed for that ahead of getting the D-Bus feature merged.

2 Likes

Sorry to resurrect this, but has there been any movement at all? Cheers :slight_smile:

2 Likes

User services without some features could be useful too.

@jamesh, the experimental support for user daemons was added already 3 years ago. What is actually missing for it to get standard/default, it is not only needed for the desktop itself in Ubuntu Core Desktop but also for the Common Print Dialog Backends (CPDB) which are needed for working print dialogs in Ubuntu Core Desktop.

2 Likes

It’s the same issue I have described to you before: the service control commands only currently support system level services.

snapd provides a number of commands for controlling services, in the form of snap services|start|stop|restart|logs, together with a similar set of snapctl commands that can be called by the snap itself (usually from hooks). These are all implemented by having snapd talk to systemd on the command’s behalf. This is a reasonable model for system services, since they are running in a similar context to snapd. But what happens when user services are added to the mix?

If a snap S has a user service U, what should snap start S.U do?

  • Should it try to start the service for all logged in users?
  • Should a regular user be able to call it to start only their own instance of the service?
  • Should it behave differently if called as root compared to a regular user?
  • In the unprivileged case, should the command talk to the user’s systemd instance and bypass snapd completely? What about in the snapctl case where that communication will be blocked?
  • If a snap has a mix of system and user daemons, what should snap start S do?

I have been advocating that we enable the feature despite the missing service control features. If we produce a well defined error when any of these commands are used on user services, then there shouldn’t be any compatibility problem when a real implementation is rolled out (whatever semantics are chosen). And it’s only snaps that use user daemons that could be affected: every other snap would behave as before.