Cannot fit name [.../sbt-load.sock] in maximum unix domain socket length

steps

• create an sbt build with a medium deeply-nested folder structure
• try to run a simple command with java.io.tmpdir set to the base folder of the build

In our case it ends up being something like

sbt -Djava.io.tmpdir=/var/lib/jenkins/workspace/some-very-long-branch-name/target/tmp clean

problem

The above command produces the following error message:

sbt thinks that server is already booting because of this exception:
sbt.internal.ServerAlreadyBootingException: java.io.IOException: org.scalasbt.ipcsocket.NativeErrorException: Cannot fit name [/var/lib/jenkins/workspace/some-very-long-branch-name/target/tmp/.sbt/sbt-socket8737049473820614565/sbt-load.sock] in maximum unix domain socket length

I think the issue is caused by sbt/sbt#6887 - although we don't set XDG_RUNTIME_DIR explicitly, I wonder if the code is somehow falling back to java.io.tmpdir.

There is a secondary issue that the error message is slightly misleading ("sbt thinks that the server is already booting") - would it be possible to separate out "the lock file already exists" from other cases such as this one? (I guess the same issue would happen if e.g. the current user didn't have permission to create the lock file in the given location).

expectation

Not sure what the expected behaviour is here. I see there's some discussion on sbt/sbt#7013 about always (?) using /tmp instead, which would be preferable since the socket name is then guaranteed to always be short enough.

Alternatively sbt could pre-check the proposed socket name length (or catch the exception?) and handle it gracefully - either by falling back to /tmp or else giving a helpful error message?

notes

We can work around the issue by also explicitly setting XDG_RUNTIME_DIR to something shorter (e.g. a known folder under /tmp) but this is mildly annoying since we'd ideally like to have a single temp directory under our build Jenkins workspace folder.

Reproduce the failure with the shown sbt command and a long java.io.tmpdir, then trace how the socket path is selected and how the exception becomes ServerAlreadyBootingException. The issue names no source files or tests, and the expected fallback versus error behavior still needs confirmation; done should include a clear, agreed handling for paths exceeding Unix socket limits.