AWS Lambda allows you to [run custom binaries](https://aws.amazon.com/blogs/compute/running-executables-in-aws-lambda/) as child processes.

However, if the packaged binary you're running on AWS Lambda uses shared libraries, they may not be available in the Lambda environment. If this is the case, your binary will terminate without any output. In my case, the exit status code was `127`, which wasn't very helpful (typically this is "command not found.")

    2015-11-18T00:50:10.731Z	521db901-8d8e-11e5-b9df-cd31cc90ece2	Calling phantom:  /var/task/phantomjs [ '/var/task/phantomjs-script.js' ]
    2015-11-18T00:50:10.809Z	521db901-8d8e-11e5-b9df-cd31cc90ece2	child process exited with code 127

Linux's loader, ld.so, allows you ([see manpage](http://man7.org/linux/man-pages/man8/ld.so.8.html)) to set an environment variable called `LD_DEBUG` that will output verbose information while the shared libraries are loaded.

Since Lambda doesn't let you set arbitrary environment variables, you need to set the environment at runtime prior to starting your child process. In Node.js, this looks like:

      process.env['LD_DEBUG'] = 'all';

      // However your progam executes your binary, e.g.
      // var phantom = childProcess.execFile('./phantomjs', args);

Re-run your Lambda function and you should get verbose information (including errors!) from the loader:

     7:	
     7:	file=libicudata.so.50 [0];  needed by /var/task/phantomjs [0]
     7:	find library=libicudata.so.50 [0]; searching
     7:	 search cache=/etc/ld.so.cache
     7:	 search path=/lib64/tls/x86_64:/lib64/tls:/lib64/x86_64:/lib64:/usr/lib64/tls/x86_64:/usr/lib64/tls:/usr/lib64/x86_64:/usr/lib64		(system search path)
     7:	  trying file=/lib64/tls/x86_64/libicudata.so.50
     7:	  trying file=/lib64/tls/libicudata.so.50
     7:	  trying file=/lib64/x86_64/libicudata.so.50
     7:	  trying file=/lib64/libicudata.so.50
     7:	  trying file=/usr/lib64/tls/x86_64/libicudata.so.50
     7:	  trying file=/usr/lib64/tls/libicudata.so.50
     7:	  trying file=/usr/lib64/x86_64/libicudata.so.50
     7:	  trying file=/usr/lib64/libicudata.so.50
     7:	
    /var/task/phantomjs: error while loading shared libraries: libicudata.so.50: cannot open shared object file: No such file or directory

In this case, the version of libicudata PhantomJS was compiled against is not available in the Lambda environment ([more info here.](https://github.com/ariya/phantomjs/issues/12948)). As Amazon indicates in their documentation, it's important to use binaries built on the actual Amazon Linux AMIs.

Also, since Amazon regularly updates Lambda's environment to track changes in Amazon Linux, it's best to compile custom binaries statically when possible.