Start of SPC cause 'Unable to start shell:/bin/bash'

[ybznek]

This is probably not problem of our code, I only want to have this issue somewhere to open discussion.

I have the issue only last days. after I start our SPC, I am not able to start new terminal on my host, I will get only Unable to start shell:/bin/bash. Problem is still here when I kill docker.

When I use our LABEL RUN="docker run -dt --privileged --pid=host -v /etc/oscapd:/etc/oscapd -v /proc/:/hostproc/ -v /sys/fs/cgroup:/sys/fs/cgroup -v /var/log:/var/log -v /run:/run -v /var/lib/docker/devicemapper/metadata/:/var/lib/docker/devicemapper/metadata/ -v /dev/:/dev/ -v /var/tmp/image-scanner:/var/tmp/image-scanner --env container=docker --net=host --cap-add=SYS_ADMIN --ipc=host IMAGE" for clean fedora:23 image I have this problem too.

atomic run has some --spc option to start container, but Daemon doesn't work only with it - but I don't have the issue.

@jan-cerny said he saw the issue too

Thanks for advice. I will probably investigate it later, maybe the same issue can have more users - I don't know it, now.

fedora23, Docker version 1.9.1, build 7206621

[mpreisler]

@baude, have you seen this as well?

I have seen this with older versions of docker but I was under the impression that it was a known bug and has been fixed. I tried to look for the bug number to reference but can't find it.

[baude]

I'm on the road this week but are you using atomic run or atomic run --spc . If the latter, that flag is not needed because we already have the permissions that --spc sets in the RUN label.

[jan-cerny]

@baude we are using atomic run. We don't use atomic run --spc

[jan-cerny]

I use Fedora 23 Workstation and I have similar issue.

1) In GNOME Terminal, run sudo atomic run openscap/openscap-daemon-f23 2) Click on File -> Open Terminal 3) I got this:

I am unable to open any new terminal Window after running the SPC. If I close all terminal windows and try to lunch the Terminal again, I get the same error again.

Reproducible always on my machine.

I use atomic-1.8-3.gitcc5997a.fc23.x86_64 and gnome-terminal-3.18.2-1.fc23.x86_64

[jan-cerny]

And when I try to start the fabulous Terminator app instead of GNOME Terminal, I got the message: Unable to start shell:/bin/bash. And attention! When I close the Terminator window, I am kicked out from GNOME. The problem persists even after logging back again.

[jan-cerny]

I had an idea that it could be caused by -t option in our Dockerfiles, but I verified that removing -t doesn't fix the issue.

[jan-cerny]

@mpreisler Do you remember some details about the issue you encountered with older versions? Which versions?

[mpreisler]

@jan-cerny Sorry but as I said, I can't find references and I don't remember versions.

[jan-cerny]

@mpreisler @baude @all Hello. Do you know something more about this? Do you have some update?? Thanks in advance for all your info.

[jan-cerny]

As @baude suggested last week, it seems to be related the fact that we bind mount the whole /dev directory (-v /dev/:/dev). Is there a way how to mount only necessary parts instead of whole directory? I mean to mount /dev/mapper + have some separated place where the block devices (dm-* files) will be stored.

[baude]

As was explained to me by Dan Walsh, this is actually a bug in docker and is fixed in docker-1.10-ish.

[baude]

@jan-cerny I dropped the -t in the RUN label and it worked for me. Does it work for you as well ?

[mpreisler]

@baude @jan-cerny Perhaps we can drop the -t argument in all the SPC labels. There could be more options and and mounts that are unnecessary. It would be nice to do a review.

[jan-cerny]

Thank you very much for new information.

As I have mentioned above in one of my previous comments, removing -t from labels in Dockerfile does not help me, the issue still happens after building and running new container. I have verified it again.

I have installed docker-1.10.2-6.git0f5ac89.fc23.x86_64 from updates-testing repository and the issue doesn't happen with the new version. So I can confirm that the issue is a bug in Docker and it is fixed in Docker 1.10.

Regarding -t option: With Docker 1.10 I have tried both with -t and without -t and the bug doesn't appear in both cases. On the other hand, I think we don't need it the -t option, because we don't need to allocate a pseudoterminal for our openscap-daemon SPC. man docker run says about this:

-t, --tty=true|false Allocate a pseudo-TTY. The default is false. When set to true Docker can allocate a pseudo-tty and attach to the standard input of any container.

[mpreisler]

If we don't need -t we should remove it from the label even if it doesn't fix the issue. Having less arguments will make it less complex and hopefully less error prone. Therefore I think we should do a review and remove as many mounts and arguments as possible from the run labels.

[jan-cerny]

@mpreisler I agree with you. I will remove all -t. I will also try to remove other options if possible.

[jan-cerny]

@mpreisler I reviewed the options last week. I spent some time testing and trying. In my opinion there are some options that could be removed and vulnerability scan would work. However I am not sure whether we need them for configuration scan of containers. I think we can postpone this for later, because I don't want to remove the options and add them back again in a few weeks.

[mpreisler]

@jan-cerny Which options are you not sure about?

[jan-cerny]

@mpreisler: --pid=host --env container=docker --net=host --cap-add=SYS_ADMIN

[mpreisler]

Yeah, we need all those for security compliance. So did you find options you can remove other than -t?

[jan-cerny]

@mpreisler No, I didn't.

[mpreisler]

Ok, let's close this then.