Failed to connect to daemon error on macOS

[JoCa96]

Verify canary release

• [X] I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

https://github.com/JoCa96/turbo-bug

What package manager are you using / does the bug impact?

npm, pnpm

What operating system are you using?

Mac

Which canary version will you have in your reproduction?

2.2.4-canary.7

Describe the Bug

Running a watch command results in an error even when the daemon is not used:

e.g.

• pnpm exec turbo watch --filter=pkg-a dev:run
• pnpm exec turbo --no-daemon watch --filter=pkg-a dev:run
• TURBO_DAEMON=0 && pnpm exec turbo --no-daemon watch --filter=pkg-a dev:run

turbo 2.2.4-canary.7

• Packages in scope: pkg-a
• Running dev:run in 1 packages
• Remote caching disabled
  × failed to connect to daemon
  ├─▶ timeout while watching directory: deadline has elapsed
  ╰─▶ deadline has elapsed

Expected Behavior

No error

To Reproduce

cd packages/pkg-a
pnpm run dev

Shows log:

turbo 2.2.4-canary.7

• Packages in scope: pkg-a
• Running dev:run in 1 packages
• Remote caching disabled
  × failed to connect to daemon
  ├─▶ timeout while watching directory: deadline has elapsed
  ╰─▶ deadline has elapsed

Additional context

• bug also appears on older system
• ps axu | grep turbo shows:

user  xxxxxx   0.0  0.0 408858800  13872   ??  Ss    9:52AM   0:00.14 /xxx/my-turborepo/node_modules/.pnpm/[email protected]/node_modules/turbo-darwin-arm64/bin/turbo --skip-infer daemon

• npx envinfo --system --npmPackages turbo --binaries prints the following

  System:
    OS: macOS 13.6.7
    CPU: (10) arm64 Apple M1 Max
    Memory: 1000.77 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.17.0 - ~/Library/Caches/fnm_multishells/91962_1730884903902/bin/node
    Yarn: 3.4.1 - ~/Library/Caches/fnm_multishells/91962_1730884903902/bin/yarn
    npm: 10.8.2 - ~/Library/Caches/fnm_multishells/91962_1730884903902/bin/npm
    pnpm: 8.15.6 - ~/Library/Caches/fnm_multishells/91962_1730884903902/bin/pnpm
    bun: 1.1.21 - ~/.bun/bin/bun
  npmPackages:
    turbo: ^2.2.4-canary.7 => 2.2.4-canary.7

[eduardoroliveira]

Cleaning the cache with the command below, solved the issue for me:

npx turbo daemon clean

[JoCa96]

Unfortunately, this only resolves the issue for a short time.

[mtoader]

This seems to happen to me also with 2.3.3 and latest canary .. One thing i noticed was that when this happens i get two folder in the turbod folder:

➜ ls -al /var/folders/_1/m_2xrg4d5vqgmswzr51dsg700000gp/T/turbod/
total 0
drwxr-xr-x    4 mihai  staff   128 Dec 21 09:56 .
drwx------@ 134 mihai  staff  4288 Dec 21 10:02 ..
drwxr-xr-x    4 mihai  staff   128 Dec 21 09:56 4f0d47126379be71
drwxr-xr-x    2 mihai  staff    64 Dec 21 09:56 72d3d2bdcd2f7576

the client (process that runs the main watch command) seems to be using the 72.. while the daemons seems to be using 4f ...

I assume the daemon is spawned with a slightly different config (or hash) and because of that can't connect.

This effectively makes turbo watch unusable.

[PerryFinn]

I encountered the same problem, even using npx turbo daemon clean could not solve the issue.

[mtoader]

The issue is, the daemon is launched from a child folder, not the repo root and it's path sha is different.

I managed to work around by wrapping the turbo launcher in my repo with a turbo daemon start in the root path and then things work out.

[nktnet1]

Ran into a similar issue on MacOS

• Remote caching disabled
  × failed to connect to daemon
  ╰─▶ server is unavailable: channel closed

had to kill the process with

pkill turbo

every time it happens :/

---

Update - might also be related to #8491

[JoCa96]

The issue is, the daemon is launched from a child folder, not the repo root and it's path sha is different.

I managed to work around by wrapping the turbo launcher in my repo with a turbo daemon start in the root path and then things work out.

Running turbo from the root directory of the monorepo seems to fix the issue. Thank you @mtoader!

[OllieJennings]

I am still seeing this issue, will there be any proper fix for this, seems like turbo runs well on linux / windows jsut not MacOSX.

@JoCa96 / @mtoader what was your fix to get this working again?

[mtoader]

At that time, i started the daemon from the root of the repo before calling watch. I don't know the current state of affairs with 2.5.2 though.

[JoCa96]

@OllieJennings Running turbo from the project root resolved any failed to connect to daemon issues I had.

So e.g. turbo watch dev in the child directory had the issue, but running turbo watch package-name#dev always works fine.

[OllieJennings]

Thanks @mtoader & @JoCa96 sadly mine just won't work at all :(

[AyushWalekar]

Had same issue. Using turbo 2.5.3 Solved it by:

turbo daemon stop
rm -rf .turbo
# optionally set timeout if you need
# TURBO_DAEMON_TIMEOUT=60000 

turbo daemon start

[kachurun]

I'm running builds with different filters in parallel from the same mounted monorepo root but in different Docker containers, and in that case, I get this error in random containers. It looks like they share the same cache/locks in the .turbo folder and maybe conflict somehow. I have no idea how to solve it and need help guys

[pmioduszewski]

I ran into the same issue after updating macOS to Sequoia 15.7.1 (24G231).

Symptoms in my case:

• pnpm dev failed with

  × Failed to connect to daemon.
    ├─▶ timeout while watching directory: deadline has elapsed
    ╰─▶ deadline has elapsed
  

• It only worked when running with sudo pnpm dev.

• Cleaning the Turbo cache (rm -rf ~/Library/Caches/turbo) or turbo daemon clean didn’t help.

Resetting ownership of the repo back to my user fixed everything:

sudo chown -R $(whoami) /path/to/your/repo

After this, pnpm dev works normally without sudo. I'm not sure why, though.

EDIT: After system restart, the issue returned. I'm using WARP terminal. I've realized that running pnpm dev with the native macOS Terminal works fine. So I've reinstalled WARP and now it works even after system restart.

[tmm1]

This seems to happen often. We see a variety of strange errors:

× Failed to connect to daemon.
 ╰─▶ server is unavailable: channel closed

╰─▶ unable to connect to daemon after 3 retries

  × Failed to connect to daemon.
  ├─▶ unable to make handshake: bad grpc status code: The operation was cancelled
  ╰─▶ bad grpc status code: The operation was cancelled

ERROR: command finished with error: failed to openpty: Os { code: 6, kind: Uncategorized, message: "Device not configured" }

[wolfcarves]

fixed mine by deleting everything including .turbo, node_modules, pnpm-lock.yml

not exactly sure which one have fixed it 😂, just go try better to delete nested .turbo folders as well

rm -rf .turbo pnpm-lock.yml npx npkill -D -y

I've tried running turbo clean, turbo daemon stop & start etc. but that was the only solution worked for me