flatpak-run invocations don't share IPC socket

[owtaylor]

Visual Studio Code is designed to run as a single process within the session: if you run code /someproject and then code --new-window /some/other/project the idea is that the second invocation opens <dir>/vscode-<hash>-<version>.sock and asks the initial process to open the second window, where:

 <dir>: $XDG_RUNTIME_DIR if set, otherwise the VSCode userDataDir 
 <hash>: a truncated md5sum of userDataDir
 <version>: 1.54.2 or whatever

But with the Flatpak, every invocation of flatpak-run com.visualstudio.code gets a new temporary $XDG_RUNTIME_DIR created.

This makes alias code="flatpak run com.visualstudio.code" not work very well.

I don't have a great idea for a solution:

• I've created a workaround wrapper script that uses flatpak ps and, if an existing process is found, flatpak enter - but flatpak enter is more a development facility then something to use in production.
• If the wrapper script unset $XDG_RUNTIME_DIR, then the socket would be created within ~/.var/app/com.visualstudio.code/config/Code/, which might work OK. I don't think sharing the user data dir on a NFS home directory would work well anyways.
• Some sort of Flatpak feature added to share $XDG_RUNTIME_DIR between flatpak run invocations?

[antis81]

From my com.visualstudio.code.desktop file:

flatpak run --branch=stable --arch=x86_64 --command=code --file-forwarding com.visualstudio.code --reuse-window @@ %F @@

EDIT: There is also a --share=ipc,network argument.

Hope that helps!

[owtaylor]

From my com.visualstudio.code.desktop file:

Do you think that helps? When I run flatpak run --branch=stable --arch=x86_64 --command=code --file-forwarding com.visualstudio.code twice, flatpak ps shows two copies of com.visualstudio.code.

[antis81]

Actually this can be achieved manually as follows:

1. Open vscode (run the code container)
2. Open the vscode terminal
3. type code <path-to-project>

You should now see two vscode windows while flatpak ps shows a single container! (have a look at flatpak-spawn maybe?)

To re-use the container you will still need to enter it first (similar to docker exec vs `docker run).

[owtaylor]

@antis81 - to explain further - a lot of applications work this way - they only start a single process even if run multiple times. (The second process talks to the first process over some IPC mechanism, passes along command line parameters, and then exits.) These are typically called "single instance applications". When the IPC mechanism is D-Bus, this "just works" for Flatpaks. But Visual Studio Code implements this mechanism with a socket, which it puts in $XDG_RUNTIME_DIR when that's set. And every invocation of 'flatpak run' gets a separate $XDG_RUNTIME_DIR. I put a couple of ideas for working around this in the original post.

[antis81]

This is what I'm saying. :)

[antis81]

@alexlarsson Please I have a question on running a sandbox'ed process as "single-instance" application. I Wrote a little wrapper script (sh) that resembles the code <file/folder> behaviour (com.visualstudio.code). However flatpak enter $INSTANCE seems to create a new empty "env" - so this doesn't function completely. How can I use the env from the running sandbox instance?

For reference here is the snippet:

#!/bin/sh
set -e

APPLICATION='com.visualstudio.code'
COMMAND=/app/bin/code
ARGS=$@

FLATPAK=/usr/bin/flatpak

flatpakInstanceId() {
  # determines the flatpak instance id from 'flatpak ps' command
  # param $1: flatpak application name (see $APPLICATION)

  local application=$1
  local ps_lines=`$FLATPAK ps --columns='instance:f,application:f'`
  local app_line=`echo $ps_lines |grep "$application"`

  # output instance id is in first column
  local inst_id=`echo $app_line |awk '{split($0,a); print a[1];}'`

  echo $inst_id
}

main() {
 local INST_ID=$(flatpakInstanceId $APPLICATION)

  if [ "$INST_ID" != '' ]; then
    echo "entering $APPLICATION instance $INST_ID"
    $FLATPAK enter $INST_ID $COMMAND $ARGS
  else
    echo "starting vscode sandbox"
    $FLATPAK run --branch=stable --arch=x86_64 --command=$COMMAND $APPLICATION $ARGS
  fi
}

main # start here

[owtaylor]

@antis81 - maybe you are running into flatpak/flatpak#3832 - that's been fixed upstream, but not in all distros. See:

https://github.com/owtaylor/toolbox-vscode/blob/main/code.sh#L410

For how I worked around it.

[gasinvein]

This is a duplicate of #75 (although more well described).
This issue will be gone in Flatpak 1.11+, but for older Flatpak versions it's impossible to fix in this app, since it requires patching VSCode itself in order to make it put its sockets in a directory shared between instances.