Catalogsource of type internal are going into crashloopbackoff state

[prafull01]

Bug Report

What did you do?
Create a catalogsource of type internal with a configmap

What did you expect to see?
I expected to see a pod of catalogsource running in my namespace

What did you see instead? Under which circumstances?
I see the pod in crashloopbackoff state.. When I printed the logs, I see the following output:

Error: open /etc/nsswitch.conf: permission denied
Usage:
   [flags]

Flags:
  -c, --configMapName string        name of a configmap
  -n, --configMapNamespace string   namespace of a configmap
  -d, --database string             name of db to output (default "bundles.db")
  -h, --help                        help for this command
  -k, --kubeconfig string           absolute path to kubeconfig file
      --permissive                  allow registry load errors
  -p, --port string                 port number to serve on (default "50051")
  -t, --termination-log string      path to a container termination log file (default "/dev/termination-log")

time="2020-10-12T09:58:24Z" level=panic msg="open /etc/nsswitch.conf: permission denied"
panic: (*logrus.Entry) (0x1773220,0xc00035cee0)

goroutine 1 [running]:
github.com/sirupsen/logrus.Entry.log(0xc0000d6000, 0xc0003971d0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/build/vendor/github.com/sirupsen/logrus/entry.go:239 +0x2db
github.com/sirupsen/logrus.(*Entry).Log(0xc00035ce70, 0xc000000000, 0xc000171f40, 0x1, 0x1)
	/build/vendor/github.com/sirupsen/logrus/entry.go:268 +0xeb
github.com/sirupsen/logrus.(*Logger).Log(0xc0000d6000, 0x0, 0xc000171f40, 0x1, 0x1)
	/build/vendor/github.com/sirupsen/logrus/logger.go:192 +0x7d
github.com/sirupsen/logrus.(*Logger).Panic(...)
	/build/vendor/github.com/sirupsen/logrus/logger.go:233
github.com/sirupsen/logrus.Panic(...)
	/build/vendor/github.com/sirupsen/logrus/exported.go:129
main.main()
	/build/cmd/configmap-server/main.go:58 +0xbe

Environment

• operator-lifecycle-manager version: 0.14.10

• Kubernetes version information:
  kubernetes 1.17

prafull@EMPID18004:~/go/src/github.com/trilioData/k8s-triliovault$ kubectl get node
NAME STATUS ROLES AGE VERSION
gke-e2e-1601628284199-default-pool-0a8662cc-x39g Ready 24m v1.17.12-gke.500

• Kubernetes cluster kind:
  GKE

Possible Solution

Additional context
I guess the bug is originated from here in operator-registry and can be seen with the latest image of operator registry

/kind bug

[benluddy]

I think this broke when operator-framework/operator-registry#425 merged. There's an init step that tries to write out a default /etc/nsswitch.conf if one doesn't already exist. PR here: operator-framework/operator-registry#474.

[benluddy]

Should be fixed with the latest image (as of https://quay.io/repository/operator-framework/configmap-operator-registry/build/9f045c9a-b5a2-40b2-aad5-68139f4de4a1).

[prafull01]

I am still seeing the issue with other error. Probably not fixed completely, here is the error I am getting:

time="2020-10-13T07:29:20Z" level=info msg="Using in-cluster kube client config"
Error: unable to open database file
Usage:
   [flags]

Flags:
  -c, --configMapName string        name of a configmap
  -n, --configMapNamespace string   namespace of a configmap
  -d, --database string             name of db to output (default "bundles.db")
  -h, --help                        help for this command
  -k, --kubeconfig string           absolute path to kubeconfig file
      --permissive                  allow registry load errors
  -p, --port string                 port number to serve on (default "50051")
  -t, --termination-log string      path to a container termination log file (default "/dev/termination-log")

time="2020-10-13T07:29:21Z" level=panic msg="unable to open database file"
panic: (*logrus.Entry) (0x1774220,0xc00013c150)

goroutine 1 [running]:
github.com/sirupsen/logrus.Entry.log(0xc0000b6000, 0xc000294480, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/build/vendor/github.com/sirupsen/logrus/entry.go:239 +0x2db
github.com/sirupsen/logrus.(*Entry).Log(0xc00013c070, 0xc000000000, 0xc000147f40, 0x1, 0x1)
	/build/vendor/github.com/sirupsen/logrus/entry.go:268 +0xeb
github.com/sirupsen/logrus.(*Logger).Log(0xc0000b6000, 0x0, 0xc000147f40, 0x1, 0x1)
	/build/vendor/github.com/sirupsen/logrus/logger.go:192 +0x7d
github.com/sirupsen/logrus.(*Logger).Panic(...)
	/build/vendor/github.com/sirupsen/logrus/logger.go:233
github.com/sirupsen/logrus.Panic(...)
	/build/vendor/github.com/sirupsen/logrus/exported.go:129
main.main()
	/build/cmd/configmap-server/main.go:58 +0xbe

/reopen

[openshift-ci-robot]

@prafull01: Reopened this issue.

In response to this:

I am still seeing the issue with other error. Probably not fixed completely, here is the error I am getting:

time="2020-10-13T07:29:20Z" level=info msg="Using in-cluster kube client config"
Error: unable to open database file
Usage:
  [flags]

Flags:
 -c, --configMapName string        name of a configmap
 -n, --configMapNamespace string   namespace of a configmap
 -d, --database string             name of db to output (default "bundles.db")
 -h, --help                        help for this command
 -k, --kubeconfig string           absolute path to kubeconfig file
     --permissive                  allow registry load errors
 -p, --port string                 port number to serve on (default "50051")
 -t, --termination-log string      path to a container termination log file (default "/dev/termination-log")

time="2020-10-13T07:29:21Z" level=panic msg="unable to open database file"
panic: (*logrus.Entry) (0x1774220,0xc00013c150)

goroutine 1 [running]:
github.com/sirupsen/logrus.Entry.log(0xc0000b6000, 0xc000294480, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
  /build/vendor/github.com/sirupsen/logrus/entry.go:239 +0x2db
github.com/sirupsen/logrus.(*Entry).Log(0xc00013c070, 0xc000000000, 0xc000147f40, 0x1, 0x1)
  /build/vendor/github.com/sirupsen/logrus/entry.go:268 +0xeb
github.com/sirupsen/logrus.(*Logger).Log(0xc0000b6000, 0x0, 0xc000147f40, 0x1, 0x1)
  /build/vendor/github.com/sirupsen/logrus/logger.go:192 +0x7d
github.com/sirupsen/logrus.(*Logger).Panic(...)
  /build/vendor/github.com/sirupsen/logrus/logger.go:233
github.com/sirupsen/logrus.Panic(...)
  /build/vendor/github.com/sirupsen/logrus/exported.go:129
main.main()
  /build/cmd/configmap-server/main.go:58 +0xbe

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[benluddy]

operator-framework/operator-registry#475

[benluddy]

OK, now I think that this should be fixed. The OLM tests that use the configmap registry image in question seem to be working properly, at least.

Thanks for taking the time to file an issue for this.