Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

[rush] rush-daemon-transport: long socket paths are silently truncated so workspaces share one daemon; reclaim lock steal is not exclusive; deleting the runtime dir leaves an unreachable daemon running

Aberta
  • Algo errado?
#6,083 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
45/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
linux, nodejs, typescript
Domínio
cli, devtools, tooling

Direção de pesquisa

The issue points to specific files: libraries/rush-daemon-transport/src/DaemonPaths.ts for socket path length, DaemonReclaimLock.ts for mutex handling, and DaemonReclaim.ts for lock cleanup. Start by reproducing the truncation with a long XDG_RUNTIME_DIR, then examine the socket creation and reclaim lock logic. Testing involves concurrent processes and file system operations. 'Done' means each of the three problems is fixed with robust error handling and atomic operations.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Summary

Three robustness problems in the daemon transport, each reproduced on Linux with rush-client/rushd from main @ 60007c9a8c:

  1. Socket paths longer than sun_path (108 bytes) are silently truncated, so different workspaces share one daemon. resolveDaemonPaths (libraries/rush-daemon-transport/src/DaemonPaths.ts:61-67) builds <base>/rushd-<uid>/rushd-<32hex>.sock (the base plus 55 bytes) and never checks the result against the limit. Node/libuv then truncate the path on listen()/connect(). The part that gets cut off is the workspace key: with a 77-character base the socket is named rushd-44c88aeea54e6, and with 90 characters it is just rushd-. So with a long XDG_RUNTIME_DIR or TMPDIR (deep CI, sandbox, Nix or Bazel-style directories), workspace B talks to workspace A's daemon: daemon status in ws2 reports ws1's PID, build fails with Cannot attest the restarting daemon ownership, and daemon stop in ws1 can stop the wrong daemon. Expected: detect overlong paths and switch to a shorter derived location (for example a hashed path under a short base), or fail with a clear error. Never truncate silently.
  2. The reclaim mutex's steal path is not exclusive. On EEXIST with a dead mutexPid, tryAcquireReclaimLock (DaemonReclaimLock.ts:73-86) calls rewriteMutexEntry (:47-64), which does unlinkSync(lock) and then writeFileSync(lock, { flag: 'wx' }). Two stealers can both see "dead holder"; B then unlinks A's fresh file and creates its own, so both acquire. In 10 trials with 16 concurrent stealers, every trial had more than one holder (2-6). In addition, readMutexPid treats a just-created, still-empty file as dead, and the finally in DaemonReclaim.ts:46-52 unlinks .reclaim even when another process owns it. Expected: steal atomically (for example rename a uniquely named file over the lock and re-verify ownership after writing), and release only a lock you still own.
  3. Deleting the runtime dir or socket leaves an unreachable live daemon running alongside a new one. systemd-logind removes /run/user/<uid> at logout, and tmp cleaners can remove it too. The old daemon keeps running, unreachable, until its idle timeout (900 s by default); the next client auto-starts a second daemon for the same workspace; and daemon stop only reaches the new one. Expected: after binding, the host periodically re-validates that lstat(socketPath) still matches the bound inode and that the lockfile still names its own PID, and shuts down (or re-publishes its endpoint) when it doesn't.

Repro steps

  1. Start the daemon with XDG_RUNTIME_DIR=<90-char dir> in two different workspaces, then run daemon status in the second: it reports the first workspace's PID.
  2. Seed <key>.pid.json.reclaim with {"mutexPid": <dead pid>} and have 16 forked processes call tryAcquireReclaimLock at the same moment: more than one acquires.
  3. rush-client daemon start && rush-client build, then rm -rf $XDG_RUNTIME_DIR/rushd-<uid>, then rush-client build: two daemon processes now exist for the workspace.

Expected result: As described for each item above.

Actual result: As described for each item above.

Details

This was found during an automated performance/behavior analysis of rush-client/rushd on Linux. Each item was confirmed independently (item 1 twice).

Standard questions

Question Answer
@microsoft/rush globally installed version? built from main @ 60007c9a8c (5.179.0)
rushVersion from rush.json? 5.179.0
pnpmVersion, npmVersion, or yarnVersion from rush.json? [email protected]
(if pnpm) useWorkspaces from pnpm-config.json? true
Operating system? Linux (WSL2 Ubuntu 24.04)
Would you consider contributing a PR? Yes
Node.js version (node -v)? 22.23.2
Linguagem predominante
TypeScript
Estrelas
6.5k
Forks
710
Merge médio
1d 15h
PRs com merge (30d)
37

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

  • Sem Dockerfile nem arquivo Docker Compose
  • Tem um modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de microsoft/rushstack

Todas as issues de microsoft/rushstack

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.