Tizonia: command-line app and dbus daemons in the same snap


Tizonia (https://github.com/tizonia/tizonia-openmax-il) is a command-line app where some of the functionality is off-loaded to D-Bus daemons.

In Tizonia’s case, the dbus processes are internal and do not need to be exposed to other snaps.

So I don’t know how to make this all work in the app’s snapcraft.yaml (https://github.com/tizonia/tizonia-snap). Some questions I have:

  • Is it necessary to declare multiple app parts in the snapcraft.yaml?. I.e. one for the command-line app, then one per dbus daemon…
  • Is it necessary to declare plugs and slots, even though the D-Bus interfaces are all internal and need not be exposed outside the container?
  • If the plugs/slots declarations are needed, is there a way to ‘auto-connect’ them? In a non-snap installation, users don’t have to do this step, since, the D-Bus services are started transparently.


  • you only need to expose them as apps to call them from outside the snap.
  • you might need to request more interfaces, but only the ones needed for the app to run the daemon, not whatever’s needed for the outside world to talk to it.
  • if these interfaces that you find you need to request aren’t auto-connected, you’ll need to request auto-connection as usual. For example if you find you need to poke at /dev/mem, even if it’s “just” for internal use, you’ll need memory-control and that is not going to connect automatically.

The security policy allows your snap commands to use an abstract Unix socket by default. If you use a private DBus bus, then you shouldn’t have to do anything else.

If you want to bind to a well-known name on the session or system buses, then your service needs to ‘slots’ the dbus interface and your clients ‘plugs’ the slot side. Using a well-known name will trigger a manual review in the store on upload and a snap declaration will be issued for use of the well-known name (it should very clearly match your snap to be approved). Auto-connection will not happen automatically, but that can be adjusted in the snap declaration as part of the review as well.

Importantly, if you use well-known names (ie, the session or system bus with the ‘dbus’ snappy interface), then other processes (non-snaps and connected snaps that plugs your declared slot) will be able to find your service and use it. If you want it truly private, I recommend using a private bus.

Hope this helps!