Problem : Docker-Container können nicht angehalten werden. Immer wenn ich versuche, Container zu stoppen, erhalte ich die folgende Fehlermeldung:
ERROR: for yattyadocker_web_1 cannot stop container: 1f04148910c5bac38983e6beb3f6da4c8be3f46ceeccdc8d7de0da9d2d76edd8: Cannot kill container 1f04148910c5bac38983e6beb3f6da4c8be3f46ceeccdc8d7de0da9d2d76edd8: rpc error: code = PermissionDenied desc = permission denied
OS-Version/build: Ubuntu 16.04 | Docker Version 17.09.0-ce, Build afdb6d4 | Docker Compose Version 1.17.1, Build 6d101fb
Schritte zum Reproduzieren:
docker build -t <project name> .
oder docker-compose up --build
erstellt.Was ich probiert habe: :
Sudo service docker restart
ausführen und dann können die Container entfernt werden. Hinweis : Diese Konfiguration hat früher richtig funktioniert, aber möglicherweise haben sich die Dateiberechtigungen geändert, und ich sehe diesen Fehler. Ich muss Sudo service docker restart
ausführen und dann können die Container entfernt werden. Dies ist jedoch äußerst unpraktisch und ich weiß nicht, wie ich das beheben kann.
Referenzdateien:
# docker-compose.yml
version: '3'
volumes:
db-data:
driver: local
redis-data:
driver: local
services:
db:
image: postgres:9.4.1
volumes:
- db-data:/var/lib/postgresql/data
ports:
- "5432:5432"
env_file: local_envs.env
web:
image: yattya_docker:latest
command: bundle exec puma -C config/puma.rb
tty: true
stdin_open: true
ports:
- "3000:3000"
links:
- db
- redis
- memcached
depends_on:
- db
- redis
- memcached
env_file: local_envs.env
redis:
image: redis:3.2.4-Alpine
ports:
# We'll bind our Host's port 6379 to redis's port 6379, so we can use
# Redis Desktop Manager (or other tools) with it:
- 6379:6379
volumes:
# We'll mount the 'redis-data' volume into the location redis stores it's data:
- redis-data:/var/lib/redis
command: redis-server --appendonly yes
memcached:
image: memcached:1.5-Alpine
ports:
- "11211:11211"
clock:
image: yattya_docker:latest
command: bundle exec clockwork lib/clock.rb
links:
- db
depends_on:
- db
env_file: local_envs.env
worker:
image: yattya_docker:latest
command: bundle exec rake jobs:work
links:
- db
depends_on:
- db
env_file: local_envs.env
Und Dockerfile:
# Dockerfile
FROM Ruby:2.4.1
RUN apt-get update && apt-get install -y nodejs --no-install-recommends && rm -rf /var/lib/apt/lists/*
ENV APP_HOME /app
RUN mkdir -p $APP_HOME
WORKDIR $APP_HOME
ADD Gemfile* $APP_HOME/
RUN bundle install
ADD . $APP_HOME
RUN mkdir -p ${APP_HOME}/log
RUN cat /dev/null > "$APP_HOME/log/development.log"
RUN mkdir -p ${APP_HOME}/tmp/cache \
&& mkdir -p ${APP_HOME}/tmp/pids \
&& mkdir -p ${APP_HOME}/tmp/sockets
EXPOSE 3000
Ich konnte das Problem beheben. Apparmor-Service in Ubuntu funktionierte aufgrund eines unbekannten Problems nicht normal. Das Problem ähnelte dem in moby project https://github.com/moby/moby/issues/20554 gemeldeten Problem.
Das /etc/apparmor.d/tunables
Ordner war leer, und https://github.com/mlaventure schlug vor, Apparmor zu bereinigen/neu zu installieren, um ihn in den Ausgangszustand zu versetzen.
Also habe ich apparmor neu installiert und nach dem Neustart das Problem behoben.
Hoffe das hilft.
Für alle, die AppArmor nicht vollständig löschen möchten.
Status überprüfen: Sudo aa-status
Fahren Sie herunter und verhindern Sie einen Neustart: Sudo systemctl disable apparmor.service --now
AppArmor-Profile entladen: Sudo service apparmor teardown
Status überprüfen: Sudo aa-status
Sie sollten jetzt Container stoppen/töten können.
Ich habe Docker aus dem Snap-Paket installiert und nach einer Weile beschlossen, mit der Repository-Installation von Apt fortzufahren.
Ich hatte das gleiche Problem und benutze Sudo aa-remove-unknown
hat für mich gearbeitet.
Daher war keine Neuinstallation von Apparmor erforderlich.
Eine direkte Lösung für das Problem ist das Ausführen von bash im Container, der beendet werden soll, und direkt kill
aufgerufen werden. Ein Beispiel:
Host$ docker exec -it <container-name> sh
container$ ps
PID USER TIME COMMAND
1 root 0:00 {entrypoint.sh} /bin/sh /entrypoint.sh
16 root 0:00 {entrypoint.sh} /bin/sh /entrypoint.sh
24 root 0:00 sh
31 root 0:00 ps
container$ kill 1
Um zu überprüfen, ob der Container beendet wurde, führen Sie docker ps
aus. Dies ist eine nützliche Alternative zum Lösungsinstallations-Apparmor, da hierdurch auch snapd entfernt wird.
In meinem Fall bestand das Problem darin, dass ich widersprüchliche Docker-Installationen hatte: docker
selbst aus dem offiziellen docker-ce
-Paket , aber docker-compose
aus dem Ubuntu-Snap-Paket.
Richtige Installation von docker-compose
vom offiziellen github ( Anweisungen hier ) hat den Trick ausgeführt. Ich habe auch die Anweisungen von Linux nach der Installation befolgt und es kann auch geholfen haben (Docker als Nicht-Root-Benutzer auszuführen).
Ich habe AppArmor hier allein gelassen - ich habe es nicht angefasst.