lambda running twice, and Runtime exited without providing a reason - amazon-web-services

I got a lambda written in Go running on a container, the image was built with alpine-golang and run with alpine.
When testing i noticed from the logs the lambda is ran twice before exiting with the following:
Error: Runtime exited without providing a reason Runtime.ExitError
From my local system this the code runs fine without errors, i earlier tried running without a container but still faced runtime issues. The only error handling and logging mechs in my code is log.Println and fmt.Printf. Anyone got an idea of what is going on?
EDIT:
I trapped the exit code, which is turns out to be 0 but lambda exits with
Runtime exited with error: exit status 1 Runtime.ExitError

I really suggest going for the "without container" path. Just pack your executable into a .zip archive. Don't forget to compile with GOOS=linux for your code to be compatible with AWS Lambda.
On Linux you can use the following commands to get your archive:
GOOS=linux go build -o executableName path/to/main.go
zip archive.zip executableName
Note that you have to set Handler to be executableName in function's Runtime settings.
For handling lambda function, you have to use github.com/aws/aws-lambda-go/lambda package and in main start the handler function like lambda.Start(handler).
Full code example:
package main
import (
"context"
"log"
"github.com/aws/aws-lambda-go/lambda"
)
func main() {
lambda.Start(handler)
}
func handler(ctx context.Context) {
log.Println("successfully executed")
}

Make sure you are following the recommended guide lines aws provide with building the container image. https://docs.aws.amazon.com/lambda/latest/dg/go-image.html
your Dockerfile should look like this to work with lambda,
FROM public.ecr.aws/lambda/provided:al2 as build
# install compiler
RUN yum install -y golang
RUN go env -w GOPROXY=direct
# cache dependencies
ADD go.mod go.sum ./
RUN go mod download
# build
ADD . .
RUN go build -o /main
# copy artifacts to a clean image
FROM public.ecr.aws/lambda/provided:al2
COPY --from=build /main /main
ENTRYPOINT [ "/main" ]
Lambda is very strange where if you have the Dockerfile like you would on a local machine then it runs it once, ends, then a second time and crashes with no reason given

Related

How to add trix.css when it is removed after pruning?

After pruning with the command "docker system prune -a" nodejs wont build anymore beacuse trix.css is missing. I am assuming this was probably deleted while pruning. How can I resolve this error (see the error below)? Why is it not created again while building the container again since the file is in the docker file.
Required path doesn't exist: /code/bower_components/trix/dist/trix.css trix
[13:57:39] 'vendorcss' errored after 1.63 ms
[13:57:39] Error: Promise rejected without Error
at Domain.onError (/usr/local/lib/node_modules/gulp/node_modules/async-done/index.js:49:15)
at Object.onceWrapper (events.js:315:30)
at emitOne (events.js:116:13)
at Domain.emit (events.js:211:7)
at Domain._errorHandler (domain.js:134:21)
at process._fatalException (bootstrap_node.js:375:33)
[13:57:39] 'staging' errored after 41 ms
ERROR: Service 'nodejs' failed to build: The command '/bin/sh -c gulp staging' returned a non-
zero code: 1
Usually I use this command : "sudo docker-compose -f docker-compose-staging.yml build nodejs" when I want to build the container again. I am very new to this and would be greatfull for some help.
For me, this was the case:
The issue exists because trix.css was removed in the latest version. It has nothing to do with docker system prune as far as I understand.
You can compare the two versions here: https://github.com/basecamp/trix/compare/1.3.1...v2.0.0
Basically, in order to fix this issue, you need to do
yarn install
yarn build
inside bower_components. This is suggested in the official updated README of the trix repository: https://github.com/basecamp/trix.
Once done with that, you will have trix.css and trix.umd.min.js files for your perusal.

Need help on compiling DPDK hello world

I try to learn DPDK using the following link: https://doc.dpdk.org/guides/prog_guide/build_app.html
I have downloaded DPDK 19.11.1 version in Ubuntu 16 virtual machine. Then unzipped the tar.gz file. Then I have given the following commands
~/DPDK$ cd examples/helloworld/
~/DPDK/examples/helloworld$ export RTE_SDK=/home/vijay/dpdk
~/DPDK/examples/helloworld$ export RTE_TARGET=x86_64-native-linuxapp-gcc
~/DPDK/examples/helloworld$ make
The following error is displayed:
/home/vijay/dpdk/mk/internal/rte.extvars.mk:29 cannot find .config in /home/vijay/dpdk/build. stop
If I put sudo make, the following error is displayed
Makefile:44: *** "Please define RTE_SDK environment variable". stop
When I put echo $RTE_SDK and echo $RTE_TARGET the values are printed correctly. I tried x86_64-native-linux-gcc for RTE_TARGET also.
I tried multiple times and referred to different sources. Not sure whether I miss any steps in the process. What can I try next?
Based on the error logs, it looks like you have not built dpdk libraries in the desired target folder. To do it correctly
cd dpdk-main-folder
export RTE_SDK=$PWD
export RTE_TARGET=x86_64-native-linuxapp-gcc
make config T=$RTE_TARGET O=$RTE_TARGET
cd $RTE_TARGET
make -j 10
With these done go to your desired example and execute make

Flatpak (flatpak-build) fatal error when building submodules

