Parallel Installs

Bummer. Thanks for spotting.

I’ve enabled the flag and tried to install Firefox Beta with snap install firefox_beta --beta but that produced

error: cannot install "firefox_beta": cannot refresh, install, or download: The Snap is present
       more than once in the request.

I already have Firefox installed, how do I get Firefox Beta installed as a second instance?

Core 16-2.35.5
$ snap info core
tracking:     beta
refresh-date: 6 days ago, at 09:42 BST
installed:   16-2.35.5                   (5742) 92MB core

$ snap version
snap    2.35.5+18.10
snapd   2.35.5+18.10
series  16
ubuntu  18.10
kernel  4.18.0-10-generic

$ snap info firefox
tracking:     stable
refresh-date: 20 days ago, at 22:56 BST
channels:                                
  stable:        62.0.3-1    (137) 204MB -
  beta:          63.0b14-1   (141) 206MB -      
installed:       62.0.3-1    (137) 204MB -

(lines omitted for brevity)

For starters, you’ll want to have the latest and greatest core, at this point --edge is needed.

The store is bit behind on the support. See the note about installing snaps from store. TLDR: you’ll need to grab the snap from the store yourself (eg. snap download) and install it using the file. Note that having 2 instances of Firefox at this pint will probably stop the snaps from refreshing as the store will respond with an error.

1 Like

Alright I’ll wait for more progress then, thanks! :slight_smile:

We’ve caught up! Parallel installs are now fully supported by the store. We’ve tested it pretty thoroughly, but please try your best to break it.

3 Likes

(firefox_beta was created with the command snap install firefox_beta --beta)

$ snap run firefox_beta
/snap/firefox_beta/144/command-firefox.wrapper: 5: exec: desktop-launch: not found
$ snap run firefox_beta.firefox
/snap/firefox_beta/144/command-firefox.wrapper: 5: exec: desktop-launch: not found
$ env BAMF_DESKTOP_FILE_HINT=/var/lib/snapd/desktop/applications/firefox_beta_firefox.desktop /snap/bin/firefox_beta %U
/snap/firefox_beta/144/command-firefox.wrapper: 5: exec: desktop-launch: not found

I suspect a core refresh or a system reboot stopped Firefox Beta from running entirely, normally it launches with a transparent window. After reverting twice to get to core (5742), then removing firefox_beta, then refreshing to core (5789), and installing firefox_beta again, I’m back to BMO bug 1501895, I don’t have the error above… I wonder what happened? snap run firefox was working fine but snap run firefox_beta was not…

Core 16-2.36~pre2+git971.73ec9b5 (5789)
$ snap info firefox
tracking:     stable
refresh-date: 23 days ago, at 22:56 BST
  stable:        62.0.3-1    (137) 204MB - <
installed:       62.0.3-1    (137) 204MB - 

$ snap info firefox_beta
tracking:      beta
refresh-date:  today at 02:26 BST
installed: 64.0b3-1 (144) 208MB -

$ snap version
snap    2.36~pre2+git971.73ec9b5~ubuntu16.04.1
snapd   2.36~pre2+git971.73ec9b5~ubuntu16.04.1
series  16
ubuntu  18.10
kernel  4.18.0-10-generic

$ snap info core
tracking:     edge
refresh-date: today at 02:25 BST
channels:                                                     
  stable:    16-2.35.4                   (5662) 92MB -    
  candidate: 16-2.35.5                   (5742) 92MB -    
  beta:      16-2.36                     (5799) 92MB -    
  edge:      16-2.36~pre2+git971.73ec9b5 (5789) 92MB -    <
installed:   16-2.36~pre2+git971.73ec9b5 (5789) 92MB core

All I get is a black window. The console log is:

[Parent 17752, Main Thread] WARNING: failed to open shm: Permission denied: file /builds/worker/workspace/build/src/ipc/chromium/src/base/shared_memory_posix.cc, line 129
[GFX1-]: Failed to lock new back buffer.
[Parent 17752, Main Thread] WARNING: failed to open shm: Permission denied: file /builds/worker/workspace/build/src/ipc/chromium/src/base/shared_memory_posix.cc, line 129
[GFX1-]: Failed to lock new back buffer.

AppArmor denials:

