[FOLIO-2615] investigate "limit for number of file watchers reached" errors in ui-users Created: 22/May/20 Updated: 22/Feb/22 Resolved: 22/Feb/22 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | TBD |
| Reporter: | Zak Burke | Assignee: | Unassigned |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
| Sprint: |
| Description |
|
Recently some ui-users builds failed with their build logs filled with the following error: Error from chokidar (/home/jenkins/workspace/folio-org_ui-users_PR-1304/project/src/routes): Error: ENOSPC: System limit for number of file watchers reached, watch '/home/jenkins/workspace/folio-org_ui-users_PR-1304/project/src/routes/LoansListingContainer.js' steve.osguthorpe pointed out that React's hot-module-replacement creates watchers and could be the source of the trouble here, and as a short-term fix, John Malconian helpfully bumped the inotify watchers limit from 8124 to 24576. That allowed us to get back on track merging PRs, but it clearly works around the problem rather than solving it. We should try to figure out why we suddenly encountered this problem – perhaps a change in a third party dep that we can figure out by diffing some log files? – and if we can pin/increment a particular dep to actually solve the problem rather than just working around it. |
| Comments |
| Comment by Zak Burke [ 22/May/20 ] |
|
yarn.1092.lock $ diff yarn.1095.lock yarn.1092.lock | grep resolved | sed -e 's/#.*//' | sed -e 's/https:\/\/repository.folio.org\/repository\/npm-ci-all/.../' < resolved "https://repository.folio.org/repository/npm-folioci/@folio/eslint-config-stripes/-/eslint-config-stripes-5.2.100058.tgz > resolved "https://repository.folio.org/repository/npm-folioci/@folio/eslint-config-stripes/-/eslint-config-stripes-5.2.100057.tgz < resolved "https://repository.folio.org/repository/npm-folioci/@folio/stripes-connect/-/stripes-connect-5.6.1000120.tgz > resolved "https://repository.folio.org/repository/npm-folioci/@folio/stripes-connect/-/stripes-connect-5.6.1000119.tgz < resolved ".../@types/node/-/node-14.0.4.tgz > resolved ".../@types/node/-/node-14.0.1.tgz < resolved ".../@types/node/-/node-8.10.61.tgz > resolved ".../@types/node/-/node-8.10.60.tgz < resolved ".../@types/uglify-js/-/uglify-js-3.9.2.tgz > resolved ".../@types/uglify-js/-/uglify-js-3.9.1.tgz < resolved ".../electron-to-chromium/-/electron-to-chromium-1.3.446.tgz > resolved ".../electron-to-chromium/-/electron-to-chromium-1.3.443.tgz < resolved ".../miragejs/-/miragejs-0.1.39.tgz > resolved ".../miragejs/-/miragejs-0.1.38.tgz < resolved ".../node-releases/-/node-releases-1.1.56.tgz > resolved ".../node-releases/-/node-releases-1.1.55.tgz < resolved ".../pretender/-/pretender-3.4.3.tgz > resolved ".../pretender/-/pretender-3.4.1.tgz Updates to node and uglify-js stand out. Can we try building ui-users with these two different lockfiles on the old version the CI docker image/VM/whatever it is? Is that something for me to try, John Malconian, or you, or ...? |
| Comment by Zak Burke [ 22/Feb/22 ] |
|
We've moved on from BTOG to RTL and haven't seen this error in ages. |