Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues 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

Ouverte
  • Quelque chose ne va pas ?
#6,083 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
45/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
linux, nodejs, typescript
Domaine
cli, devtools, tooling

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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
Langage dominant
TypeScript
Étoiles
6.5k
Forks
708
Merge moyen
2 j 1 h
PR mergées (30 j)
46

Préparer son environnement

Nous n'avons pas encore vérifié les fichiers d'installation de ce projet. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de microsoft/rushstack

Toutes les issues de microsoft/rushstack

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.