-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
[native-image] naitive doesn't run in AWS Lambda custrom runtime beacuse of "Util_sun_misc_Signal.ensureInitialized: CSunMiscSignal.open() failed." #841
Comments
I can not reproduce your issue. However, I only tried with our First I built a
In that docker container I tried your test program:
and built an image for that:
(Just to make sure it was not one of your additional options that was causing the issue, I built another image with all your options and ran it:)
Since the issue seems to be around signal handling I built an image for one of our internal tests (not shown) that raises
and built an image for that
and that all seemed to work. I suspect the problem is that the docker container you are running in does not have the semaphore functions from During image start-up we register a signal handler for I admit that the error message is less than enlightening. I will go make it clearer. At least I should report which function says it is not implemented. |
Thanks for response. I tried |
Building an image with When you say "it doesn't work in lambda", are you trying to run the native image for your application in the Docker image for {{GraalVM/CE/1.0.0-rc9}}, or are you trying to take that native image and run it on some different platform (on AWS)? A complete log that would let me reproduce the problem would be useful. |
I try building a native image in GraalVM/CE/1.0.0-rc9 image. And try running it on AWS Lambda Custrom Runtime. AWS Lambda Custom Runtime is here.
And I pushed reproduce sample at https://github.com/kencharos/graal-native-on-lambda I attached log file and deployed zip file that contains image and bootstrap shell. |
In general, you can not build a native image on one platform and execute it on different platform. For example, building a native image on the In your case, your execution platform seems not to have the semaphore functions from the When I look at the libraries required to run the
and if I look in
What do you see as the libraries needed by your image, and do you see the definitions of the semaphore functions in those libraries on your execution platform? I am asking to see if that is the cause of the "Function not implemented" message. What happens if you build the image on Amazon Linux and execute it there? E.g., using one of our prebuilt binaries for Linux? |
I tried to build native image in EC2 using same AMI. native image works EC2. but I got same error when it rut in Lambda. mn and ldd output is bellow:
Then, I run
So that, |
Looks like the kernel on AWS Lambda does not provide the necessary syscall(s). errno = 38 means |
If AWS Lambda does not have the syscall for |
Also hit this issue, any hope for a resolution? GraalVM + AWS Lambda Custom Runtimes could be very promising if we can get the Kernel differences resolved |
Works for me (I was using rc10); fwiw, I'm doing my builds on Manjaro (4.19 kernel). See also https://qiita.com/kencharos/items/69e43965515f368bc4a3 |
@plutext thanks for the tip, got it working |
If the workaround is sufficient, can this issue be closed? |
@Peter-B-Kessler I build on Manjaro (4.19 kernel) but there is nothing particularly special about that, I don't think (unless I was lucky!). kencharos builds in a docker image: https://github.com/kencharos/try-graal-lambda/blob/master/AmazonGraal/Dockerfile No need to run with that kernel at run time (nor do i think you could). Just zip up the native image and whatever else you need, and upload to lambda.
You can code/include the bootstrap functionality in your native image, in which case you name your native image bootstrap. This seems the best way performance-wise. Or you can use the example bootstrap at https://docs.aws.amazon.com/lambda/latest/dg/runtimes-walkthrough.html to invoke the native image. That's an easy way to get started. |
I would say "not"; the workaround appears essentially to disable all signal handlers so that the code in question is never called. I would say that it might be a better idea to come up with some different signal-handling solution than using POSIX named semaphores. If a semaphore must be used - in preference to, say, a POSIX thread mutex or something simpler - then why not use |
We use POSIX named semaphores because they are available on Darwin and Linux. Unnamed semaphores are not available on Darwin. Having platform-specific code is a maintenance burden, especially for platforms we do not have in our testing infrastructure. |
Why does it need to be a semaphore at all? What about using a The problem (in case it wasn't clear) is that |
In the very, very worst case, maybe a pipe... |
native images can run on AWS lambda: https://github.com/pmlopes/aws-lambda-native-vertx In the example above we successfully built images on:
And the produced binaries do run on AWS Lambda. |
Are you using signal handlers? |
@Peter-B-Kessler is there a reason for relying on GCC-specific builtins in this code e.g. |
It looks like the design of signal handling doesn't employ a single-threaded |
Hmm I don't understand how/why I just unassigned @Peter-B-Kessler just by replying to a comment. GitHub confounds again. |
* We have two lambdas, one for each context * Each lambda can CreateReadDelete * The last parts of the frontend stack are removed (cleanup) * TODO: ** Add tests ** Generalize the handler code (too many duplications) ** Add persistence ** Find out why native deployment fails on AWS Lambdas (same errors as stated here: oracle/graal#841) ** Add routing to via proper URL (happy-stars.play.ideas.de ??) ** Think about better deployment strategie (atm, we need to execute mvn two times for the two handler-jars to get created, the second time without "clean" goal to not delete the first jar-file) ** Think about multi-user support (two frontend devs doing the challenge parallel)
@dmlloyd Should this issue have been fixed? As of which GraalVM version? @dainiusjocas still ran into it because babashka uses a |
No, the issue is not fixed. It turns out the anonymous |
One idea might be to use |
I tried running naitive image in AWS Lambda custrom runtime.
But it did not run. Error Summary is bellow.
Sample code is bellow:
Then, build native image command is bellow:
I run native-image in Docker oracle/graalvm-ce:1.0.0-rc9 .
And this image run in local.
lambda's full log is bellow:
The text was updated successfully, but these errors were encountered: