-
Notifications
You must be signed in to change notification settings - Fork 12
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
Gödel build of linux/amd64 check_cpu doesn't seem to work in container #184
Comments
Something else is amiss. The binary as fetched and extracted from the latest release on GitHub executes successfully in my Docker container:
|
Hi @quaggoth, apologies--I neglected to mention that this is inside of an Alpine container. This still seems to be the case that the check doesn't work on alpine, though other checks that I've used that are for a linux/amd64 OS (which Alpine reports to be) work. Bare Alpine container w/ nagiosfoundation asset docker container run --rm -it alpine:latest /bin/sh
/ # apk add curl
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz
(1/4) Installing ca-certificates (20190108-r0)
(2/4) Installing nghttp2-libs (1.39.2-r0)
(3/4) Installing libcurl (7.66.0-r0)
(4/4) Installing curl (7.66.0-r0)
Executing busybox-1.30.1-r2.trigger
Executing ca-certificates-20190108-r0.trigger
OK: 7 MiB in 18 packages
/ # curl -Ls https://github.com/ncr-devops-platform/nagiosfoundation/releases/download/0.2.2/nagiosfou
ndation-linux-amd64-0.2.2.tgz | tar -zxvf - bin/check_cpu
bin/check_cpu
/ # bin/check_cpu
/bin/sh: bin/check_cpu: not found Bare Alpine container w/ asachs01/sensu-go-cpu-check asset / # curl -Ls https://github.com/asachs01/sensu-go-cpu-check/releases/download/0.0.4/sensu-go-cpu-check_0.0.4_linux_amd64.tar.gz | tar -xvzf - bin/sensu-go-cpu-check
/ # bin/sensu-go-cpu-check
CheckCPU OK - value = 4.90 | system_cpu=4.90 And looking at the two executables: ~/bin # ls
check_cpu sensu-go-cpu-check
~/bin # file check_cpu
check_cpu: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=Pu00gzT2065S5Dy-zGy2/PdiIixQaDF-d5K6noDi8/GVfrQ4yBBPUAmTEfRPEV/LLEXmQiAuf1Cj5yupBBi, not stripped
~/bin # file sensu-go-cpu-check
sensu-go-cpu-check: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=FqwmBQw8H4gbO32qY26t/CzNPCRUB9lUTKimGZ4WK/exS17Huy1gQE-Q-RgqZE/W2Uo8KvQoRJRXR9cEgPj, stripped Which looks like the |
@quaggoth also in chatting with our engineers, the other possibility would be to ensure that |
Discussed with our eng folk, it seems |
Ah. Alpine. Good times for you. Alpine is not based on
There may be some other ways around this but I certainly am not aware of them off the top of my head. It would probably involve statically linking Using the workaround above, here's a full example run using Alpine...
|
Yes, I would take a pull request with Based on the documentation for it, I doubt it will cause any issues: |
Yup! I actually got it working by adding that compatibility package. I'll work on testing w/ cgo disabled and get a PR in. |
Greetings NCR team!
I've been using the collection here across Windows systems, Linux systems, and Docker containers. I've noticed that there seems to be a way that the executables are built w/ Gödel vs building the executables natively, or with goreleaser.
The scenario that has surfaced this difference is that I'm running the
check_cpu
check across Linux, Windows and Docker. I have Linux entities that report back as linux/amd64 and Docker containers that report back as linux/amd64.When the collection is downloaded on the Linux systems, the check runs without issue. However, in Docker containers, I receive an error:
Compare that with the Linux systems:
I found that if I build the executable natively and copy it into the container, it works:
Is there something that needs to be changed with Gödel's builds for them to work on containers?
The text was updated successfully, but these errors were encountered: