1.0.0 fails to start on Grafana 7.0.3 (on Alpine linux)

[teodoryantcheff]

So after updating our production grafana to 7.0.3 and the google-sheets plugin to 1.0.0 this is what we get in the logs :
grafana t=2020-06-19T11:47:21+0000 lvl=eror msg="Failed to start plugin" logger=plugins.backend pluginId=grafana-googlesheets-datasource error="fork/exec /var/lib/grafana/plugins/grafana-googlesheets-datasource/gfx_sheets_linux_amd64: no such file or directory"

Trying to start gfx_sheets_linux_amd64 manually yields the same results :

bash-5.0$ ./gfx_sheets_linux_amd64
bash: ./gfx_sheets_linux_amd64: No such file or directory
bash-5.0$ pwd
/var/lib/grafana/plugins/grafana-googlesheets-datasource
bash-5.0$

We're running it in a k8s cluster on GKE.
Tried both installing with grafana-cli plugins install ... and downloading the zip from github.

Not sure what to do next, Please advice.

[teodoryantcheff]

So the problem is that gfx_sheets_linux_amd64 that comes in the dist zip is not built for alpine Linux hence missing library references.
Building a statically linked executable (CGO_ENABLED=0 yarn build ) produces an executable that runs.

So, please add alpine to the list of supported platforms for the plugin.

[teodoryantcheff]

The static bin I made available at https://teodoryantcheff.github.io/gfx_sheets_linux_amd64.

For that to run one must delete MANIFEST.TXT and add :

...
[plugins]
allow_loading_unsigned_plugins = grafana-googlesheets-datasource
...

to grafana.ini.

[ryantxu]

@aknuds1 -- should we set CGO_ENABLED=0
https://github.com/grafana/grafana-plugin-sdk-go/blob/master/build/common.go#L120

is that a better default? currently it is not specified so I think depends on the platform where the plugin is built

[aknuds1]

@ryantxu To my understanding, the question isn't fundamentally whether to disable cgo or not, but whether we should statically link our Linux plugins (disabling cgo seems to produce statically linked binaries, I can only guess it's because libc dependencies go away). The author is right in that our current Linux builds of plugins depend on glibc, and won't work on Alpine as a result. We need to fix this, but the question is how.

I think the alternatives are:

• Build also a variant for Linux/musl (works on Alpine, which uses musl for its libc), as we do for Grafana itself
• Build plugins statically linked (should be portable to both glibc and musl based distros)

I'd like to hear from others on the team if there are any strong reasons not to statically link (maybe against musl since it's smaller). When I check the binary size of this plugin, it's practically the same when statically linked with cgo disabled (against glibc, didn't try musl). It's actually 0.02% smaller, maybe because cgo is disabled?

[aknuds1]

I found a comprehensive article on statically linking Go binaries. It seems if you disable cgo, you might lose parts of the standard library (like getting the current user?), so at least if the article is (still) correct, there could be some real drawbacks to it. As such, we might want to consider statically linking in musl.

[teodoryantcheff]

Cause of grafana/grafana-plugin-sdk-go#189 I'm closing this.

[aknuds1]

I've merged the PR to grafana-plugin-sdk-go to produce statically linked binaries, which should fix this issue.

[aknuds1]

Thanks for reporting it!

[teodoryantcheff]

Maybe the one thing left to do is to make an official (signed) plugin release with the static backend binaries, so people don't have to jump through the "run unsigned plugins" hoops?