Error with xvfb_executable Path

[ikeorizu]

When I test on Lambda, this is the error I get, How do I fix this ?

{ "errorMessage": "Command failed: curl --silent --show-error -L -o /tmp/pck.zip http://static.apptentic.com/tools/electron/nightmare-lambda-pck-with-xvfb-20170313-1726-43.zip\ncurl: (7) Failed to connect to static.apptentic.com port 80: Connection timed out\n", "errorType": "Error", "stackTrace": [ "", "checkExecSyncError (child_process.js:481:13)", "Object.execFileSync (child_process.js:501:13)", "Object.pack._downloadFileSync (/var/task/src/lib/bootstrap/nightmare-lambda-pack.js:40:19)", "Object.pack.installNightmare (/var/task/src/lib/bootstrap/nightmare-lambda-pack.js:104:20)", "Object.pack.installNightmareOnLambdaEnvironment (/var/task/src/lib/bootstrap/nightmare-lambda-pack.js:121:17)", "Object.<anonymous> (/var/task/index.js:22:31)", "Module._compile (module.js:570:32)", "Object.Module._extensions..js (module.js:579:10)", "Module.load (module.js:487:32)", "tryModuleLoad (module.js:446:12)" ] }

[dimkir]

Does this error still occur? It could have been a random S3 error or network error or maybe your lambda runs in VPC and there's some firewall restrictions in place. Or maybe you're running from some "recent" AWS region where things are not configured same as in "old" regions like us-west-1 ...

[jwswj]

I went through the tutorial on the weekend and didn't get this issue.

[Raidus]

Works in my case as well

[dimkir]

this seems to have been some network connectivity/configuration problem. Closing.

[dimkir]

Hey @themattrobinson,

the original question refers to old location of the electron binary (pre December-2017), so as of now referring to the old location (apptentic.com/lalala/...zip) will permanently fail.

In your comment you mention that your error is intermittent (comes and goes). So I assume that you're using a newer version where electron is hosted on Github releases. My first thought would be that it relates to your connectivity issues or maybe some throttling from Github side.

Keep in mind that Github serves releases from us-east-1, which means that if your lambda is not in the same region, you will have to do cross-region transfer of file. This will be both slower (2-5 times), more prone to transmission errors, and who knows if it may be subject to throttling.

If your own lambdas are NOT in us-east-1 I would strongly encourage to host electron binary in your own bucket in the same region as your lambdas. There's a quick guide for that: https://github.com/dimkir/nightmare-lambda-tutorial#self-hosting-electron

If the problem still persists, probably it would be better if you open a new issue and would be great if you can provide logs or at least exact error message).

[themattrobinson]

Hey @dimkir,

I am hosting the Electron package in my own S3, thanks for the tip.

I believe I determined the issue though. It appears that every time I invoke my Lambda function, it adds a new 18MB “core.exe.[N]” file to the /tmp directory.

Here’s the condensed log output from three consecutive runs (I run "du -d 1 -h /tmp” and then “ls -ltr /tmp”); the only additions each time are highlighted an commented inline:

18:32:00 152M   /tmp/pck
18:32:00 4.0K   /tmp/.X11-unix
18:32:00 4.0K   /tmp/shm
18:32:00 8.0K   /tmp/.config
18:32:00 36K    /tmp/.pki
18:32:00 170M   /tmp
18:32:00 total 18604
18:32:00 drwxrwxr-x 5 sbx_user1070 476 4096 Mar 13 2017 pck
18:32:00 -rw------- 1 sbx_user1070 476 18108416 Aug 30 18:23 core.exe.47   _**(<====== added during first execution)**_
18:32:00 -rw------- 1 sbx_user1070 476 18108416 Aug 30 18:25 core.exe.122 **_(<====== added during second execution)_**
-rw------- 1 sbx_user1070 476 18108416 Aug 30 18:31 core.exe.220 **_(<====== added during third execution)_**
18:32:00drwxrwxr-x 2 sbx_user1070 476 4096 Aug 30 18:31 shm

Those core files would eventually take all of the 512MB available ephemeral space, and would eventually crash the Lambda function, and then the subsequent re-trying of the Electron package download would ultimate error out.

I am now removing all /tmp/core.exe.* files at the end of each function run, so the available tmp space never runs out... this seems to be doing the trick, though I will continue to test over time to confirm.

I haven't examined the core files yet in gdb, but removing them at the end seems to be the way to go.

[dimkir]

Thank you for the details.

From the logs it looks like Electron SEGFAULTs during execution (may be various reasons behind it, including sophisticated nightmare js script or simply bad weather).

When I was testing and had problems with Electron, they weren't crashdumps, but rather "hangs".

In that scenario Lambda would have simply timed out, then mark container as "dirty" and container will be killed and all /tmp would be cleaned up.

However your case is different: it seems that Electron crashdumps, and the nightmare-on-lambda code doesn't notice it (or notices, but doesn't do anything). So the same container keeps being reused and eventually you fill up /tmp.

Your solution of cleaning up all crashdumps upon execution seems to be the right approach. I will add similar code to nightmare-on-lambda.

ps. Apart from filling out /tmp space - did you identify which cases cause Electron to crash dump?