-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WARNING failed to contact turbod. #2034
Comments
In 1.5 we have toggled on using the daemon by default. On your machine the connection between the main turbo process and the daemon is failing. This does not prevent your build from running to completion but we do need to identify why that connection is failing.
|
@nathanhammond Thanks for the reply. How do you even start the daemon? I searched the docs and only the cache config mentions a daemon. I understand the principle, but I just upgraded, didn't make a change to turbo.json to run a daemon. Is this something like Gradle where it spins it up on first launch? Just wanted to mention that some confusion for me is the lack of docs. I also found the option
Edition Windows 10 Pro for Workstations
For me that hexHash join is I am fairly certain I have full permission. I run other go executables and go tools without issue. I can also open and edit the pid file. The sock file is 0 bytes and the pid file has a pid, but when I run that pid is not running, exluding It should be |
the same warning here on Windows 11 |
|
Hi there, also getting the same issue. On trying
I'm on WSL2 with the following details:
Nothing out of the ordinary on the logs, they just say something about
|
Same issue for me on Mac, today installed turbo for first time
Error from log is
|
Gets the same warning message as @MariuzMM and @jayg-hive Been using turbo for a while now. This warning started in version 1.5.2 On Windows10: 2022-09-23T14:16:10.471+0200 [ERROR] turbod: error: EXTRA_VALUE_AT_END="failed to lock the pid file at . Is another turbo daemon running?: Locked by other process" No error on WSL2/Ubuntu :) |
I'm seeing the same after a sweeping upgrade of dependencies today. Log output is a repeat of:
Console is outputting:
Reverting and hard-coding to |
Couple things going on:
For those of you hitting the warning, can you confirm that |
@gkn if you run |
Running MacOS 12.6 here. When running the command |
Addressing |
Additional context and debugging thoughts:
Also, to everyone, thanks for your patience while we iron out the edge cases on this. There may be platforms and scenarios where the daemon does not work or does not provide benefit, and we'll work to detect those and behave accordingly as we identify them. |
Hopefully this will help. I run the daemon and no errors to the console etc. Looks good using When I run |
Yup, no breakage whatsoever. It still runs the intended task. 👍 |
On Windows 10:
I still get the same warning message but now get a log file without error messages, just a lot of fsnotify messages. It even includes folders that is not specified as part of npm workspaces. This seems odd and wasteful, especially since it will watch node_modules in that folder too: 2022-09-24T08:41:40.051+0200 [DEBUG] turbod.rpc server.fsnotify: watching directory C:\xxxx\tools\storybook\node_modules@mrmlnc Initial startup seems slow. Monorepo is relatively large, a few hundred folders with roughly 5000 source files.
I primarily use WSL2/Ubuntu for this project. I noticed that the size of the turbod log file was large. (roughly 1.5 million lines, 260 MB) in just a few turbo runs since yesterday. Seems odd. |
The logging and |
Same here, I'm running
I ran |
Gets the same warning, and the log file is empty. On Windows 11, turbo 1.5.4 |
@klapec the |
@gsoltis Thanks for the response. It did appear at the root of my monorepo, I assume it was either created by upgrading turbo to 1.5.4 (postinstall?) or by the codemod. I haven't seen exactly when was it created, I noticed it when I was about to commit my changes to the repository. |
@klapec got it. we're looking into how it could've ended up in that spot, but it's safe to delete. Sorry about that! |
For the windows users in this thread: it looks like we have an issue somewhere between Go, windows support for |
We've published For those curious about the nitty-gritty details:
Not to worry though, we can patch it to do special handling on windows. Coming soon. |
@gsoltis Tried out turbo@1.5.5 on both WSL2/Ubuntu and on the (disabled) Windows variant now. No noticeable issues - good work :) If you have the time, could you please explain where we actually benefit from utilizing the daemon? I cannot say I notice any differences and could not find any documentation addressing that btw. |
I was able to fix it by deleting |
Just started happening here on MacOS and Windows machines. Seems this is actively being worked through though just confirming this is still happening as my time posting here. |
same thing is happening to me for the latest version 1.9.3 |
works for win10 by deleting |
Issue still present on MacOS 13.3.1 (a), running under pnpm 8.5.1. Temporarily fixed by removing the |
Issue still present: MacOS 13.3.1
|
@ekqt I just resolved it by running |
I believe this is triggered when upgrading the turbo local dependency. I haven't had any success using the npx codemod, and upgrading it via |
Hello everyone! I just deleted the file that showed in the warn |
If you run If you run |
Getting the error |
I updated to I first tried getting the process from the |
I was also getting the error. By following the above instructions, I deleted the temp files in turbod directory. Now there is no error while using turbo |
If I try to clean and start the daemon I get:
|
Same here, on MacOS (M2)
|
I'm getting the exact same response |
Also same |
+1 as well |
One of the guys on my team solved this by deleting his package-lock.json and running the install again. That was what worked for him. |
Delete lock file and reinstall could potentially break your application tho. |
Since today i get that error regularly with v1.10.7 |
Hello folks, we have been shipping a host of daemon improvements (including a total rewrite) over the last year or so, so while I am not promising there are no issues, the set of issues that you can hit are completely different and I think that warrants opening a new ticket for the new daemon, since it is hard to filter in this thread between current problems and ones affecting the old implementation. Thank you all for chiming in and helping make turbo better, and don't hesitate to open a new issue if you are still having issues post 1.11. |
What version of Turborepo are you using?
1.5.1
What package manager are you using / does the bug impact?
npm
What operating system are you using?
Windows
Describe the Bug
After upgrading from 1.4.7 I now get a warning. Following the warning text leads to not a fix. The log is fine and I've removed the temp files, no fix.
Expected Behavior
No warning or turbod properly launching. If a warning must be shown, it should reflect failure to launch turbod, not contact it.
To Reproduce
Upgrade a 1.4.7 to 1.5.1
The text was updated successfully, but these errors were encountered: