Closed ybznek closed 8 years ago
@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.
I'm on the road this week but are you using atomic run
@baude we are using atomic run
. We don't use atomic run --spc
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
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.
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.
@mpreisler Do you remember some details about the issue you encountered with older versions? Which versions?
@jan-cerny Sorry but as I said, I can't find references and I don't remember versions.
@mpreisler @baude @all Hello. Do you know something more about this? Do you have some update?? Thanks in advance for all your info.
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.
As was explained to me by Dan Walsh, this is actually a bug in docker and is fixed in docker-1.10-ish.
@jan-cerny I dropped the -t in the RUN label and it worked for me. Does it work for you as well ?
@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.
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.
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.
@mpreisler I agree with you. I will remove all -t
. I will also try to remove other options if possible.
@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.
@jan-cerny Which options are you not sure about?
@mpreisler: --pid=host --env container=docker --net=host --cap-add=SYS_ADMIN
Yeah, we need all those for security compliance. So did you find options you can remove other than -t
?
@mpreisler No, I didn't.
Ok, let's close this then.
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