Ok, sorry for taking forever.
I was testing a relatively recent snapd from edge:
$ snap --version
snap 2.27.1+git322.46fa975~ubuntu16.04.1
snapd 2.27.1+git322.46fa975~ubuntu16.04.1
series 16
ubuntu 16.04
kernel 4.10.0-32-generic
I tried the handbrake-jz
snap and immediately ran into the issue. Ironically it is not related to the order of starting snaps at all. Let me bring in some facts before I get to the point.
This is the application snap:
$ cat /snap/handbrake-jz/current/meta/snap.yaml
apps:
ghb:
command: command-ghb.wrapper
plugs:
- unity7
- home
- gsettings
- mount-observe
- network
- process-control
architectures:
- amd64
confinement: strict
description: |
HandBrake is a tool for converting video from nearly any format to a
selection of modern, widely supported codecs.
epoch: 2
grade: stable
name: handbrake-jz
plugs:
gnome-3-24-platform:
default-provider: gnome-3-24:gnome-3-24-platform
interface: content
target: $SNAP/gnome-platform
summary: HandBrake is a tool for convertion video to.
version: 1.0.7-1
This is the shared content snap:
$ cat /snap/gnome-3-24/current/meta/snap.yaml
architectures:
- amd64
confinement: strict
description: "This snap includes a GNOME 3.24 stack (the base libraries and desktop\
\ \nintegration components) and shares it through the content interface. \nIt's\
\ built using the Ubuntu xenial backport binaries.\n"
grade: stable
name: gnome-3-24
slots:
gnome-3-24-platform:
interface: content
read:
- /
summary: Shared GNOME 3.24 Ubuntu stack
version: 3.24
Interestingly installing both does not result in any attempts to connect. Note that the content
attribute is absent from both the plug and the slot but this is okay as by default the plug/slot name is used as the content attribute.
This renders the following situation:
plug: handbrake-jz:gnome-3-24-platform
slot: gnome-3-24:gnome-3-24-platform
The interface is set to auto-connect if the base declaration or snap assertions allow this to happen, let’s have a look at those then.
The base declaration:
content:
allow-installation:
slot-snap-type:
- app
- gadget
allow-connection:
plug-attributes:
content: $SLOT(content)
allow-auto-connection:
plug-publisher-id:
- $SLOT_PUBLISHER_ID
plug-attributes:
content: $SLOT(content)
Here we see that the plug’s content
attribute must be the same as the content
attribute of the slot. We also see a restriction that the publisher of both plug and slot snaps must be the same. Under those rules the interfaces would not auto-connect as the publishers are canonical
and jz
.
Looking at snap declarations I don’t see anything changing this. I therefore conclude that those snaps will not auto-connect today.
Let’s proceed to connect them manually now:
$ sudo snap connect handbrake-jz:gnome-3-24-platform gnome-3-24:gnome-3-24-platform
Inspecting the mount namespace I created earlier (by running handbrake-jz) I see that it was modified according to the new connection:
$ sudo nsenter -m/run/snapd/ns/handbrake-jz.mnt
# cat /proc/self/mountinfo | grep gnome-platform
1216 1131 7:40 / /snap/handbrake-jz/12/gnome-platform ro,nodev,relatime master:224 - squashfs /dev/loop40 ro
Attempting to start the snap now doesn’t mention the absent platform snap:
zyga@fyke:~/go/src/github.com/snapcore/snapd/interfaces/builtin$ handbrake-jz.ghb
(process:18379): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
(ghb:18379): GLib-GIO-ERROR **: No GSettings schemas are installed on the system
Pułapka debuggera/breakpoint (zrzut pamięci)
The snap crashes though.