Following on from here, when using OpenSUSE Tumbleweed I cannot get flatpak-builder to compile submodule dependencies. I first noticed this issue when developing a console application within Gnome Builder using the Vala dependencies Gee and GXml.
As a test, I have installed org.gnome.Books.json and issued the following command (as documented here):
$ flatpak-builder --repo=repo books-app org.gnome.Books.json
The outcome is the same as I observed when developing my own application, the fatal error:
Initializing build dir
Committing stage init to cache
Starting build of org.gnome.Books
fuse: failed to exec fusermount: Permission denied
<more stuff>
Cloning into '/home/robin/Projects-CSim/org.gnome.books/.flatpak-builder/build/gnome-online-accounts-1/telepathy-account-widgets'...
Submodule path 'telepathy-account-widgets': checked out '7d944b79961dfb6291110ceb27597a224d329b36'
error: Build directory /home/<user>/Projects/org.gnome.books/.flatpak-builder/rofiles/rofiles-D4R4cZ not initialized, use flatpak build-init
Error: module gnome-online-accounts: module gnome-online-accounts: Child process exited with code 1
Effectively it fails to build the very first submodule. This is the same behaviour that I observed when invoked from Gnome-Builder on my project; it downloaded but failed to build the very first submodule - in that case it was libgee-0.8.
I've double checked the Flatpak (V0.10.4) installation here and cannot find a solution. I understand from the documentation that invoking flatpak-builder should automatically invoke flatpak build-init.
This is worrisome as Gnome-Builder seems be using Flatpak as the default packager. Any suggestions?
The problem is not Flatpak. It is a conflict between Flatpak and fuse. For some reason this was not occuring with valac or meson from the command line, only Flatpak.
From here we find a solution:
# chmod +x /usr/bin/fusermount
Is this a peculiarity of OpenSUSE Tumbleweed? In any case, after making this change, Flatpak builds submodules as expected. Magnificent!
Not sure about the security aspect of this, however - any comments would be welcomed.

How to run nosetests in jenkins

I have a project which has two folders on same level
/home/ishan/my_repo/jenkins_test/business_logic
/home/ishan/my_repo/jenkins_test/test_cases
test_cases has two files test_fib and test_fact
when I run nosetests --exe at /home/ishan/my_repo/jenkins_test/ it runs correctly showing
....
----------------------------------------------------------------------
Ran 4 tests in 0.036s
OK
I am trying to run these test cases so, I created following script at /home/ishan/my_repo
#!/bin/bash
source /home/ishan/venv/bin/activate
nosetests --exe /home/ishan/sf_shared/my_repo/jenkin_test/
deactivate
When I run it using
source /home/ishan/my_repo/test_runner.sh it shows correct output.
So, I tried to put it in jenksins build step. So, I added the same line
source /home/ishan/my_repo/test_runner.sh in command section of Execute Shell in jenkins.
Now, when I trigger the build using build now it fails saying
Started by user anonymous
Building in workspace /var/lib/jenkins/workspace/jenkins_test
[jenkins_test] $ /bin/sh -xe /tmp/hudson5020664150857393715.sh
+ source /home/ishan/sf_shared/test_runner.sh
/tmp/hudson5020664150857393715.sh: 2: /tmp/hudson5020664150857393715.sh: source: not found
Build step 'Execute shell' marked build as failure
Finished: FAILURE
I think it doesn't even execute any test cases. It fails long before.
Can you suggest what am I doing wrong?
Maybe this will works:
/home/ishan/venv/bin/nosetests --exe /home/ishan/sf_shared/my_repo/jenkin_test/
Resolved it, issue was with the following line
source /home/ishan/venv/bin/activate
I replaced it source with standard . then it worked. So, my line became
. /home/ishan/venv/bin/activate

GDB - Attach to and break a running Go application

I compiled a simple go application with debug flags:
go build -gcflags "-N -l" -o main main.go
main.go
package main
import (
"fmt"
"time"
)
func main() {
for i := 0; true; i++ {
fmt.Println("number:", i)
time.Sleep(time.Second)
}
}
In gdb, I attached to its pid and executed break and break 11.
gdb --pid=<pid>
Gdb reports that the breakpoints are successfully set, but they don't ever get hit. Is there a way to get this working?
Note: that same setup (even when adding your runtime-gdb.py to your .gdbrc) risks to not work with Ubuntu 13.10, where you would get a "SyntaxError" message, as illustrated in:
blog post "Debugging Go 1.2 on Ubuntu 13.10 with GDB" from Michael Susens-Schurter (schmichael)
issue 6698 (gdb: upgrade to be python 3 compatible)
The problem is that Ubuntu 13.10 links GDB against Python 3.3 while the script golang ships is for Python 2. Someone has already filed an issue, and it appears to be fixed upstream (so expect Go 1.3 to Just Work).
Luckily backporting the fix is easy. Simply move your exist runtime-gdb.py out of the way and download the upstream version in its place.
If your $GOROOT is /usr/local/go the following should Just Work:
sudo mv /usr/local/go/src/pkg/runtime/runtime-gdb.py /usr/local/go/src/pkg/runtime/runtime-gdb.py.orig
cd /usr/local/go/src/pkg/runtime/
sudo wget https://go.googlecode.com/hg/src/pkg/runtime/runtime-gdb.py
the go/src/pkg/runtime/runtime-gdb.py script needs to be loaded inside gdb to effectively be able to debug go programs.
You can add it to the .gdbrc file.