grafana / synthetic-monitoring-agent

Synthetic Monitoring Agent

Home Page:https://grafana.com/docs/grafana-cloud/how-do-i/synthetic-monitoring/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

bash: ./synthetic-monitoring-agent: cannot execute binary file

anhdle14 opened this issue · comments

Try to install to AWS EC2: by following exactly this link. Also tried to install manually via GH release.

[root@ip-xxxx~]# wget https://github.com/grafana/synthetic-monitoring-agent/releases/download/v0.10.2/synthetic-monitoring-agent_0.10.2_Linux_x86_64.zip
Saving to: ‘synthetic-monitoring-agent_0.10.2_Linux_x86_64.zip’
[root@ip-xxxx ~]# unzip synthetic-monitoring-agent_0.10.2_Linux_x86_64.zip
Archive:  synthetic-monitoring-agent_0.10.2_Linux_x86_64.zip
  inflating: CHANGELOG.md
  inflating: LICENSE
  inflating: README.md
  inflating: synthetic-monitoring-agent
[root@ip-10-17-230-10 ~]# chmod +x synthetic-monitoring-agent
[root@ip-10-17-230-10 ~]# ./synthetic-monitoring-agent
bash: ./synthetic-monitoring-agent: cannot execute binary file
[root@ip-10-17-230-10 ~]# uname -r
5.10.147-133.644.amzn2.x86_64

Doesn't seem to happen in 0.9.x version.

I experienced the same issue with the AMD64 DEB package. Upon further inspection of the executable file, it looks like the files included in the package are for the wrong architecture. The output of the 'file' tool yields ARM aarch64 architecture for both the AMD64 DEB package and the Linux_x86_64 package:

root@sm01-lpv1-srv01:/tmp# unzip synthetic-monitoring-agent_0.10.2_Linux_x86_64.zip
Archive: synthetic-monitoring-agent_0.10.2_Linux_x86_64.zip
inflating: CHANGELOG.md
inflating: LICENSE
inflating: README.md
inflating: synthetic-monitoring-agent
root@sm01-lpv1-srv01:/tmp# file synthetic-monitoring-agent
synthetic-monitoring-agent: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, Go BuildID=Cu1obHqDMGpbNWOJMglF/bOYDmiFia8uZ_yqT5eIt/JO34gkg-ePerZeekbz11/MCt_9AKUh2RrmxCwHltT, not stripped

Is this a joke ?

@mem the amd64 .deb file in the release as well as the package that was published to the repository appear to contain binaries for the arm64 architecture instead of amd64. This prevents the service from working.

How does an issue like this not get fixed after 12 days?

Sorry, I was away from the keyboard, looking...

My apologies for the handling of this issue.

From the commit message for the fix:

A while back the use of the WANTED_OSES and WANTED_ARCHES variables was removed in favor of buidling a single list using PLATFORMS, which has a default value. (this refers to the build process)

When this was fixed, the scripts/package/goreleaser-build wrapper was broken, and we didn't notice because we didn't do a release. Later we didn't notice because we ourselves use the docker images, which are unaffected by this. (this refers to the fact that the same binaries that we use to run the service ourselves are the binaries that end up in the packages, but we don't install the agent from the packages but from the docker images).

Fix this by passing PLATFORMS in the wrapper.