Java seems to have issues creating UnixDomainServerSocket on persistent storage #18394
Labels
area/languages
Issues related to Language extensions or plugins integration.
kind/bug
Outline of a bug - must adhere to the bug report template.
lifecycle/stale
Denotes an issue or PR has remained open with no activity and has become stale.
severity/P2
Has a minor but important impact to the usage or development of the system.
Comments
sideeffffect
added
the
kind/bug
che-bot
added
the
status/need-triage
|
@sideeffffect thank you for this bugreport. Could you please follow Che's bug template report? Thanks. |
benoitf
added
area/hosted-che
severity/P2
ibuziuk
added
area/languages
|
Issues go stale after Mark the issue as fresh with If this issue is safe to close now please do so. Moderators: Add |
che-bot
added
the
lifecycle/stale
eed3si9n
pushed a commit
to sbt/sbt
that referenced
this issue
May 27, 2022
…the creation of sockets (#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 #6777 appear. There are other related issues, such as #6101, [Metals issue #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 #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>
eed3si9n
pushed a commit
to eed3si9n/sbt
that referenced
this issue
May 29, 2022
…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>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Java seems to have issues creating a
UnixDomainServerSocketwhen using the persistent storage feature. This has been observed on the hosted instanceche.openshift.io.Is that something to be expected?
I'm not sure that it is indeed the case, more detailed investigation would be needed to have 100% proof.
But it would explain, why there are issues when importing a Scala project on Che (with persistent storage). sbt (the Scala build tool), during the import of the project, tries to create a Unix socket on the filesystem but doesn't seem to be able to do so. That causes it to get into a weird state, which blocks the import.
It is reproducible by creating a new Scala project from the available template.
Issue on Metals (the Scala language server) scalameta/metals#2235
Issue on sbt sbt/sbt#6101
/cc @eatkins @tgodzik
The text was updated successfully, but these errors were encountered: