Panic: invalid memory address or nil pointer dereference

[gordontyler]

I've had this working for a while on various hosts, but today I noticed that the instance running on one of my hosts had the status Restarting (2). The logs contianed the following:

INFO[0000] Waking up to check for volumes...
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x8 pc=0x4d8e5a]

goroutine 1 [running]:
github.com/fsouza/go-dockerclient.(*Env).Map(0x0, 0x0)
        /go/src/github.com/cloudnautique/vol-cleanup/Godeps/_workspace/src/github.com/fsouza/go-dockerclient/env.go:159 +0x2a
github.com/fsouza/go-dockerclient.(*Env).Get(0x0, 0x819bb0, 0xd, 0x0, 0x0)
        /go/src/github.com/cloudnautique/vol-cleanup/Godeps/_workspace/src/github.com/fsouza/go-dockerclient/env.go:20 +0x3a
github.com/cloudnautique/vol-cleanup/volumes.Volumes.GetVolumes(0xc20800b140, 0x837630, 0x17, 0x0, 0x0)
        /go/src/github.com/cloudnautique/vol-cleanup/volumes/volume.go:34 +0x7f
main.Start(0x5, 0x80fb00, 0x0, 0x0)
        /go/src/github.com/cloudnautique/vol-cleanup/main.go:49 +0x22d
main.func·001(0xc20808c000)
        /go/src/github.com/cloudnautique/vol-cleanup/main.go:35 +0x168
github.com/codegangsta/cli.(*App).Run(0xc20805e400, 0xc20800a000, 0x3, 0x3, 0x0, 0x0)
        /go/src/github.com/cloudnautique/vol-cleanup/Godeps/_workspace/src/github.com/codegangsta/cli/app.go:164 +0xddd
main.main()
        /go/src/github.com/cloudnautique/vol-cleanup/main.go:38 +0x26a

Docker info:

Client:
 Version:      1.8.2
 API version:  1.20
 Package Version: docker-1.8.2-7.el7.centos.x86_64
 Go version:   go1.4.2
 Git commit:   bb472f0/1.8.2
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.2
 API version:  1.20
 Package Version:
 Go version:   go1.4.2
 Git commit:   bb472f0/1.8.2
 Built:
 OS/Arch:      linux/amd64

The host is Centos 7 running in a vSphere VM. I have a number of other identical hosts running the container without this problem.

[cloudnautique]

I think I'm swallowing an error when I go to collect the docker Info that probably holds the key to this.

On Centos 7, when you bind mount in the docker.sock you have to run in --privileged.

If you wouldn't mind trying it with --privileged to confirm my suspicion. I'll also need a to do an updated version that doesn't swallow the error. Not sure what I was thinking there :)

[gordontyler]

Yes, adding --privileged worked.

[cloudnautique]

Thanks for checking. I don't think we can get around that. It technically is a privileged container since it has the docker socket and /var/lib/docker access. I'll add something to the README to inform users it needs the --privileged flag for everything. May as well be explicit.

[cloudnautique]

I added the --privileged flag to the docs, I also caught the error that let the panic happen.

I'm going to close this issue.