-
-
Notifications
You must be signed in to change notification settings - Fork 8.5k
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
Build fails on MacOS for large site because max proc limit is exceeded #10348
Comments
I think a hardcoded limit is ok, and at best we can have an env variable to customize. |
Left my initial review here: #10354 (review) To be honest, although the proposed solution might fix the problem, and we might still want to limit git concurrency, I believe it only hides the real bug here: shelljs (unmaintained deps) probably doesn't handle file descriptors well under concurrent access? I'd like to explore switching to alternatives first, before introducing IO queueing: |
I agree to that, let's get rid of shelljs completely for execa? However I don't know why file descriptors are related. The problem here is hitting the process limit, not the FD limit, no? |
I'm not 100% sure but it seems "EBADF" means "Error, bad file descriptor" in Node.js I propose that we first remove shelljs and see if the problem disappears by testing upgrading the zowe site to a canary? |
If shelljs is unmaintained then I'm all for getting rid of it. Although the error code does seem related to file descriptors, I don't think the max file descriptor limit is being hit because I tried increasing it with Regardless of what dependency is being used to spawn processes, IMO it's not good practice to launch hundreds or potentially thousands of processes at once, without a promise queue in place to limit the number of concurrent processes. |
Thanks, was about to ask.
Agree, but this is a general problem we have, not just limited to Git commands but to all IOs in general. I tried building your branch locally zowe/docs-site#3785 I got many warnings (broken links, admonitions) but was able to build without such EBADF error (I'm on MacOS M3 Sonoma) Only you will be able to confirm it moving to Execa fixes it. You can try to apply this change locally: |
We archived some old doc versions to reduce the number of files in the repo and work around the issue. I'll test the changes next week on a branch that still has the old files. Thanks for the reminder about broken links, there is WIP to fix them 🙂 |
Have you read the Contributing Guidelines on issues?
Prerequisites
npm run clear
oryarn clear
command.rm -rf node_modules yarn.lock package-lock.json
and re-installing packages.Description
After updating from Docusaurus v3.1 to v3.4, building a large site fails with the following error on MacOS:
Reproducible demo
No response
Steps to reproduce
docusaurus build
Expected behavior
The build succeeds
Actual behavior
There is an
EBADF
error like the one above. This works on other OS's like Ubuntu, so it seems to be related to the max number of processes supported by MacOS.I was able to work around the issue by replacing the following line to limit the number of concurrent
git
processes to 100:docusaurus/packages/docusaurus-plugin-content-docs/src/index.ts
Line 194 in 95990c6
I'm willing to open a PR if the fix is simple, but not sure what the preferred solution would be - is a hardcoded limit like 100 ok, or should it be configurable in the Docusaurus config?
Your environment
Self-service
The text was updated successfully, but these errors were encountered: