yarn start / npm start / reac-static start errors with 'Error: watch /home/mrh/src/safe-sites/safe-dweb-blog/static.config.js ENOSPC'

[happybeing]

Are you reporting a bug?

Kind of

Environment

    react-static -V: 6.1.5
    node -v: 8.11.3
    npm -v: 6.4.1
    Operating system: Ubuntu 18.10
    Browser and version (if relevant):

Steps to Reproduce the problem

create a new project with react-static create and use the 'basic' template
cd into the project and type yarn start, or npm start, or react-static start. Note that yarn build and yarn serve behave as expected. Result for yarn start is as follows:

$ yarn start
yarn run v1.7.0
$ react-static start
events.js:183
      throw er; // Unhandled 'error' event
      ^

Error: watch /home/mrh/src/safe-sites/safe-dweb-blog/static.config.js ENOSPC
    at _errnoException (util.js:992:11)
    at FSWatcher.start (fs.js:1382:19)
    at Object.fs.watch (fs.js:1408:11)
    at createFsWatchInstance (/home/mrh/src/safe-sites/safe-dweb-blog/node_modules/chokidar/lib/nodefs-handler.js:37:15)
    at setFsWatchListener (/home/mrh/src/safe-sites/safe-dweb-blog/node_modules/chokidar/lib/nodefs-handler.js:80:15)
    at FSWatcher.NodeFsHandler._watchWithNodeFs (/home/mrh/src/safe-sites/safe-dweb-blog/node_modules/chokidar/lib/nodefs-handler.js:232:14)
    at FSWatcher.NodeFsHandler._handleFile (/home/mrh/src/safe-sites/safe-dweb-blog/node_modules/chokidar/lib/nodefs-handler.js:259:21)
    at FSWatcher.<anonymous> (/home/mrh/src/safe-sites/safe-dweb-blog/node_modules/chokidar/lib/nodefs-handler.js:480:21)
    at FSReqWrap.oncomplete (fs.js:153:5)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Expected Behavior

yarn start
yarn run v1.7.0
$ react-static start
=> Building Routes...
=> [✓] Routes Built (0.5s)
=> Building Templates
=> [✓] Templates Built
=> Building App Bundle...
=> [✓] Build Complete (5.8s)
=> [✓] App serving at http://localhost:3000
=> File changed: /tmp/dev-server/index.html
=> Updating build...
=> [✓] Build Updated (0.4s)
=> File changed: /src/App.js
=> Updating build...
=> [✓] Build Updated (0.5s)

Solution

The problem appears to be due to the number of files being watched hitting a limit, which can be increased by the following command:

echo fs.inotify.max_user_watches=582222 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

After running that, yarn start should behave as expected.

I don't know why I hit this while others presumably have not yet, as @tannerlinsley hasn't seen this before. I found the solution in this issue comment.

[tannerlinsley]

If you post a link to your repo, we may be able to debug this, but I think I would classify this as extreme edge case. As long as you were able to get around it for now, let's plan on debugging it soon and going forward with your fix. The amount of files to be watched should not be large at all, not even hundreds (for a large site).

Marking this with enhancement, given it's very edge case.

[happybeing]

Creating a repo shouldn't help I think, as all I did was `react-static create` and choose the 'basic' template. Obvs that shouldn't create many files, so either it is inadvertently watching files elsewhere (eg starting at a parent directory) or the limit was too small in my system. I suspect the former, but don't know as I haven't used hot reloading much on this machine. I agree it's an edge case, and posted the issue mainly to help others find the workaround if it happens again. -- Helping decentralise the Internet with: SAFE Network - Secure Access For Everyone, https://safenetwork.tech Project Solid - Tim Berners-Lee's vision of the Web, https://solid.mit.edu

[tannerlinsley]

Would you be open to editing some source files in your local React Static to help us nail down the issue?

[happybeing]

Sure, but first I will compare what I have with the basic template on github because I wonder if this is related to the warnings I reported from `yarn build` about the size of some output being bigger than recommended. If there were extra files there for some reason, maybe that explains both issues. Can't do that just now, but will reply here or on spectrum when I've had a look.

[tannerlinsley]

Sounds good.

…

On Jan 8 2019, at 11:46 am, Mark Hughes (happybeing) ***@***.***> wrote: Sure, but first I will compare what I have with the basic template on github because I wonder if this is related to the warnings I reported from `yarn build` about the size of some output being bigger than recommended. If there were extra files there for some reason, maybe that explains both issues. Can't do that just now, but will reply here or on spectrum when I've had a look. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub (#952 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/AFUmCRxodpWjANTgwEADc899aryAYeseks5vBOd_gaJpZM4Z19z3).

[happybeing]

Hmm, well to update:

• I don't see anything odd in the contents of my 'basic' project (175M of files in node_modules but that's not unusual)
• I had a hunch that maybe I have so many files under projects in Atom that this was putting me close to the watch limit, but even having reverted the fs.inotify.max_user_watches solution, I can no longer trigger this error.

So the issue is probably to do with my system state. Maybe Atom active project files, maybe not, but until I can reproduce it I guess we should wait and then I'll revisit.

[Pixelatex]

You can just create your app outside of atom with terminal and see if atom is indeed the culprit here.

[happybeing]

You can just create your app outside of atom with terminal and see if atom is indeed the culprit here.
Indeed, unfortunately the problem has gone away so I can't do this until it comes back.

[happybeing]

I can confirm the cause in my case is having lots of files under projects open in Atom. This must have pushed the fs watch near or past its limit, so that when I manually set this (as described under Solution in the OP) the error goes away.

Undoing that setting didn't take effect until a system restart, so I was only able to verify this today.