No grafana-agent for armhf?

[ealmonte32]

Sorry if this was addressed before but before posting I searched around and did not find any concrete answer, also in the packages I only see the binary and not the deb package so that the cloud agent can be automatically installed and registered to my grafana account with the corresponding cloud API key etc.. it gives the error that the deb package is for amd64 arch only and I'm testing running it on a Raspberry Pi 3 which is running Raspian buster on arch armv7..
Any help is appreciated, thanks.

pi@pi3dev:~ $ sudo GCLOUD_STACK_ID="######" GCLOUD_API_KEY="*************" /bin/sh -c "$(curl -fsSL https://github.com/raw/grafana/agent/release/production/grafanacloud-install.sh)"
--- Using package system deb. Downloading and installing package
dpkg: error processing archive /tmp/grafana-agent.deb (--install):
 package architecture (amd64) does not match system (armhf)
Errors were encountered while processing:
 /tmp/grafana-agent.deb

[ealmonte32]

I am going to close this but hoping that first someone answers why I had to use the "Other Distribution" method and manually change the amd64 to armv7 and then continue the other steps manually... I just wonder why the install script doesn't retrieve the appropriate binary depending the arch of the user's device..

[rfratto]

Hey there, you're right, the install script just assumes amd64 at the moment. We're planning on fixing this, but have been discussing how to handle it (e.g., detect automatically or show an architecture selection for users to pick themselves). Sorry for the confusion!

[ealmonte32]

Hey there, you're right, the install script just assumes amd64 at the moment. We're planning on fixing this, but have been discussing how to handle it (e.g., detect automatically or show an architecture selection for users to pick themselves). Sorry for the confusion!

I can cook up a quick user selection prompt when the script is executed and based on that selection to pull the right package version.. should I give it a try? I think something is better than nothing and can be tweaked later on. Let me know if you think I should go for it and put it as a PR.

[rfratto]

I can cook up a quick user selection prompt when the script is executed and based on that selection to pull the right package version.. should I give it a try? I think something is better than nothing and can be tweaked later on. Let me know if you think I should go for it and put it as a PR.

Feel free to contribute! Though for now, I think I'd prefer the selection be done via an environment variable/command line flag, similarly to what we do in this script for setting the Kubernetes namespace.

[ealmonte32]

Feel free to contribute! Though for now, I think I'd prefer the selection be done via an environment variable/command line flag, similarly to what we do in this script for setting the Kubernetes namespace.

Got it, yeah I already tested using variables and works, and we can pass the flag to the case argument in a nested form because since you already have which type of system rpm or deb, if its deb then which arch of deb and then based on that it directs to the package.

[ealmonte32]

Ok, so far I've managed to do something like this as an example for when its armv7:

PACKAGE_SYSTEM=${PACKAGE_SYSTEM:=}

archcheck() {
ARCH=$(arch);
 case "$ARCH" in
  *armv7*) install_arm ;;
        *) fatal "Unknown arch." ;;
 esac
}

#
# Global constants.
#
RELEASE_VERSION="0.11.0"

RELEASE_URL="https://github.com/grafana/agent/releases/download/v${RELEASE_VERSION}"
DEB_URL="${RELEASE_URL}/grafana-agent-${RELEASE_VERSION}-1.x86_64.deb"
ARMV7_URL="${RELEASE_URL}/agent-linux-armv7.zip"
RPM_URL="${RELEASE_URL}/grafana-agent-${RELEASE_VERSION}-1.x86_64.rpm"

.
.
.

# install_arm downloads and installs the arm package of the Grafana Cloud Agent.
install_arm() {
  curl -sL "${ARMV7_URL}" -o /tmp/grafana-agent.zip
  unzip -o /tmp/grafana-agent.zip
  chmod a+x agent-linux-armv7
  rm /tmp/grafana-agent.zip
}

But then I am getting stuck in the part where I have to manually create the grafana-agent.service with systemd, etc, and even then, the service just says:

