Electron snap killed when using app.makeSingleInstance API

snapd
21

I filed https://launchpad.net/bugs/1731012 against apparmor for now (but note it isn’t clear this is an apparmor bug).

22

Hey @jdstrand thanks for the reply and the investigation.

Interestingly, if I add this to the policy (ie, no owner match):

/run/user/[0-9]/snap.@{SNAP_NAME}/{,.}org.chromium./SS r, then launching mailspring in the second terminal after window close works in that it doesn’t kill the first process, we see ‘Exiting because another instance of the app is already running.’ and a mailspring window pops up.

Ahh great! This totally makes sense. The code in that Chromium ProcessSingleton class I referenced earlier implements the business logic around these files, and they’re intentionally killing the first process if it can’t open the socket file (I think the idea is that it’s become unresponsive). Resolving the AppArmor denial and allowing access to that file should definitely prevent the process from being killed.

Thanks for adding a workaround rule— that seems like a good solution for now and I’ll see if I can create a small reproduction snap (though a minimal Electron app still isn’t super minimal…)

How long will it take for the policy change to reach the stable channel? I’d love to ship the Mailspring snap (I’m actually getting a couple emails / tweets a day about it because I said it was coming soon on the website :sweat_smile:) but I should probably wait until a fix for this is in the wild.

23

Not long :slight_smile:

https://github.com/snapcore/snapd/pull/4180 and https://github.com/snapcore/snapd/pull/4181

1 Like
24

More specifically, this will be in snapd 2.29.3 which I’m told people are targeting for Monday.

1 Like
25

Hey! I can confirm that this issue is fixed on my test machines after the 2.29.3 update. Thanks for the quick turnaround! Going to start directing users to download the snap instead of the deb / rpm packages in a few hours. :+1:

3 Likes
26

I’m getting this same issue now, but my snapd version is 2.56.2 (Electron is v19.0.14). If I run my app, it creates a folder /run/user/1000/snap.glint which looks like:

snap.glint
    ├─── dconf
    |    └─── user
    └─── scoped_dir0cJlEZ
         ├─── SingletonCookie -> 4779539152699396278
         └─── SingletonSocket

Did the names of these files/folders change from .org.chromium.*/SS to scoped_*/SingletonSocket and cause a regression here?

As far as I can make out, the workaround would be to adding this to the policy: /run/user/[0-9]*/snap.@{SNAP_NAME}/scoped_.*/SingletonSocket r, However I don’t really understand what that means or how to do that ^^

Maybe I should also mention that I am using core20 for snap (Electron v19 uses core18 by default, I had to upgrade it to solve a separate issue)