[  +0.000002] audit: type=1327 audit(1540445566.824:534): proctitle="/snap/firefox/144/firefox"
[  +0.016190] audit: type=1400 audit(1540445566.841:535): apparmor="DENIED" operation="mknod" 
     profile="snap.firefox_beta.firefox" name="/dev/shm/snap.firefox.org.mozilla.ipc.17752.52"
     pid=17752 comm="firefox-bin" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000                                                                               
[  +0.000010] audit: type=1300 audit(1540445566.841:535): arch=c000003e syscall=2 success=no
     exit=-13 a0=7ffd1a3f2060 a1=a00c2 a2=180 a3=67726f2e786f6665 items=0 ppid=2001
     pid=17752 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts2 ses=3
     comm="firefox-bin" exe="/snap/firefox/144/firefox-bin" subj==snap.firefox_beta.firefox (enforce) key=(null)

It’s one of the quirks about accessing /dev/shm:

I’ll see whether I can tweak the snap a little bit.

1 Like

That particular issue is off-topic, I think? Presumably it would affect firefox were (144) the only firefox snap installed? The point I was making was something broke the snap even further and I’m wondering if that was related to an automatic core refresh to (5789) and the parallels install feature… Unfortunately I don’t have time to test again now to try and reliably break it, so it might’ve been some other reasons that made desktop-launch: not found happen, and unfortunately I didn’t check journalctl -f when running the command :frowning:

No it doesn’t, I just verified that in a VM with core from edge and the firefox snap from the beta channel. All works well, so it’s likely only an issue of named access to /dev/shm.

1 Like

Is parallel installs the correct/only way to have both the stable and beta release of e.g. Blender available at the same time?

Yes. Each instance of a snap is separate, and can track different channel.

However, blender is a classic snap, and currently, we only support parallel installation of confined snaps.

There is work planned in the forthcoming months that should address this problem, and hopefully it will be possible to parallel install classic snaps too. Unfortunately, I cannot give any exact dates as to when that feature will be available.

1 Like

@mborzecki how should snaps go forward (confined vs classic)? Does it make sense to have multiple snaps of the same app now?

Look at the Opera Snap. They originally allowed for consecutive installs on all platforms. Since there were no Parallel Install ability from Snaps, they appear to have released 3 snaps to cover this specific use case. Should this be seen as a bad practice nowadays? When is this a good idea?

Android Studio’s snap (classic) is coming up to a similar decision once Parallel Installs are fully supported. https://github.com/snapcrafters/android-studio/issues/26

1 Like

In the command line (v2.40, Ubuntu 18.04), I can’t do parallel installs with --classic – I’d really like to install multiple versions of dotnet-sdk, but if I say

sudo snap install dotnet-sdk dotnet-sdk_22 --classic

I get the error

error: a single snap name is needed to specify mode or channel flags

My guess is that the options parser is interpretting dotnet-sdk_22 as a second package rather than as an alias.

Classic snaps are not parallel installable yet unfortunately.

When using channel (--edge, --beta, --channel=..) or mode (--classic, --jailmode) flags, you can only pass a single snap name in the command line.

As for parallel installs of classic snaps, the current state is as @ijohnson wrote, we do not support it at the moment. However, we have some work scheduled to add support for this feature, so things may indeed change in 2-3 releases.

1 Like

We have discovered one more weird interaction that enabling parallel installs can have with existing snap mount namespaces, see Parallel-instances breaks content snap consumers for details.

With this in mind, I would recommend that if the users ran any snap applications in the currently booted system prior to enabling/disabling the feature, they should reboot after toggling the experimental flag state.
Alternatively they can discard the mount namespace of all snaps, though I see that as something that a snap developer or a snapd hacker would be more willing to try.

Is this still currently the case? It seems to be conflicting with the following passage:

Thanks for spotting. I’ve updated the doc.

2 Likes

The link at https://snapcraft.io/docs/parallel-installs 404s and I’m under the impression that it should be automatically generated from the post here, is there someone who can take a look at restoring it?

Thanks

Thanks for flagging this, and sorry for the 404. The webteam here at Canonical is experimenting with a new publishing mechanism and this seems to have inadvertently led to a number of 404s for our docs. We’re trying to sort this out now.

1 Like