System limit for number of file watchers reached #7612
Comments
|
I agree that we could provide a better user experience. IMO: Pretty much every software developer bumps their inotify limits once and then never thinks about it again, so this is potentially a lot of work and complexity (changing how we watch isn't necessarily an easy feat) for a rare and easy to fix edge case. |
|
I agree in principle but "this is potentially a lot of work and complexity" is a blanket reaction against doing anything and in my opinion is an overstatement. Shouldn't this just be a one line of code in the configuration? C'mon, if excluding a folder from the watcher is going to add "a lot of work and complexity" then something isn't right. Then possibly another line in package.json to run the build without watching that folder? The watcher implemented in chokidar was actually only watching files loaded during the course of running the application, not all files in node_modules. I could see that I was running above the limit because a certain version of VSCode was trying to watch all the files in the project. Switching to VSCode insider version solved this for me. However, I actually tried to figure out what it would take to exclude certain folders from watching and it wasn't easy. Stating that the default is for each and every developer to bump their inotify limits is bad. The application should be designed and implemented in such a way that such a simple task should be completed in no time. |
This is kinda the status quo for development, no? I bumped my inotify limits a long time before create-react-app even existed. Development tools, especially in the node ecosystem, tend to watch a lot of files. Heh, like I said I think this a good idea! I'm just not personally interested in doing it. CRA is maintained entirely by unpaid volunteers; if the change is "one line of code in the configuration" then please submit a thoughtful PR and join our unpaid ranks :) |
|
The complexity isn't not watching node_modules fwiw, it's gracefully catching ENOSPC and updating our watch priority accordingly. I think that we could probably provide a better error message, but again if you google "node ENOSPC error" you probably land on a stack overflow post telling you how to fix it. |
|
To reiterate, I said that in my opinion it should be a one-line-of-code-type-of-change but it wasn't so easy when I tried to do the change. In other words, CRA requires to watch all files ever loaded in the app and it doesn't work if the amount of files in the project is larger than the system limit set elsewhere. There is nothing you can do about that in the code. It's a hard requirement and as such should be listed in the documentation. If someone doesn't know how to or can't (e.g. because of permissions) change the limits in their system they should not consider CRA in their project.
No. Watching each file takes CPU and memory. I would rather disable watching node_modules. I understand the work is done by volunteers and no one really cares. I don't think there is any urgency in fixing this issue, but I would like to see this resulting in an easier configuration to exclude certain folders from the watcher. And if you tell me how to accomplish this I am more than happy to make the necessary changes. |
I just looked at the code and node_modules isn't watched. We're definitely not going to provide configuration to allow you to disable watching files inside of your project tree. Still open to providing a better error message on ENOSPC. It doesn't look like webpack provides any hooks to catch errors thrown by its watcher, so it might be kinda difficult. |
|
I added logs to the chokidar module and I could see files from node_modules being added to the watcher when they were loaded by the app. Otherwise I wouldn't have raised this issue. I will recreate the scenario tomorrow and provide relevant logs. |
|
Sorry for the delay. I added: in It doesn't watch all files in node_modules but to me it looks like it does watch all files ever loaded or served in the app. |
|
I have had this error too. Try
This document helped me |
|
Thanks @obendesmond ! Works for me |
|
I think the resolution to this if any is to add a bit of documentation in our troubleshooting page linking or explaining how to increase the limit if running into this error. |
|
My pleasure @matheusgnreis |
This works for me as well |
this is working very well. Thank you for help. |
Thanks. |
How to increase the limit is easy to lookup on the internet (it's even available above). But it's like asking someone to buy a better phone when they complain that the web page is too big to render. Instead of fixing symptoms, the proper fix would be to fix the root cause - not adding Best fix would be to expose the watcher configuration where one could define to ignore any folders or files of their choosing, not just I tried to do that but I couldn't find where |
|
Created a project using Web template studio in vscode got same error |
//This command will definitely solve our issue.. |
|
delete react node_modules rm -r node_modules
yarn or npm install
yarn start or npm startif error occurs use this method again |
|
In case it's useful to have another point of view: Today is the first time I've tried building a project with React. I have no experience with Node, I'm a Python developer that was interested in learning. It took about 1 hour from a cold start to me finding this bug as the top result when I googled this error message. It's not at all clear to me why increasing the inotify limit is desirable, as I don't yet know if it's possible to test my code without subscribing to file changes because I'm only a few minutes into using this software. It's a bit disheartening to find a bug report for the error you're having and have it dismissed as something that's an edge case because it only affects beginners. It looks like a PR has been submitted that will fix this, which is good. |
|
This is a note for anyone landing on this ticket after it has been closed. This issue is caused by A proposed fix was to exclude from watcher files from A workaround is of course increasing the system limit, which was by many (incorrectly) reported as the fix, also within this ticket. I tried to make a change in the code to allow excluding certain folders but it was not easy. So I gave up hoping someone will be able to help. Instead, the ticket was closed. So, if you plan to use |
Nah fam, apparently it's more than that. |
Fam!! I think I just might have gone bald due to this bug. I was just all about to go all in on my developing beards - Thanks for saving them! |
|
Welcome @tegaguru |
Thank you very much! |
Thanks folks! |
|
Hello! Just popping in to support the sentiments of @amiramix - the solution offered isn't possible for me to use as a student working in a linux environment without root permissions. This problem cripples student adoption of react native at my university. |
Describe the bug
npm startends with a cryptic error due to exceeding the amount of files the system can watch:Did you try recovering your dependencies?
Yes
Which terms did you search for in User Guide?
exclude blacklist folders directories watch watched
Environment
Steps to reproduce
cat /proc/sys/fs/inotify/max_user_watches)My project doesn't even have many dependencies. Mostly added with
npm i apollo-boost graphql react-apollo -S. And it already created three times as many files as the maximum currently allowed by the system to watch. I would expect this problem to be quite common on some systems.Expected behavior
I am aware of the solutions provided in #2549 and #6068.
Asking users to increase the limit only pushes the problem further without resolving it. And in my opinion is a workaround for a bad design. It also provides a less than ideal user experience and unnecessarily raises the bar for newbie developers.
The
npm startscript should either:The script can then ask the user to restart the app after updating dependencies and show info to how to enable watching
node_modulesif they want to recompile automatically after updating dependencies. From my experience it's better to restart the application after dependencies have been updated rather than rely on watch due to problems with watching and compiling source files in linked npm modules (if used of course).The script can show a warning to the user telling them there is a problem and how to resolve it, then fall back to not watching
node_modulesuntil it's resolved. Detecting how many files is in the project is quite quick:startthat skips watchingnode_modules.Providing such a script, say
quick-start, could also serve as a quick example how to exclude certain folders from the watcher should the user opt to do that.In any case the scripts documentation and/or troubleshooting and/or Advanced Configuration guide should mention that the
startscript will attempt to automatically watch all files in the project, includingnode_modules. Then it should be documented how to enable or disable (depending on what's the default behaviour) watching specific folders, including how to enable or disable watchingnode_modules.Actual behavior
Application doesn't start. Only a cryptic error is shown to the user. For less advanced users it's not possible to figure out what the problem might be without searching the internet and learning all the theory about inotify, kqueue (FreeBSD or Mac) and system limits. They may try various snippets of code available on Stack Overflow or other resources to increase the system limit, which may or may not work due to differences between systems.
The text was updated successfully, but these errors were encountered: