Skip to content
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

Closed
EugeneEl opened this issue Oct 23, 2019 · 17 comments
Closed

[BUG] Error: spawn ETXTBSY #69

EugeneEl opened this issue Oct 23, 2019 · 17 comments
Assignees
Labels
question Further information is requested

Comments

@EugeneEl
Copy link

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.0
  • OS:
  • Node.js Version: 8 and 10

I 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:

 const generatePDF = async data => {
   try {
     const browser = await chromium.puppeteer.launch({ 
      args: chromium.args,
      defaultViewport: chromium.defaultViewport,
       executablePath: await chromium.executablePath,
      headless: chromium.headless
     });
     const page = await browser.newPage();
 
     await page.goto(`file://${BASE_FILE}`, {
       waitUntil: 'networkidle0'
     });
 
     console.log(data);
 
     page.on('console', msg => console.log('PAGE LOG:', msg.text()));
 
     await page.evaluate(async params => await startVue(params), data);
 
     const pdf = await page.pdf({ format: 'A4' });
 
     browser.close();
     return pdf;
   } catch (error) {
     console.error(`Error while generating pdf:${error}`);
     throw error;
   }
 };

@EugeneEl EugeneEl added the bug Something isn't working label Oct 23, 2019
@alixaxel
Copy link
Owner

@EugeneEl It looks like the snippet you shared is incomplete, so hard to tell what's going on.

A couple of points:

  • file:// the file protocol needs 3 forward slashes (like file:///...)
  • what's BASE_FILE? does it exist on disk?
  • what's startVue()? and why is it complaning that params.Body is required?

Please share the whole repro so that I can help you better.

@alixaxel alixaxel added question Further information is requested and removed bug Something isn't working labels Oct 23, 2019
@karimc1
Copy link

karimc1 commented Feb 11, 2020

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.
When I delete the layer from AWS console and reattach it again, it works.
At the end of the lifecycle of the lambda (more than 10 minutes after), when calling the lambda again I fall back on the same error.
Do you have an idea?

Below the stack error as well as my generation function

{
	"errorType": "Error",
	"errorMessage": "spawn ETXTBSY",
	"trace": [
		"Error: spawn ETXTBSY",
		"    at ChildProcess.spawn (internal/child_process.js:366:11)",
		"    at Object.spawn (child_process.js:551:9)",
		"    at Launcher.launch (/var/task/node_modules/puppeteer-core/lib/Launcher.js:132:40)"
	]
}
​
const convertToPdf = async function (html) {
	let browser = null;
	let pdf = null;
	try {
		const executablePath = await chromium.executablePath;
		browser = await chromium.puppeteer.launch({
				args: chromium.args,
				defaultViewport: chromium.defaultViewport,
				executablePath: executablePath,
				headless: chromium.headless
			});
		const page = await browser.newPage();
		await page.setContent(html);
​
		pdf = await page.pdf({
				format: 'A4'
			});
​
	} catch (error) {
		throw error;
	}
	finally {
		if (browser !== null) {
			await browser.close();
		}
		if (pdf) {
			return pdf;
		}
	}
​
};

@alixaxel
Copy link
Owner

@karimc1 It's really hard to help without a complete repro. My guess is that you're calling convertToPdf multiple times from the same Lambda instance? Also, you only have a single chrome-aws-lambda layer attached right?

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.

I'd be happy to help you further if you need, just open a new issue and share a full repro.

@karimc1
Copy link

karimc1 commented Feb 11, 2020

Thanks for your quick answer I will open another ticket for that.

Bests,

@bwoodlt
Copy link

bwoodlt commented Aug 4, 2020

@karimc1 how did you fix it?

@krvajal
Copy link

krvajal commented Sep 1, 2020

I am having the same issue

@Eastkap
Copy link

Eastkap commented Dec 8, 2021

having the issue too

@kryptonian41
Copy link

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.

@kryptonian41
Copy link

@alixaxel can you reopen the issue ?

@mikejackowski
Copy link

Sam issue happening to me, everything on the latest versions

@umairyounus
Copy link

Getting same issue

@SethCaryak
Copy link

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"}"
subsequent calls result in "{"errno":-26,"code":"ETXTBSY","syscall":"spawn"}"
the chromium.executablepath is actually /tmp/chromium which I'm guessing is a symlink to /var/task/src/functions/bin/chromium.br which isn't actually there for some reason, the layer is setup correctly afaik. Been working on this for two days straight, need help, about to shoot myself

@jacksonneal
Copy link

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

@gventuri
Copy link

gventuri commented Aug 6, 2022

Same happening for me, with node 16 and 12. Any idea?

@Carson12345
Copy link

@gventuri it could happen when you launch more than 1 puppeteer instance synchronously in your code.

is it your case?

@Moicky
Copy link

Moicky commented Oct 24, 2023

@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 😄

mbland added a commit to mbland/vitest that referenced this issue Dec 7, 2023
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.
mbland added a commit to mbland/vitest that referenced this issue Dec 8, 2023
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.
mbland added a commit to mbland/vitest that referenced this issue Dec 8, 2023
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.
mbland added a commit to mbland/vitest that referenced this issue Jan 3, 2024
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.
mbland added a commit to mbland/vitest that referenced this issue Jan 4, 2024
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.
@AlteriusOmega
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests