SIGSEGV when loading a plugin #6572
Comments
|
More on this, it seems that it's the What I'm doing in short is: ARG GOIPFSVERSION=v0.4.22
# Build in a build container with golang
FROM golang:1.12-stretch AS builder
# ... build go-ipfs@${GOIPFSVERSION} and the plugins accordingly
# Now we override the official go-ipfs container with our things
FROM ipfs/go-ipfs:${GOIPFSVERSION}
# overwrite with our go-ipfs version
COPY --from=builder /root/go/bin/ipfs /usr/local/bin/ipfs
# ... copy the plugins
# override the entrypoint with our script to copy the plugin binary
# before launching the normal /usr/local/bin/start_ipfs
ENTRYPOINT ["/sbin/tini", "--", "/usr/local/bin/docker_wrapper.sh"]
CMD ["daemon"]While building for v0.4.22, if I change the second base image to |
|
The base image for the running stage of |
|
Is it possible to build within the new IPFS container? |
|
Check |
|
If you're looking for a quick workaround:
This will preload the plugin and build it into go-ipfs. |
|
Note: There's some documentation in docs/plugin.md. |
|
Ha, nice trick. I'm good for now with reverting to
Do you mean building go-ipfs + plugins directly in the |
Yes.
Just make sure you're using 0.4.22. The only issue I've found about this is with static builds: golang/go#13470 |
|
Sorry to be annoying, but imho it's really a bug in the Dockerfile (specifically here: https://github.com/ipfs/go-ipfs/blob/master/Dockerfile#L40) because the busybox image version is not set explicitly. As a consequence (and now by default), This has been a headache for me, but it might cause some subtle problem for the normal usage of the ipfs/go-ipfs container.
|
|
Ah, got it. So the issue is that the busybox image is buster based while we're currently stretch based. |
|
(note: the glibc version shouldn't matter, as far as I can tell). |
|
Dealt with by #6582 |
Version information:
go-ipfs version: 0.4.22-
Repo version: 7
System version: amd64/linux
Golang version: go1.12.8
Binaries are compiled locally.
Description:
I'm building go-ipfs and 3 plugins in a docker container. When starting go-ipfs, it crashes with the following stacktrace:
The problem doesn't seem to be related to any plugin in particular, as soon as one of them is present in $IPFS_PATH, this crash happen. To make things more complicated, this seems to only happen inside the docker container: if I extract the binaries (go-ipfs+plugins), it loads just fine.
Note: this whole thing was working fine ~20 days ago with go-ipfs v0.4.21. Alas, I can't run that anymore as the building process seems to be broken:
Building with
GOPROXY='https://proxy.golang.org' GOPATH= go get github.com/ipfs/go-ipfs/cmd/[email protected]leads to missing package in the proxy (go: github.com/go-critic/[email protected]: unexpected status (https://proxy.golang.org/github.com/go-critic/go-critic/@v/v0.0.0-20181204210945-ee9bf5809ead.info): 410 Goneas an example).Building with
GOPATH= go get github.com/ipfs/go-ipfs/cmd/[email protected]leads to the following error:go: github.com/dgraph-io/[email protected]+incompatible: go.mod has post-v2 module path "github.com/dgraph-io/badger/v2" at revision v2.0.0-rc.2The text was updated successfully, but these errors were encountered: