Yarn classic is unmaintained - I'm just noting this here as a point of reference/pointer for others
When using --mutex=network, Yarn attempts to start an HTTP server on the configured port. If it fails, it tries to ask whatever is listening for its name, and then waits for it if it appears to be a Yarn process.
This can go wrong in a few ways, often leading to infinite recursion due to the retry behaviour.
If Yarn isn't allowed to listen on the configured port.
The listening process doesn't respond to an HTTP request (hangs or closes).
The listening process is a non-Yarn HTTP server that responds with JSON (Yarn tries to wait for it by opening a socket)
The only circumstance where Yarn correctly reports Cannot use the network mutex on port 31997. It is probably used by another app is when the listening process is an HTTP server that responds with anything other than JSON.
We're patching this locally by not retrying with startServer() on errors, and adding a timeout for unresponsive sockets.
Yarn classic is unmaintained - I'm just noting this here as a point of reference/pointer for others
When using
--mutex=network, Yarn attempts to start an HTTP server on the configured port. If it fails, it tries to ask whatever is listening for its name, and then waits for it if it appears to be a Yarn process.This can go wrong in a few ways, often leading to infinite recursion due to the retry behaviour.
https://github.com/yarnpkg/yarn/blob/158d96dce95313d9a00218302631cd263877d164/src/cli/index.js#L419-L447
The only circumstance where Yarn correctly reports
Cannot use the network mutex on port 31997. It is probably used by another appis when the listening process is an HTTP server that responds with anything other than JSON.We're patching this locally by not retrying with
startServer()on errors, and adding a timeout for unresponsive sockets.