Vscode: Snap package: "Error: listen EACCES on startup"

[TimOrme]

• VSCode Version: 1.20.1 (From snap install)
• OS Version: Ubuntu 17.10

On launching, VSCode errors out with the following:

vscode --disable-extensions --verbose [main 9:49:58 AM] Error: listen EACCES /run/user/1000/snap.vscode/Code-1.20.1-main.sock at Object.exports._errnoException (util.js:1050:11) at exports._exceptionWithHostPort (util.js:1073:20) at Server.setupListenHandle [as _listen2] (net.js:1247:19) at listenInCluster (net.js:1304:12) at Server.listen (net.js:1413:5) at /snap/vscode/25/usr/share/code/resources/app/out/vs/code/electron-main/main.js:154:456 at new n.Class.derive._oncancel (/snap/vscode/25/usr/share/code/resources/app/out/vs/code/electron-main/main.js:81:234) at Object.t.serve (/snap/vscode/25/usr/share/code/resources/app/out/vs/code/electron-main/main.js:154:386) at n (/snap/vscode/25/usr/share/code/resources/app/out/vs/code/electron-main/main.js:443:882) at J (/snap/vscode/25/usr/share/code/resources/app/out/vs/code/electron-main/main.js:446:235)

And fails to start. The application was working fine for a while, and I've only seen this behavior as of this morning.

Does this issue occur when all extensions are disabled?: Yes

[TimOrme]

And after a few hours of not working, and not changing anything, it seems to have fixed itself...

[stobbsm]

Same issue, using the snap on KDE Neon (Ubuntu 16.04)

[sduchesneau]

workaround is to: mkdir /run/user/1000/snap.vscode

It's mainly a missing folder that's causing the EACCES when creating the socket.

[rodroma-zz]

@sduchesneau fix solved it for me. Thank you!

[TimOrme]

It is interesting that the file seems to have been created magically after some time. I wonder if this is something to do with how snaps work? I don't know enough about them but is it possible that an update was running behind the scenes at the time I was trying to startup?

[sduchesneau]

I'm (moderately) trying to gather some information about this. Here are the facts that I found out:
1) /run (and /var/run which is a symlink to /run) is NOT a persistent folder! Example: https://serverfault.com/questions/74796/directory-in-var-run-gets-deleted-after-hard-reboot
2) The "correct" way of automatically creating folders in a non-persistent folder after reboot with systemd-enabled-systems is to use tmpfiles.d (man tmpfiles.d)

I cannot find where is the code that should add the tmpfiles.d (or even a mkdir in a startup script) -- is it a builtin in snapcraft or in vscode, but it seems something is not doing its job right, of ensuring existence of that folder on reboot. I'm not sure of every situation where /run gets cleaned up ("hard" reboot, soft reboot.. whatever) but the snap package should NOT assume that it won't.

Now, who is a snap guru to help us with finding the piece of code to fix? ;)

[mainmachine]

I also got hit with this today, on Ubuntu 16.04. Thought it was something I'd done with libvirt and network namespaces, but other snaps worked fine.

@sduchesneau - Thank you so much for the workaround!

[TimOrme]

Seems to recur as well, I started up this morning and it's re-appeared. I'll leave it and see if it recovers again.

[mainmachine]

Now, who is a snap guru to help us with finding the piece of code to fix? ;)

@sduchesneau - This fellow might be the guy to talk to. Can't see where to report a bug on this specific snap...

[julian-alarcon]

Hey @flexiondotorg can you help us with this? I got the same issue

[flexiondotorg]

I've sent a fix to Daniel on the VS Code team and will fix my build today.

[Tyriar]

I fixed this on tyriar/snap so I'll close. Track snap distribution in https://github.com/Microsoft/vscode/issues/5458