I think I see the issue. When the chroot environment is being created, we bind-mount a default set of paths. This includes
/etc/passwd, which defines the Unix user
nobody that we run the process under. If I leave that out, I can replicate what you’re seeing:
2019-11-22T19:07:17.032Z [ERROR] client.alloc_runner.task_runner: running driver failed: alloc_id=75455c34-6904-3627-88cc-83b4270adbf2 task="run uuid chroot exec" error="failed to launch command with executor: rpc error: code = Unknown desc = container_linux.go:346: starting container process caused "setup user: unable to find user nobody: no matching entries in passwd file""
2019-11-22T19:07:17.032Z [INFO] client.alloc_runner.task_runner: not restarting task: alloc_id=75455c34-6904-3627-88cc-83b4270adbf2 task="run uuid chroot exec" reason="Error was unrecoverable"
You’ll need to add
/etc/passwd to the chroot env. This is definitely something we should clearly call out in the docs, so I’ll fix that!
using go version go1.6.2 linux/amd64
That’s a pretty old version of go. But if you don’t feel like standing up a whole golang toolchain (certainly understandable!) and you have Docker handy you could drop that as primes.go in your home directory and then run:
docker run -it --rm -v $(pwd):/tmp golang:1.12 go build -o /tmp/primes /tmp/primes.go
That’ll drop a Linux executable named
primes in the home dir, which you could place on the client.