Parallel installs¶
Parallel installs enable you to run multiple instances of the same snap on the same system. Each instance is completely isolated from all other instances, including its name, configuration, interface connections, data locations, services, applications and aliases.
Parallel installs are enabled by default from snapd 2.79. Earlier versions of snapd treated them as an experimental feature that had to be enabled explicitly.
Not every snap can be installed as a parallel instance. Snaps that use unsupported interfaces or app properties are rejected when installed with an instance key. See Snaps that are unsupported as parallel instances for details.
To disable parallel installs, set the experimental.parallel-instances system option to false:
sudo snap set system experimental.parallel-instances=false
With parallel installs disabled, snap install fails when given an instance key.
The native package of snapd 2.79 ships a new mount unit, crucial for the correct behavior of parallel instances of classic snaps. For systems that previously did not have the feature enabled and wish to use parallel instances of classic snaps, we recommend rebooting the system after updating the native package to a version >=2.79.
Installing multiple instances¶
The process for installing multiple instances of a snap is identical to installing a single snap except you must provide a unique identifier, called an instance key, separated by an underscore (_) from the target snap name.
For example, the following command will install two instances of the hello-world snap with the second given an instance key of foo:
sudo snap install hello-world hello-world_foo
To specify a specific channel and track for each instance, install each instance separately.
For example, to install Juju 2.9 alongside Juju 3.0, run the following commands:
sudo snap install --channel 2.9/stable juju_29 --classic
sudo snap install --channel 3.0/stable juju_30 --classic
When installing from snap file, the instance key is set by passing --name=<snap>_<instance> explicitly:
sudo snap install --name hello-world_foo hello-world_27.snap
Instance key naming¶
The instance key needs to be manually appended to the snap name, and takes the following format: <snap>_<instance-key>
For example, the following are valid instance names, for example:
hello-worldhello-world_foohello-world_0123456789
Only lowercase letters or digits are valid, and the instance name can be up to 10 characters long. After being set during the installation of a snap, an instance name cannot be changed.
ⓘ The instance key must match the following regular expression:
^[a-z0-9]{1,10}$.
Instance management¶
When working with instances, the vast majority of snap commands function just as they would with a single snap. To remove an instance, for example, use remove:
$ snap remove hello-world_foo
hello-world_foo removed
Interfaces¶
Interfaces work across multiple snap instances just as they do from any one snap to another. For example, xkcd-webserver includes a network plug, as will all of its instances, any of which can be connected to the system’s :network slot:
$ snap connections xkcd-webserver_foo
Interface Plug Slot Notes
network xkcd-webserver_foo:network :network -
network-bind xkcd-webserver_foo:network-bind :network-bind -
$ sudo snap disconnect xkcd-webserver_foo:network
$ snap connections xkcd-webserver_foo
Interface Plug Slot Notes
network xkcd-webserver_foo:network - -
network-bind xkcd-webserver_foo:network-bind :network-bind -
$ sudo snap connect xkcd-webserver_foo:network
$ snap connections xkcd-webserver_foo
Interface Plug Slot Notes
network xkcd-webserver_foo:network :network manual
network-bind xkcd-webserver_foo:network-bind :network-bind -
Slots provided by a parallel instance are never used for automatic connections. If an instance provides a slot that another snap needs, connect it manually:
sudo snap connect <consumer-snap>:<plug> <provider-snap>_<instance-key>:<slot>
Some interfaces are not supported on parallel instances. See Snaps that are unsupported as parallel instances for details.
Services¶
As with Interfaces, Services function the same with multiple instances of a snap as they do from any one snap to another.
However, with multiple instances, you’re more likely to run into port allocation issues, such as two web servers needing access to port 80. In such cases, only the service from one instance will be active.
$ snap services
Service Startup Current
xkcd-webserver.xkcd-webserver enabled active
xkcd-webserver_foo.xkcd-webserver enabled inactive
You can see why xkcd-webserver_foo.xkcd-webserver is inactive by looking at its logs:
$ sudo snap logs xkcd-webserver_foo.xkcd-webserver
2018-10-03T12:31:59Z xkcd-webserver_foo.xkcd-webserver[1760]: OSError: [Errno 98] Address already in use
(...)
As with single snap service collisions, the solution is to stop the service on one instance and start the service on the other:
$ sudo snap stop xkcd-webserver.xkcd-webserver
Stopped.
$ sudo snap start xkcd-webserver_foo.xkcd-webserver
Started.
$ snap services
Service Startup Current
xkcd-webserver.xkcd-webserver enabled inactive
xkcd-webserver_foo.xkcd-webserver enabled active
Application names and aliases¶
Snap application names for multiple instances are adjusted according to the following pattern:
<instance-name>.<app>
When an application name matches the snap name, a short alias is created to match the instance name.
For example, with hello-world and hello-world_foo installed, hello-world.env has an alias of hello-world_foo.env in the _foo instance:
$ hello-world.env |grep SNAP_INSTANCE_NAME
SNAP_INSTANCE_NAME=hello-world
$ hello-world_foo.env |grep SNAP_INSTANCE_NAME
SNAP_INSTANCE_NAME=hello-world_foo
As with regular snaps, aliases can be added separately:
$ sudo snap alias hello-world_bar bar_env
Added:
- hello-world_bar as bar_env
$ sudo snap alias hello-world_foo foo_env
Added:
- hello-world_foo as foo_env
$ snap aliases
Command Alias Notes
hello-world_bar bar_env manual
hello-world_foo foo_env manual
Aliases from instances generate conflict errors, just as they would with distinct snaps:
$ sudo snap alias hello-world_foo bar_env
error: cannot perform the following tasks:
- Setup manual alias "bar_env" => "hello-world" for snap "hello-world_foo"
(cannot enable alias "bar_env" for "hello-world_foo", already enabled for "hello-world_bar")
When aliases trigger a conflict during snap installation, try passing --unaliased with the command to disable automatic alias generation:
$ sudo snap install snap-with-conflicting-alias_foo --unaliased
Snap environment, data and namespace¶
When a snap application is run, its environment is populated with a number of SNAP* environment variables.
The following environmental variables are potentially affected when installing multiple instances of a snap:
SNAP_NAME: the name of the snap, eg.
hello-worldSNAP_INSTANCE_NAME: the name of the instance, eg.
hello-world_fooSNAP_INSTANCE_KEY: instance key, eg,
fooforhello-world_fooSNAP: location of files for the snap
SNAP_DATA: data for this particular snap revision
SNAP_COMMON: data shared between revisions of the same snap
SNAP_USER_DATA: user data for this particular snap revision
SNAP_USER_COMMON: user data shared between revisions of the same snap
HOME: user’s home, equivalent to
SNAP_USER_DATAXDG_RUNTIME_DIR: user’s XDG runtime directory
For example, if hello-world and its instance, hello-world_foo, are installed, the following name variables would be set:
snap |
hello-world |
hello-world_foo |
|---|---|---|
SNAP_NAME |
hello-world |
hello-world |
SNAP_INSTANCE_NAME |
hello-world |
hello-world_foo |
SNAP_INSTANCE_KEY |
foo |
The data and mount points of parallel installed snaps are kept separate on the host filesystem. Assuming the snap mount directory is /snap, the following locations are used:
snap |
hello-world |
hello-world_foo |
|---|---|---|
mount point |
/snap/hello-world/27 |
/snap/hello-world_foo/27 |
system data |
/var/snap/hello-world/ |
/var/snap/hello-world_foo/ |
user data |
$HOME/snap/hello-world/ |
$HOME/snap/hello-world_foo/ |
Within the mount namespace of a snap, adjustments are made to map instance-specific locations to the snap locations. Taking hello-world as an example, system data locations are set to the following:
snap |
hello-world |
hello-world_foo |
|---|---|---|
SNAP |
/snap/hello-world/27 |
/snap/hello-world/27 |
SNAP_DATA |
/var/snap/hello-world/27 |
/var/snap/hello-world/27 |
SNAP_COMMON |
/var/snap/hello-world/common |
/var/snap/hello-world/common |
However, due to security concerns, user data locations are not similarly adjusted:
snap |
hello-world |
hello-world_foo |
|---|---|---|
SNAP_USER_DATA |
/home/ |
/home/ |
SNAP_USER_COMMON |
/home/ |
/home/ |
HOME |
/home/ |
/home/ |
XDG_RUNTIME_DIR |
/run/user/ |
/run/user/ |
Snaps that are unsupported as parallel instances¶
Certain snaps, due to their nature, can never be parallel installed:
snapd
core base
kernel
gadget
All other snaps are subject to feature checking. Snapd checks every snap installed with an instance key and rejects it if it uses a feature that cannot work with more than one instance.
Unsupported interfaces¶
Some interfaces give the snap exclusive ownership of a system-wide resource, such as a well-known D-Bus name. Others allow operations on shared hardware or kernel state that would conflict if performed by more than one instance. A snap cannot be installed as a parallel instance (unless specified with an explicit bypass flag; see Installing an unsupported snap anyway) if it declares a plug or slot for one of these interfaces on an unsupported side:
Interface |
Plug supported |
Slot supported |
|---|---|---|
No |
Yes |
|
No |
Yes |
|
Yes |
No |
|
No |
Yes |
|
Yes |
No |
|
Yes |
No |
|
Yes |
No |
|
No |
Yes |
|
No |
Yes |
|
No |
No |
|
Yes |
No |
|
Yes |
No |
|
Only without |
No |
|
No |
Yes |
|
Yes |
No |
|
No |
Yes |
|
No |
Yes |
|
Yes |
No |
|
No |
Yes |
|
No |
Yes |
|
Yes |
No |
|
Yes |
No |
|
No |
Yes |
|
No |
Yes |
|
Yes |
No |
|
Yes |
No |
|
No |
Yes |
|
Yes |
No |
|
Yes |
No |
|
No |
Yes |
|
No |
Yes |
|
Yes |
No |
|
Yes |
No |
|
No |
Yes |
|
Yes |
No |
|
No |
Yes |
|
No |
Yes |
|
|
Yes |
No |
Yes |
No |
|
Yes |
No |
|
Yes |
No |
|
Yes |
No |
|
No |
Yes |
|
No |
Yes |
|
Yes |
No |
|
Yes |
No |
|
No |
No |
|
Yes |
No |
|
No |
Yes |
|
Only with |
No |
|
No |
Yes |
|
Yes |
No |
|
Yes |
No |
|
Yes |
No |
|
Yes |
No |
|
Yes |
No |
|
Yes |
No |
|
Yes |
No |
|
Yes |
No |
|
|
Yes |
No |
Yes |
No |
|
Yes |
No |
|
No |
Yes |
When an instance cannot be installed, the error names the plug or slot responsible and the reason, for example:
cannot install snap "network-manager_foo" as parallel instance: slot "service" with interface "network-manager" is not supported for parallel instances: owning a unique global resource cannot have parallel instances
Unsupported app properties¶
A snap is unsupported as a parallel instance if any of its apps set one of the following properties in snap.yaml:
common-id: the desktop file ID referenced by AppStream metadata is unique on the system.bus-name: the well-known D-Bus name the app claims is unique on the system.activates-on: D-Bus activation requires adbusslot, which is not supported on parallel instances.
Installing an unsupported snap anyway¶
Users who understand and accept the risks of conflicts between instances may bypass these checks with --allow-unsupported-instances:
sudo snap install --allow-unsupported-instances <snap>_<instance-key>
Snapd remembers this choice for the instance, so later refreshes are not blocked.
If a refresh introduces an unsupported plug, slot or app property to an instance that is already installed and was fully supported, snapd blocks the refresh and adds a warning visible with snap warnings. To refresh the instance anyway, run:
sudo snap refresh --allow-unsupported-instances <snap>_<instance-key>
--allow-unsupported-instances can only be used with snaps installed with an instance key.
Classic confinement¶
Snaps with classic confinement can be installed as parallel instances, but may require some setup on the part of the user, depending on the snap. Check the relevant snap’s documentation for more details.
As mentioned in the beginning description of parallel instances, for correct behavior of parallel instances of classic snaps, systems that previously did not have parallel instances enabled yet had at least one snap installed should reboot their system after updating the native package to snapd >=2.79.
Current limitations¶
There are a few limitations with parallel installs that will be addressed in subsequent snapd releases.
User data and runtime locations¶
The user data locations are kept separate across multiple instances. Applications that hard code paths to either user data directories or the XDG runtime directory may not function correctly as the AppArmor profile has been updated to allow accessing instance specific paths only.
Applications need to use SNAP_USER_DATA, SNAP_USER_COMMON or fallback to using HOME.
Applications built using most popular frameworks, such as Gtk/glib or Qt, and that are already capable of observing both HOME and XDG_RUNTIME_DIR, should continue to work.