Ubuntu Core Desktop - The desktop session

I hope you enjoyed learning more about Ubuntu Core Desktop in our last post. This week we’ll be getting into some of the engineering work necessary to make this all work, specifically the Ubuntu Desktop Session as a snap.

Let’s talk a bit more about what the desktop session snap really is. This is the component that flavours or other derivatives will need to provide to build custom desktop experiences. For Ubuntu Desktop, the snap provides all the necessary desktop services to run a traditional GNOME desktop. An interesting point to make here is that the desktop session snap runs under confinement as well, isolated from other snaps. This isn’t some unconfined space for privileged services to run.

What does this really mean? We’ll start with a quick overview of how snaps use “plugs” and “slots”. Snapd leverages kernel level mediation for syscalls and resource access as well as providing a well defined set of interfaces that provide access to necessary resources and manages connections between the slot and plug. Users can disconnect these interfaces to prevent this access. All desktop snaps have a few common interfaces necessary to work in a desktop session, things like wayland and x11 are pretty self-explanatory. If you disconnect x11, the app will no longer be able to talk to an X server, for example. There’s another important interface for desktop snaps, which is the “desktop” interface. This interface provides access to things like fonts, XDG Portal APIs, App indicator, etc. For more information on these interfaces see the snapd documentation.

On classic Ubuntu systems, the slot side of interfaces like wayland, x11, and desktop are provided by the host system as these services are running unconfined on the host system. In the case of an Ubuntu Core based desktop, these slots are provided by the desktop session snap.

Interface       Plug                     Slot                                    Notes
audio-playback  firefox:audio-playback   ubuntu-desktop-session:audio-playback   -
audio-record    firefox:audio-record     ubuntu-desktop-session:audio-record     -
desktop         firefox:desktop          ubuntu-desktop-session:desktop          -
wayland         firefox:wayland          ubuntu-desktop-session:wayland          -
x11             firefox:x11              ubuntu-desktop-session:x11              -

In the above example, firefox is allowed access to pipewire running inside the ubuntu-desktop-session for audio playback and recording. Disconnecting it from the “audio-record” slot will disable access to the microphone. The connection to the desktop slot allows it to access settings, fonts, and other DBus APIs that are running in ubuntu-desktop-session.

This is where we get into some of the engineering work that was necessary to build a desktop experience based on Ubuntu Core. Snapd has had the necessary mediation since the beginning, however running a desktop session requires the use of user session services. Snapd already had support for systemd system services, but we really need user session services and DBus activation in the user session to provide a full featured desktop.

These are features useful for classic desktop as well, but essential for desktop on Ubuntu Core. We set out to add support for user-daemon and dbus-activation in Snapd. More information can be found on the snapcraft forum.


This feature allows a snap to provide a systemd user daemon. Here’s an example of how we utilize this in the ubuntu-desktop-session snap to run pipewire:

    command: run.sh /usr/bin/wireplumber
    daemon: simple
    daemon-scope: user
    - pipewire

In this example, we run wireplumber via systemd in the user session, after pipewire has started.


DBus activation just extends the user-daemon functionality by registering a service to be launched when needed via DBus. Here’s an example of how we utilize this in the ubuntu-desktop-session snap to run xdg-desktop-portal-gnome:

    interface: dbus
    bus: system
    name: org.freedesktop.impl.portal.desktop.gnome

    command: run.sh /usr/libexec/xdg-desktop-portal-gnome
    daemon: simple
    - dbus-freedesktop-impl-portal-gnome

Notice in this example we include a DBus slot definition and declare the user-daemon to activate on the slot.

Both the user-daemon and dbus-activation features landed in snapd a while back behind an experimental flag, enabled on classic Ubuntu Desktop since 22.04 for the snapd-desktop-integration snap which provides user services to improve integration with the desktop experience. We’ve enabled these on Ubuntu Core Desktop, as they are essential

Other Desktop Services

A full list of services running within confinement as part of the ubuntu-desktop-session snap:

The desktop session snap also provides the wayland socket, surfaced through the wayland slot as well as X support via Xwayland surfaced through the x11 slot.

Stay tuned for our next post where we’ll talk about the desktop-launch interface and the challenges to enable application launching from within the desktop session snap.


Thanks a lot for this kind of posts :slight_smile:
I also hope to see a “Kubuntu Core Destop” in a not too far future :crossed_fingers:


One point to add here: The section “user-daemons” in the original posting actually describes how to declare an app as user daemon, running as a normal user and only during their (desktop/login) session. But note that the “dbus-activation” example describes the D-Bus activation of a system daemon via the system bus. And example for the a D-Bus-triggered user daemon would be:

    interface: dbus
    bus: session
    name: org.openprinting.Backend.CUPS

    command: scripts/run-cpdb-backend-cups
    daemon: simple
    daemon-scope: user
    - dbus-openprinting-backend-cups
    plugs: [cups]

Here we have bus: session and daemon-scope: user. Note that a system-bus-triggered user daemon does not work. snapcraft errors when trying to build such a Snap.

I discovered that when a volunteer (was attending my Snap workshop on the Opportunity Open Source in India) was snapping the CUPS backend of the Common Print Dialog Backends (which will also be a part of Ubuntu Core Desktop).


Now I have tried out my first user daemon Snap, the CUPS backend of the Common Print Dialog Backends (CPDB) and ran into some problems which I want to discuss in this thread on snapcraft.io.

This package is really needed in Ubuntu Core Desktop as it is required to be able to print on the snapped CUPS form the print dialogs of snapped applications. And for later classic Ubuntu releases which use the CUPS Snap as printing stack it also needs to work with unsnapped clients (applications with print dialogs).

The problem is that the D-Bus service of the backend is provided to clients only through a dedicated slot, and so unsnapped clients do not have access and Snaps would need to explicitly plug each backend which defeats the architecture of the CPDB where a client (CPDB frontend aka print dialog) is supposed to use all backends available on the system especially also of new print services (like cloud printing services), without need to modify all app Snaps to explicitly plug each new backend.

Same here. I’m keeping an eye on Ubuntu Core Desktop as alternative to Fedora Kinoite/Onyx to replace Windows 7 on my father’s old computer so he can start again using it with Internet access. (And hopefully without having to serve constantly as tech support.) And a “Windows” like interface would probably fit his habits’ better.

By the way @kenvandine how will upgrades between two versions of Ubuntu Core Desktop (from 24.04 to 26.04 for example) be done ? (And how automatic would software upgrades be ?)

Since Core Desktop is UbuntuCore under the hood… here is how “release upgrades” happen there (this might indeed be adjusted, enhanced or changed for the desktop version)

1 Like

A post was split to a new topic: Battery Life