https://yryz.net/post/golang-docker-alpine-start-panic.html
用docker基于alpine微型镜像部署go的项目,启动时报错 panic: standard_init_linux.go:175: exec user process caused "no such file or directory"
,去年测试docker时遇到过,没去深入研究,这次项目遇又到了,深入分析了一下。
详细错误记录:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
➜ xxx git:(master) ✗ docker run --rm -it xxxx.com/xxx_webapp:prod panic: standard_init_linux.go:175: exec user process caused "no such file or directory" [recovered] panic: standard_init_linux.go:175: exec user process caused "no such file or directory" goroutine 1 [running, locked to thread]: panic(0x88f8a0, 0xc82011bb20) /usr/local/go/src/runtime/panic.go:481 +0x3e6 github.com/urfave/cli.HandleAction.func1(0xc8200e72e8) /tmp/tmp.UkUQ4KXBPZ/src/github.com/opencontainers/runc/Godeps/_workspace/src/github.com/urfave/cli/app.go:478 +0x38e panic(0x88f8a0, 0xc82011bb20) /usr/local/go/src/runtime/panic.go:443 +0x4e9 github.com/opencontainers/runc/libcontainer.(*LinuxFactory).StartInitialization.func1(0xc8200e6bf8, 0xc82001a0c8, 0xc8200e6d08) /tmp/tmp.UkUQ4KXBPZ/src/github.com/opencontainers/runc/Godeps/_workspace/src/github.com/opencontainers/runc/libcontainer/factory_linux.go:259 +0x136 github.com/opencontainers/runc/libcontainer.(*LinuxFactory).StartInitialization(0xc820051630, 0x7fc3c9efc728, 0xc82011bb20) /tmp/tmp.UkUQ4KXBPZ/src/github.com/opencontainers/runc/Godeps/_workspace/src/github.com/opencontainers/runc/libcontainer/factory_linux.go:277 +0x5b1 main.glob.func8(0xc82006ea00, 0x0, 0x0) /tmp/tmp.UkUQ4KXBPZ/src/github.com/opencontainers/runc/main_unix.go:26 +0x68 reflect.Value.call(0x7f45a0, 0x9a4d88, 0x13, 0x8ebac8, 0x4, 0xc8200e7268, 0x1, 0x1, 0x0, 0x0, ...) /usr/local/go/src/reflect/value.go:435 +0x120d reflect.Value.Call(0x7f45a0, 0x9a4d88, 0x13, 0xc8200e7268, 0x1, 0x1, 0x0, 0x0, 0x0) /usr/local/go/src/reflect/value.go:303 +0xb1 github.com/urfave/cli.HandleAction(0x7f45a0, 0x9a4d88, 0xc82006ea00, 0x0, 0x0) /tmp/tmp.UkUQ4KXBPZ/src/github.com/opencontainers/runc/Godeps/_workspace/src/github.com/urfave/cli/app.go:487 +0x2ee github.com/urfave/cli.Command.Run(0x8ee970, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x984240, 0x51, 0x0, ...) /tmp/tmp.UkUQ4KXBPZ/src/github.com/opencontainers/runc/Godeps/_workspace/src/github.com/urfave/cli/command.go:191 +0xfec github.com/urfave/cli.(*App).Run(0xc820001500, 0xc82000a100, 0x2, 0x2, 0x0, 0x0) /tmp/tmp.UkUQ4KXBPZ/src/github.com/opencontainers/runc/Godeps/_workspace/src/github.com/urfave/cli/app.go:240 +0xaa4 main.main() /tmp/tmp.UkUQ4KXBPZ/src/github.com/opencontainers/runc/main.go:137 +0xe24 |
首先确认被执行的程序都是存在的,经过一番搜索测试也没解决。
之前用GOOS=linux GOARCH=amd64 go build
是可以的,这次是通过golang的docker镜像编译的确不行,对比编译后的文件发现有猫腻。
1 2 3 |
> GOOS=linux GOARCH=amd64 go build > file xxx xxx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped |
vs docker build:
1 2 3 |
> docker run --rm -it -v $GOPATH:/go golang:1.7 bash -c 'cd $GOPATH/src/xxx && go build > file xxx xxx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped |
问题找到了,一个是静态链接,一个是动态链接,动态链接的在微型镜像alpine上不支持。
CGO_ENABLED=0
来解决。go build --ldflags "-extldflags -static"
来让gcc使用静态编译。参考:Linking golang statically