jaydubbyasee
commented
9 years ago I've been running into this as well. As an unsafe workaround, you can enable privileged mode.
Closed peterabbott closed 8 years ago
jaydubbyasee
commented
9 years ago I've been running into this as well. As an unsafe workaround, you can enable privileged mode.
steffengodskesen
commented
9 years ago I'm also running into this with some of our tests. Lately with the postfix init script from Debian wheezy which tries to read /proc/PID/exe.
Running the container in privileged mode sure works, but apart from the security issues with that, I often also run into this Docker behaviour: https://github.com/docker/docker/issues/4040 when doing that.
Being able to --cap-add=SYS_PTRACE would sure make my world a happier place.
peterabbott
commented
9 years ago Got tired of waiting for a response from repo owner so I have forked this and published a new driver with this fix included. When we do get a response I'll look at merging back.
New Gem: https://rubygems.org/gems/kitchen-docker_ssh
More notes: https://github.com/portertech/kitchen-docker/issues/112#issuecomment-87333727
miketheman
commented
8 years ago https://github.com/portertech/kitchen-docker/pull/105 has been emrged & released - recommend closure.
coderanger
commented
8 years ago Thanky!
In order to run some services, for example tomcat on ubuntu, a container requires the capability SYS_PTRACE, others the init.d daemon startup will fail.
Discovered this while writing some test kitchen serverspec tests and switched from vagrant to docker driver and the tests started failing.