-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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: sam local start-api fails to initialise lambda function containers within podman/toolbox container #7298
Comments
Hi @AidanOB, thanks for reporting the issue and providing details. I will try to reproduce the issue. |
Can you check if |
Unfortunately the containers don't initialise either. Regular output is just no response on the terminal. With the -debug flag set:
|
Further behaviour I have discovered, but intermittently (so unable to reliably reproduce) is that the lambdas will initialise if I do other things with toolbox/podman. Sometimes making or entering a new toolbox will trigger the initialisation of the lambdas. Or making another container. But this has only happened once or twice and not exactly sure what I did at the time that caused the lambdas in the other container to suddenly initialise. |
I'm experiencing something similar. Environment details: |
Thanks @gergo-dryrun - running |
Attempt to fix this in #7760 |
Thank you! The changes there fixed the issue for me. Looking forward to seeing that released! |
@gergo-dryrun You sir deserve more likes! Thank you!!! Now only if we know why your solution works would be even better 😄 🚀 |
@gminova It's because the event SAM cli is reading from blocks until there's an event of type image triggered, which happens when you run a pod or pull an image. |
@chiting Thank you. Yes, I saw the reason described in your PR, hopefully you can get your fix merged, however I wonder why sam is working seamlessly with docker and does not have the same problem whereas with podman this issue happens. Perhaps there could be some fix podman could do instead of sam? |
@gminova I agree with you, there seem to be some differences around events and it would be good for podman to close the gap with how docker behaves. Regardless of the above, I still believe SAM cli shouldn't use blocking calls in the main thread (unless it's by design, which I could be missing). The fact it works with docker seems to be server side implementation specific and I think the tool shouldn't rely on it to work. |
@chiting Hey, I was able to fix my issue locally by removing my machine and init it again and ensuring the podman info is using version 5.3 where they have a fix, please see issue and discussion here: containers/podman#24839 (comment) I think this issue can be closed @AidanOB |
Description:
When attempting to run
sam local start-api
from within podman/toolbox on Fedora 40 Kinoite, the lambda function containers fail to initialise. Command hangs for over an hour (at least) without initialising containers. On one occassion, when left overnight it initialised the container and was ready to be called.To test, utilised AWS Lambda powertools tutorial template found here: https://docs.powertools.aws.dev/lambda/python/latest/tutorial/#code-example
Output
Initializing the lambda functions containers.
Steps to reproduce:
Fedora 40 Kinoite -> Toolbox
Observed result:
Expected result:
Expected Lambda to initialise and be available.
Additional environment details (Ex: Windows, Mac, Amazon Linux etc)
OS: Fedora 40 Kinoite
{
"version": "1.120.0",
"system": {
"python": "3.11.8",
"os": "Linux-6.9.10-200.fc40.x86_64-x86_64-with-glibc2.39"
},
"additional_dependencies": {
"docker_engine": "5.1.2",
"aws_cdk": "Not available",
"terraform": "Not available"
},
"available_beta_feature_env_vars": [
"SAM_CLI_BETA_FEATURES",
"SAM_CLI_BETA_BUILD_PERFORMANCE",
"SAM_CLI_BETA_TERRAFORM_SUPPORT",
"SAM_CLI_BETA_RUST_CARGO_LAMBDA"
]
}
The text was updated successfully, but these errors were encountered: