Use XDG_RUNTIME_DIR environment variable to choose the path used for the creation of sockets #6887
Conversation
|
Hi @AlonsoMontero, @AlonsoM45, Thank you for your contribution! We really value the time you've taken to put this together. Before we proceed with reviewing this pull request, please sign the Lightbend Contributors License Agreement: |
|
Thanks for the contribution. Rather than creating a system property for this specific use case, I wonder if we should use this as an opportunity to adhere to some existing standards like XDG Base Directory Specification (#3681). For instance, I think it recommends socket files to be created under What do you think? |
Uses environment variable XDG_RUNTIME_DIR instead of -Dsbt.altSockLocation in order to choose the location for the sockets.
|
Hello, I changed the code in order to use the |
|
Yea. Mostly looks good I think. Could you update the description of the PR to reflect the update please? |
AlonsoM45
changed the title
Done, I have just updated it. |
|
Thanks @eed3si9n for your review, your suggestions and for merging this PR. I had a question for you, if you don't mind: Do you have an estimated date for the next release? |
|
@AlonsoM45 It's a bit concerning that the develop branch is no longer passing on CI though. I don't know if this is caused by merging this PR. |
|
|
…the creation of sockets (sbt#6887) The `XDG_RUNTIME_DIR` environment variable will be used to choose the base directory in which the sockets will be created by **sbt**. This can help when issues such as sbt#6777 appear. There are other related issues, such as sbt#6101, [Metals issue sbt#2235](scalameta/metals#2235), [Che issue #18394](eclipse-che/che#18394). Those are closed issues, but there are some cases in which the solution does not work (such as the case in sbt#6777). Furthermore, the solution given seems more like a workaround than an actual fix. **What causes this issue?** At least in my case, the **ServerAlreadyBootingException** is thrown after **sbt** tries to create a Unix domain socket and fails. In my specific environment, I was not able to create the sockets in some directories because they were mounted on an NFS. This prevented me from using any automated sbt command on any of those directories (Metals uses sbt under the hood, and it was not able to start because of the ServerAlreadyBootingException), which in turn resulted in me not being able to use Metals on a project that was created on any of those directories. **How is the issue solved in this PR?** If the `XDG_RUNTIME_DIR` environment variable is set, then sockets will be created in a folder with a hashed name, inside the directory `XDG_RUNTIME_DIR/.sbt/`. If this variable is not set, everything works exactly the same as always. Let's see an example: 1. My environment variable `XDG_RUNTIME_DIR` is set to /home/alonso/.runtime-dir` 2. I create my project in `/home/alonso/workspace/hello-world` 3. I run `sbt compile` 4. The socket is created in `/home/alonso/.runtime-dir/.sbt/sbt-socket102030405060/sbt-load.sock`. The number **102030405060** is a hash that is computed from the base directory of the project (it is actually the same hash that is produced in order to create sockets in Windows) and it will be different depending on the location of the project 5. The sbt command executed correctly, which would not have happened if the socket had been created in the `home/alonso/workspace` directory or any of its subdirectories (in this example, `/home/BlackDiamond/workspace` corresponds to a network file share) Co-authored-by: Alonso Montero <lumontero@mobilize.net>
|
#6907 tested and merged. |
|
Hello. I saw that CI is passing now. I assume everything is OK now on that side. Thanks for backporting this to 1.7.x. |
|
One possible issue with defaulting to |
|
This change seems to negatively effect macOS where for some reason if Edit: the problem in macOS was caused by #6935 which sets the default directory to be a temp directory - which is too long for a unix socket on macOS |
The
XDG_RUNTIME_DIRenvironment variable will be used to choose the base directory in which the sockets will be created by sbt. This can help when issues such as #6777 appear. There are other related issues, such as #6101, Metals issue #2235, Che issue #18394. Those are closed issues, but there are some cases in which the solution does not work (such as the case in #6777). Furthermore, the solution given seems more like a workaround than an actual fix.What causes this issue?
At least in my case, the ServerAlreadyBootingException is thrown after sbt tries to create a Unix domain socket and fails. In my specific environment, I was not able to create the sockets in some directories because they were mounted on an NFS. This prevented me from using any automated sbt command on any of those directories (Metals uses sbt under the hood, and it was not able to start because of the ServerAlreadyBootingException), which in turn resulted in me not being able to use Metals on a project that was created on any of those directories.
How is the issue solved in this PR?
If the
XDG_RUNTIME_DIRenvironment variable is set, then sockets will be created in a folder with a hashed name, inside the directoryXDG_RUNTIME_DIR/.sbt/. If this variable is not set, everything works exactly the same as always.Let's see an example:
XDG_RUNTIME_DIRis set to /home/alonso/.runtime-dir`/home/alonso/workspace/hello-worldsbt compile/home/alonso/.runtime-dir/.sbt/sbt-socket102030405060/sbt-load.sock. The number 102030405060 is a hash that is computed from the base directory of the project (it is actually the same hash that is produced in order to create sockets in Windows) and it will be different depending on the location of the projecthome/alonso/workspacedirectory or any of its subdirectories (in this example,/home/BlackDiamond/workspacecorresponds to a network file share)