grafana-agent.service - Grafana Cloud Agent
   Loaded: loaded (/etc/systemd/system/grafana-agent.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2021-01-29 20:46:24 GMT; 24min ago
 Main PID: 3440 (agent-linux-arm)
    Tasks: 9 (limit: 1786)
   CGroup: /system.slice/grafana-agent.service
           └─3440 /home/pi/agent-linux-armv7 --config.file=/etc/grafana-agent.yaml

Jan 29 20:46:24 pi3dev systemd[1]: Started Grafana Cloud Agent.
Jan 29 20:46:24 pi3dev agent-linux-armv7[3440]: level=info ts=2021-01-29T20:46:24.49678796Z caller=server.go:225 http=[::]:80 grpc=[::]:9095 msg="server listening on addresses"
pi@pi3dev:~ $ 

But the grafana-agent.yaml file is empty..
What am I missing?

[rfratto]

The config file is generated by running grafana-agentctl cloud-config in the script, you'll likely need to copy over the armv7 binary of that file too.

[rfratto]

FYI, we're going to have platform-specific deb/rpm packages in v0.12.0 (changelog), which is due near the end of next week

[ealmonte32]

So I should basically just leave it alone until v0.12.0 😄 ?

[rfratto]

Ha, probably, it would make adding in architecture selection a lot easier :)
(I forgot it wasn't already released, sorry about that)

[ealmonte32]

Gotcha.
Ok, will close this then.
Thx for help and info.

[ealmonte32]

Btw, after incorporating the agentctl to retrieve the config file, everything worked as expected, in other words, my install script checked the architecture, if the system was deb it then checked which deb arch, then it found it was ARMv7, then downloaded both binaries the grafana-agent and the agentctl belonging to armv7, then setup the grafana-agent.service by doing that cat <<EOF command, and then everything worked.. is this basically what the platform specific deb package in 0.12.0 will be doing? just wondering.

[rfratto]

You can check out #344 for the PR that added more platform packages. They're the same as the existing packages but with architecture-appropriate builds of the binaries. The install script still doesn't allow for any architecture selection as of the development branch, though, and still assumes the x86_64 (renamed amd64 in 0.12.0) package.

[ealmonte32]

Got it, I see the commits for armv7 being part of the package build.. I'll test the installer out when released and give feedback if I see anything not working or any errors. 👍🏻

[ealmonte32]

Sorry but even though the manual installation and all worked, I just have one minor issue with the grafana-agent.service when manually creating it, it seems like any time I add a User= to the exec of the file, I get a permission issue and it does not start, only if I allow the service to start without the process being ran by any specific user does it work properly.. I am following the exact steps from the agent_as_a_service documentation on the web.. any ideas?

agent-linux-armv7[8034]: level=error ts=2021-02-01T00:38:34.934475869Z caller=main.go:55 msg="failed to create server" err="listen tcp :80: bind: permission denied"

service file and agent are owned by root:

pi@pi3dev:~ $ ls -lah /etc/systemd/system/grafana-agent.service
-rw-r--r-- 1 root root 226 Feb  1 00:38 /etc/systemd/system/grafana-agent.service


pi@pi3dev:~ $ ls -lah /usr/local/bin/agent-linux-armv7
-rwxr-xr-x 1 root root 65M Jan 31 23:48 /usr/local/bin/agent-linux-armv7

this is the contents of grafana-agent.service:

pi@pi3dev:~ $ cat /etc/systemd/system/grafana-agent.service
[Unit]
Description=Grafana Cloud Agent

[Service]
User=grafana-agent
ExecStart=/usr/local/bin/agent-linux-armv7 --config.file=/etc/grafana-agent.yaml
Restart=always
RestartSec=5s

[Install]
WantedBy=multi-user.target

the user exists:

pi@pi3dev:~ $ lslogins
  UID USER             PROC PWD-LOCK PWD-DENY  LAST-LOGIN GECOS
    0 root               96                               root
    1 daemon              0                               daemon
    2 bin                 0                               bin
    3 sys                 0                               sys
    4 sync                0                               sync
    5 games               0                               games
    6 man                 0                               man
    7 lp                  0                               lp
    8 mail                0                               mail
    9 news                0                               news
   10 uucp                0                               uucp
   13 proxy               0                               proxy
   33 www-data            0                               www-data
   34 backup              0                               backup
   38 list                0                               Mailing List Manager
   39 irc                 0                               ircd
   41 gnats               0                               Gnats Bug-Reporting System (admin)
  100 systemd-timesync    1                               systemd Time Synchronization,,,
  101 systemd-network     0                               systemd Network Management,,,
  102 systemd-resolve     0                               systemd Resolver,,,
  103 _apt                0                               
  104 messagebus          1                               
  105 _rpc                0                               
  106 statd               0                               
  107 sshd                0                               
  108 avahi               2                               Avahi mDNS daemon,,,
  109 grafana             1                               
  996 systemd-coredump    0                               systemd Core Dumper
 1000 pi                  5                   Jan31/20:10 ,,,
 1001 grafana-agent       0        <<<<<<<<<<<<<<<<<<------------------------                       
65534 nobody              1                               nobody

[rfratto]

(FYI I'd recommend reaching out to Grafana Cloud Support for issues with Grafana Cloud. While I'm happy to help, Grafana's Support team goes way beyond just me and you're more likely to get help sooner)

Port 80 is the default port of the HTTP server and requires root. This shouldn't be happening, I'll create an internal ticket to get our cloud config to use a non-root port by default.

In the meantime, change the server block in the Agent config and set it to another port:

server:
    http_listen_port: 8080 # or whatever works for you 

[rfratto]

Oh, actually, the cloud config listens on 12345 by default. Did you change that?

[ealmonte32]

Oh, actually, the cloud config listens on 12345 by default. Did you change that?

Nope, I was just doing this whole customized grafanacloud-install.sh script for the armv7 and part of it was to manually create the agent service which is done with systemd and all that, so when it runs, remember it is running the cloud-config that it retrieved from the cloud agent based on the GCLOUD_API_KEY and GCLOUD_STACK_ID, so I actually never touch the default grafana-agent.yaml file once it is downloaded and placed in the /etc/ directory.

About contacting grafana cloud support, it really isn't a big deal, i was just trying to fix the grafanacloud-install.sh script and seeing if a finalized version would have been good to contribute until 0.12.0 was released, but also for learning purposes.

[AE720]

I'm mentioning this. The lack of any information on a armv7 build is asinine. I'm trying to install the agent on a Pi which everywhere I can find says it supports, only to see no reference in either Debian based, or other Linux distribution There's nothing in the script that points to anything but 64bit architecture and I can't find any information on it's discontinuation. If it is possible to install this on a Pi 3. no information exists on it. I can't find even a manual package to install manually.

[rfratto]

We don't support 32-bit platforms due to a Go compiler bug. golang/go#58425

This won't change unless the bug gets fixed.

[grossadamm]

That linked issue is now marked as done, does that mean this should be re-opened? I'm not sure what the process is.

[rfratto]

That linked issue is now marked as done, does that mean this should be re-opened? I'm not sure what the process is.

There should usually be a new issue created; it's too easy for maintainers to miss comments on closed issues or reopened old issues.

However, in this particular case, we're not sure whether it's worth adding back support for 32-bit ARM devices. We haven't heard more than a handful of requests to bring back support, and we're not confident yet that there won't be:

• A regression causing 32-bit ARM builds to break again, forcing us to remove support again (the Go team has done several fixes for the bug, and it's hard to tell if this latest one is a real, final fix)
• Yet another 32-bit ARM build issue forcing us to remove support again
• Or a future change that might require a 64-bit host (#5225?)

I'd still encourage you to open a new issue for returning 32-bit ARM support. It's not a "no" from the maintainers right now, and we're mainly waiting for demand to rise before making a final decision about what to do.

[grossadamm]

Thank you for the thoughtful response @rfratto