-
-
Notifications
You must be signed in to change notification settings - Fork 293
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
[BUG] Error: spawn ETXTBSY #69
Comments
@EugeneEl It looks like the snippet you shared is incomplete, so hard to tell what's going on. A couple of points:
Please share the whole repro so that I can help you better. |
Hi Alixaxel, I had the same error this is why I am leaving my comment on this closed issue: When I deploy my lambda, I constantly get "spawn ETXTBSY" error. Below the stack error as well as my generation function
|
@karimc1 It's really hard to help without a complete repro. My guess is that you're calling The I'd be happy to help you further if you need, just open a new issue and share a full repro. |
Thanks for your quick answer I will open another ticket for that. Bests, |
@karimc1 how did you fix it? |
I am having the same issue |
having the issue too |
I am facing the same issue when launching chrome-aws-lambda browser inside WSL2 in headless mode. It used to work fine for quite a while now I don't whether I made a change in my environment which caused this. |
@alixaxel can you reopen the issue ? |
Sam issue happening to me, everything on the latest versions |
Getting same issue |
I am having the same issue. First I get an error that it can't find chromium. {"errno":-2,"code":"ENOENT","syscall":"open","path":"/var/task/src/functions/bin/chromium.br"}" |
I am running into this error when bundling with esbuild (only when in lambda, local invoke works fine). However, I can successfully execute when using webpack as in this repo https://github.com/metacollective9/playwright-amz-scrape |
Same happening for me, with node 16 and 12. Any idea? |
@gventuri it could happen when you launch more than 1 puppeteer instance synchronously in your code. is it your case? |
Well, this was the issue in my case 🤦 This comment made me read my code again and therefore I found the issue. Thanks a lot 😄 |
Adding the fix-4686.test.mjs introduced a second `vitest` process into the test/browser/specs suite. This attempts to resolve subsequent flakiness in the test-browser CI job by ensuring one test file completely finishes before the next. - https://nodejs.org/docs/latest-v20.x/api/cli.html#--test-concurrency --- This particular build showed ETXTBSY errors thrown when launching the chrome via WebdriverIO: - https://github.com/vitest-dev/vitest/actions/runs/7128065730/job/19409296285?pr=4692#step:10:1 ```text ⎯⎯⎯⎯⎯⎯ Unhandled Error ⎯⎯⎯⎯⎯⎯⎯ Error: spawn ETXTBSY ❯ ChildProcess.spawn node:internal/child_process:421:11 ❯ Object.spawn node:child_process:761:9 ❯ startWebDriver ../../node_modules/.pnpm/@wdio+utils@8.22.0/node_modules/@wdio/utils/build/node/startWebDriver.js:57:28 ❯ process.processTicksAndRejections node:internal/process/task_queues:95:5 ❯ WebDriver.newSession ../../node_modules/.pnpm/webdriver@8.22.1/node_modules/webdriver/build/index.js:18:31 ❯ remote ../../node_modules/.pnpm/webdriverio@8.22.1_typescript@5.2.2/node_modules/webdriverio/build/index.js:45:22 ❯ WebdriverBrowserProvider.openBrowser ../../packages/browser/dist/providers.js:81:26 [...snip...] ``` ETXTBSY is a relatively obscure error that isn't seen much anymore: - lwn.net: The shrinking role of ETXTBSY https://lwn.net/Articles/866493/ The results I found while searching all seemed to point to Chromium being a potential source of this issue, such as this excerpt from (emphasis mine): - alixaxel/chrome-aws-lambda#69 (comment) ```text The `ETXTBSY` error code is thrown when puppeteer is trying to **start the Chromium binary but the binary file is under a exclusive lock** - that can happen if you don't wait for `executablePath` to resolve, or, **if you call `executablePath` multiple times.** ``` This also showed up with older versions of Node and Docker, but each of the versions in the current build are up to date.
Adding the fix-4686.test.mjs introduced a second `vitest` process into the test/browser/specs suite. This attempts to resolve subsequent flakiness in the test-browser CI job by ensuring one test file completely finishes before the next. - https://nodejs.org/docs/latest-v20.x/api/cli.html#--test-concurrency --- This particular build showed ETXTBSY errors thrown when launching the chrome via WebdriverIO: - https://github.com/vitest-dev/vitest/actions/runs/7128065730/job/19409296285?pr=4692#step:10:1 ```text ⎯⎯⎯⎯⎯⎯ Unhandled Error ⎯⎯⎯⎯⎯⎯⎯ Error: spawn ETXTBSY ❯ ChildProcess.spawn node:internal/child_process:421:11 ❯ Object.spawn node:child_process:761:9 ❯ startWebDriver ../../node_modules/.pnpm/@wdio+utils@8.22.0/node_modules/@wdio/utils/build/node/startWebDriver.js:57:28 ❯ process.processTicksAndRejections node:internal/process/task_queues:95:5 ❯ WebDriver.newSession ../../node_modules/.pnpm/webdriver@8.22.1/node_modules/webdriver/build/index.js:18:31 ❯ remote ../../node_modules/.pnpm/webdriverio@8.22.1_typescript@5.2.2/node_modules/webdriverio/build/index.js:45:22 ❯ WebdriverBrowserProvider.openBrowser ../../packages/browser/dist/providers.js:81:26 [...snip...] ``` ETXTBSY is a relatively obscure error that isn't seen much anymore: - lwn.net: The shrinking role of ETXTBSY https://lwn.net/Articles/866493/ The results I found while searching all seemed to point to Chromium being a potential source of this issue, such as this excerpt from (emphasis mine): - alixaxel/chrome-aws-lambda#69 (comment) ```text The `ETXTBSY` error code is thrown when puppeteer is trying to **start the Chromium binary but the binary file is under a exclusive lock** - that can happen if you don't wait for `executablePath` to resolve, or, **if you call `executablePath` multiple times.** ``` This also showed up with older versions of Node and Docker, but each of the versions in the current build are up to date.
Adding the fix-4686.test.mjs introduced a second `vitest` process into the test/browser/specs suite. This attempts to resolve subsequent flakiness in the test-browser CI job by ensuring one test file completely finishes before the next. - https://nodejs.org/docs/latest-v20.x/api/cli.html#--test-concurrency --- This particular build showed ETXTBSY errors thrown when launching the chrome via WebdriverIO: - https://github.com/vitest-dev/vitest/actions/runs/7128065730/job/19409296285?pr=4692#step:10:1 ```text ⎯⎯⎯⎯⎯⎯ Unhandled Error ⎯⎯⎯⎯⎯⎯⎯ Error: spawn ETXTBSY ❯ ChildProcess.spawn node:internal/child_process:421:11 ❯ Object.spawn node:child_process:761:9 ❯ startWebDriver ../../node_modules/.pnpm/@wdio+utils@8.22.0/node_modules/@wdio/utils/build/node/startWebDriver.js:57:28 ❯ process.processTicksAndRejections node:internal/process/task_queues:95:5 ❯ WebDriver.newSession ../../node_modules/.pnpm/webdriver@8.22.1/node_modules/webdriver/build/index.js:18:31 ❯ remote ../../node_modules/.pnpm/webdriverio@8.22.1_typescript@5.2.2/node_modules/webdriverio/build/index.js:45:22 ❯ WebdriverBrowserProvider.openBrowser ../../packages/browser/dist/providers.js:81:26 [...snip...] ``` ETXTBSY is a relatively obscure error that isn't seen much anymore: - lwn.net: The shrinking role of ETXTBSY https://lwn.net/Articles/866493/ The results I found while searching all seemed to point to Chromium being a potential source of this issue, such as this excerpt from (emphasis mine): - alixaxel/chrome-aws-lambda#69 (comment) ```text The `ETXTBSY` error code is thrown when puppeteer is trying to **start the Chromium binary but the binary file is under a exclusive lock** - that can happen if you don't wait for `executablePath` to resolve, or, **if you call `executablePath` multiple times.** ``` This also showed up with older versions of Node and Docker, but each of the versions in the current build are up to date.
Adding the fix-4686.test.mjs introduced a second `vitest` process into the test/browser/specs suite. This attempts to resolve subsequent flakiness in the test-browser CI job by ensuring one test file completely finishes before the next. - https://nodejs.org/docs/latest-v20.x/api/cli.html#--test-concurrency --- This particular build showed ETXTBSY errors thrown when launching the chrome via WebdriverIO: - https://github.com/vitest-dev/vitest/actions/runs/7128065730/job/19409296285?pr=4692#step:10:1 ```text ⎯⎯⎯⎯⎯⎯ Unhandled Error ⎯⎯⎯⎯⎯⎯⎯ Error: spawn ETXTBSY ❯ ChildProcess.spawn node:internal/child_process:421:11 ❯ Object.spawn node:child_process:761:9 ❯ startWebDriver ../../node_modules/.pnpm/@wdio+utils@8.22.0/node_modules/@wdio/utils/build/node/startWebDriver.js:57:28 ❯ process.processTicksAndRejections node:internal/process/task_queues:95:5 ❯ WebDriver.newSession ../../node_modules/.pnpm/webdriver@8.22.1/node_modules/webdriver/build/index.js:18:31 ❯ remote ../../node_modules/.pnpm/webdriverio@8.22.1_typescript@5.2.2/node_modules/webdriverio/build/index.js:45:22 ❯ WebdriverBrowserProvider.openBrowser ../../packages/browser/dist/providers.js:81:26 [...snip...] ``` ETXTBSY is a relatively obscure error that isn't seen much anymore: - lwn.net: The shrinking role of ETXTBSY https://lwn.net/Articles/866493/ The results I found while searching all seemed to point to Chromium being a potential source of this issue, such as this excerpt from (emphasis mine): - alixaxel/chrome-aws-lambda#69 (comment) ```text The `ETXTBSY` error code is thrown when puppeteer is trying to **start the Chromium binary but the binary file is under a exclusive lock** - that can happen if you don't wait for `executablePath` to resolve, or, **if you call `executablePath` multiple times.** ``` This also showed up with older versions of Node and Docker, but each of the versions in the current build are up to date.
Adding the fix-4686.test.mjs introduced a second `vitest` process into the test/browser/specs suite. This attempts to resolve subsequent flakiness in the test-browser CI job by ensuring one test file completely finishes before the next. - https://nodejs.org/docs/latest-v20.x/api/cli.html#--test-concurrency --- This particular build showed ETXTBSY errors thrown when launching the chrome via WebdriverIO: - https://github.com/vitest-dev/vitest/actions/runs/7128065730/job/19409296285?pr=4692#step:10:1 ```text ⎯⎯⎯⎯⎯⎯ Unhandled Error ⎯⎯⎯⎯⎯⎯⎯ Error: spawn ETXTBSY ❯ ChildProcess.spawn node:internal/child_process:421:11 ❯ Object.spawn node:child_process:761:9 ❯ startWebDriver ../../node_modules/.pnpm/@wdio+utils@8.22.0/node_modules/@wdio/utils/build/node/startWebDriver.js:57:28 ❯ process.processTicksAndRejections node:internal/process/task_queues:95:5 ❯ WebDriver.newSession ../../node_modules/.pnpm/webdriver@8.22.1/node_modules/webdriver/build/index.js:18:31 ❯ remote ../../node_modules/.pnpm/webdriverio@8.22.1_typescript@5.2.2/node_modules/webdriverio/build/index.js:45:22 ❯ WebdriverBrowserProvider.openBrowser ../../packages/browser/dist/providers.js:81:26 [...snip...] ``` ETXTBSY is a relatively obscure error that isn't seen much anymore: - lwn.net: The shrinking role of ETXTBSY https://lwn.net/Articles/866493/ The results I found while searching all seemed to point to Chromium being a potential source of this issue, such as this excerpt from (emphasis mine): - alixaxel/chrome-aws-lambda#69 (comment) ```text The `ETXTBSY` error code is thrown when puppeteer is trying to **start the Chromium binary but the binary file is under a exclusive lock** - that can happen if you don't wait for `executablePath` to resolve, or, **if you call `executablePath` multiple times.** ``` This also showed up with older versions of Node and Docker, but each of the versions in the current build are up to date.
Just in case anyone else made the same mistake as me, I forgot to comment out the running of the handler function at the end of my Lambda function that I use to run locally for testing during development. This caused two instances of the function to run causing this error. |
hi, I got very strange error, unfortunately I didn't find anything related to my issue.
If possible please have a look at this.
Environment
chrome-aws-lambda
Version: ^1.20.2,puppeteer
/puppeteer-core
Version: ^1.20.0I tried to run it on different AWS node versions.
Logs:
2019-10-15T21:42:28.073Z 1930cd72-b389-41b5-b5bd-d4534dd0bc25 ERROR Error while generating pdf:Error: spawn ETXTBSY
2019-10-15T21:42:28.076Z 1930cd72-b389-41b5-b5bd-d4534dd0bc25 ERROR Error: params.Body is required
at ManagedUpload.validateBody (/var/task/node_modules/aws-sdk/lib/s3/managed_upload.js:271:13)
at ManagedUpload.configure (/var/task/node_modules/aws-sdk/lib/s3/managed_upload.js:123:10)
at new ManagedUpload (/var/task/node_modules/aws-sdk/lib/s3/managed_upload.js:95:10)
at features.constructor.upload (/var/task/node_modules/aws-sdk/lib/services/s3.js:1133:20)
at /var/task/services/awsUploader.js:18:8
at new Promise ()
at Object.uploadFile (/var/task/services/awsUploader.js:17:10)
at module.exports (/var/task/export.js:38:40)
2019-10-15T21:42:28.076Z 1930cd72-b389-41b5-b5bd-d4534dd0bc25 INFO finally:
2019-10-15T21:42:28.094Z 1930cd72-b389-41b5-b5bd-d4534dd0bc25 ERROR Invoke Error
{
"errorType": "Error",
"errorMessage": "params.Body is required",
"stack": [
"Error: params.Body is required",
" at ManagedUpload.validateBody (/var/task/node_modules/aws-sdk/lib/s3/managed_upload.js:271:13)",
" at ManagedUpload.configure (/var/task/node_modules/aws-sdk/lib/s3/managed_upload.js:123:10)",
" at new ManagedUpload (/var/task/node_modules/aws-sdk/lib/s3/managed_upload.js:95:10)",
" at features.constructor.upload (/var/task/node_modules/aws-sdk/lib/services/s3.js:1133:20)",
" at /var/task/services/awsUploader.js:18:8",
" at new Promise ()",
" at Object.uploadFile (/var/task/services/awsUploader.js:17:10)",
" at module.exports (/var/task/export.js:38:40)"
]
}
my code:
The text was updated successfully, but these errors were encountered: