/bin/bash: /bin/bash: cannot execute binary file

[lukasheinrich]

Hi,

i am trying to get some basic functionality using the cernvm-atlas docker image.

my docker info is:

docker info
Containers: 73
Images: 99
Storage Driver: devicemapper
 Pool Name: docker-253:1-25604962-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 6.713 GB
 Data Space Total: 107.4 GB
 Data Space Available: 13.23 GB
 Metadata Space Used: 10.37 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.137 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.0-229.1.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 1
Total Memory: 1.797 GiB
Name: lheinric-recast-centos.cern.ch
ID: MIUS:PRLB:PAPV:HGI5:GQWT:LNHS:ZUMX:FG4X:XCTZ:HGCE:IF2U:4UOF

curiously it seems to work with binet/cvmfs-atlas

$> docker run binet/cvmfs-atlas /bin/bash -c 'echo hello'
hello
$> docker run hepsw/cvmfs-atlas /bin/bash -c 'echo hello'
/bin/bash: /bin/bash: cannot execute binary file

[sbinet]

ok, that's what I surmised from our twitter conversation.

binet/cvmfs-atlas had no ENTRYPOINT defined. hepsw/cvmfs-atlas does: https://github.com/hepsw/docks/blob/master/cvmfs-atlas/Dockerfile#L27

in the new scheme, if you really want to do such a thing, that would look like:

$ docker run --entrypoint=/bin/echo hepsw/cvmfs-atlas hello
hello

why did I change that? to be sure that in interactive mode (which is the only mode which makes sense for these containers, at least at the moment) the correct shell would be called (ie: /bin/bash) that is, the shell for which loading the CVMFs daemon with the correct configuration and mounting the CVMFs points was done as part of .bashrc.

as an aside, do note all the hepsw/cvmfs-XYZ images have to be run with --privileged switch so the CVMFs mount points can be actually mounted.

[sbinet]

actually, a simpler example would be:

$ docker run hepsw/cvmfs-atlas -c 'echo hello'
hello

that said, I could be convinced to revert to the old "sans ENTRYPOINT", though.

closing as "work as intended." (feel free to reopen if that breaks something for you.)

[lukasheinrich]

great. I confirm that docker run -it --entrypoint=/bin/bash --privileged hepsw/cvmfs-atlas works great

[sbinet]

perfect.

note that (as show in the README) you just have to type:

$ docker run --privileged -i -t hepsw/cvmfs-atlas

(as /bin/bash is the default entry point)

(also, even if I haven't documented yet nor made my intentions clear, I do plan to have a helper executable/script to run these docker run blah containers to ease connecting containers together, rigg users' dev. environments, etc...)

[lukasheinrich]

thanks. so i'm trying to understand what cvmfs-atlas is trying to accomplish. Is this only supposed to mount the cvmfs and set up the ATLAS-specific repos. The latter is of course perfectly reasonable, but I wanted to clarify since I tried a simple localSetupROOT which failed due to some libraries not being present (also gcc is not found?). So I assume the usage model is to have this as a mixin to a larger chain of docker images?

[sbinet]

yes. I tried to make these images as minimal as possible so people could use them as solid foundations for their own purpose.

specifically, for the cvmfs-xyx images, the idea is to have these images run as containers sharing the /cvmfs mount point with other containers (which could be based on any distro) where users would install their favorite production or dev environment.

the tool which will do that will be based on kubernetes. (but besides having a name, it is still vaporware)