sbt "server ... already running" lock error in CI
sbt takes a lock on the project (and starts a server) so two sbt processes do not corrupt shared state. When a previous run left a stale lock, or two steps launch sbt at once, the new process reports the project is already locked or the server is already running.
What this error means
sbt fails or hangs with "Project ... is being used by another sbt process" or "waiting for lock" / "server is already running", often after a cancelled prior run.
[error] java.io.IOException: Project loading failed: waiting for lock on
/home/runner/work/app/app/project/target/.sbt.ipc held by another process
[error] sbt already running: server socket in useCommon causes
A stale lock from a cancelled run
A prior sbt process was killed without releasing the lock, leaving a lock file or server socket that the new run cannot acquire.
Two sbt invocations sharing the same project dir
Parallel CI steps both launch sbt against the same working copy, and the second blocks on the first process's lock.
How to fix it
Run sbt in batch mode without a persistent server
- Invoke sbt with all tasks in one non-interactive command so it exits and releases the lock.
- Avoid launching a second sbt against the same directory concurrently.
- Clear stale lock/socket state if a previous run was killed.
sbt --batch clean compile testSerialize sbt steps against one working copy
Combine sbt tasks into a single invocation rather than several parallel sbt steps sharing the same checkout.
sbt "clean; compile; test; assembly"How to prevent it
- Run one sbt invocation per job with all tasks batched together.
- Do not run parallel sbt steps against the same working directory.
- Use fresh runner workspaces so no stale lock survives between runs.