run - env file docker

el contenedor de la ventana acoplable no se iniciará porque un archivo pid existente

Question

Cuando inicio un contenedor docker falla porque un archivo pid existente:

[root@newhope sergio]# docker logs sharp_shockley 
httpd (pid 1) already running
httpd (pid 1) already running
httpd (pid 1) already running
httpd (pid 1) already running

¿Cómo puedo eliminar un archivo de este tipo, porque no lo encuentro.

[root@newhope sergio]# docker version
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8/1.4.1
OS/Arch (client): linux/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8/1.4.1

[root@newhope sergio]# find / -name "httpd.pid"
find: ‘/run/user/1000/gvfs’: Permiso denegado

Answer 1

Basándome en el comentario de Paul y en la documentación de la ventana acoplable, he encontrado la solución:

docker export sharp_shockley > /tmp/sharp_shockley.tar
mkdir /tmp/sharp_shockley
cd /tmp/sharp_shockley/
tar xvf sharp_shockley.tar
rm run/httpd/httpd.pid
rm sharp_shockley.tar
tar -c . | sudo docker import - apache3

Luego tengo que realizar algunos arreglos menores, eliminar archivos temporales en / var / run / httpd, confirmar los cambios y luego volver a comenzar mi contenedor.

Más información en https://docs.docker.com/reference/commandline/cli/#import https://docs.docker.com/reference/commandline/cli/#import

Answer 2

De alguna manera solo el down no me funcionó. La mejor solución para mí hasta ahora fue hacer un archivo bash como se muestra a continuación. Probado muchas veces yo mismo hice el hack necesario.

#!/usr/bin/env bash
# chmod +x start_dockers.sh
# ./start_dockers.sh

sudo docker-compose down

#stop all containers
sudo docker stop $(docker ps -aq)

sudo docker-compose up --build

Answer 3

Después de demasiada frustración, resolví esto en mi contenedor de fabrica roto:

Debe saber cuál es el nombre / ruta al archivo http pid. En el siguiente ejemplo, se encuentra en /run/apache2/apache2.pid dentro del contenedor. Una vez que tienes eso, ejecuta lo siguiente:

docker start [container_id]; docker exec [container_id] rm /run/apache2/apache2.pid

Lo que esto hace es iniciar el contenedor e inmediatamente intenta ejecutar el comando para eliminar el archivo PID; es de esperar que, antes de que se inicie el proceso, la ventana acoplable tenga tiempo de fallar. Si su proceso de contenedor falla rápidamente, esto podría no funcionar para usted. Intenta ejecutarlo un par de veces y podrías vencerlo.

Para encontrar la ubicación de mi archivo PID, hice algo similar a @sebelk, pero en lugar de expandir el archivo tar, ahorré algo de tiempo al simplemente enumerar su contenido y buscar el nombre de archivo correcto ... así:

docker export [container_id] > /tmp/brokecontainercontents.tar
tar -tf /tmp/brokecontainercontents.tar | less 

Esto es una tontería, y probablemente hay una manera mucho mejor de mirar a través del contenido del contenedor. Idealmente, puede encontrar el nombre del archivo PID de otra manera (¡bienvenidos los comentarios!).

Epifanía

La respuesta anterior es útil, pero ahora me doy cuenta de que yo y muchos otros aquí hemos malentendido a Docker en un nivel fundamental. De hecho, la respuesta de @styonsk a la baja es la correcta. Y, el comentario crítico de @ avijendr también es correcto: destruirá los datos en el contenedor, pero no debería importar. Lo explicaré.

Originalmente me dijeron que Docker era "como chroot pero mejor". Eso es cierto pero engañoso. En una cárcel chroot, sus datos viven dentro de la cárcel (por supuesto que sí, ¿de qué otra manera lo vería el proceso encarcelado?). Entonces, cuando comencé a usar Docker, pensé que la función Volúmenes era una forma de obtener los datos en el contenedor, que podía montar el Volumen en su sistema local y ver qué contenía. Cuando lo intenté, realmente me enojé porque era como si el contenedor PIERRÍA todos mis datos: la aplicación del contenedor actuó de esa manera, ¡y no había nada en la ubicación local montada! Mal equivocado mal

Los volúmenes en Docker montan sus datos / archivos locales en el contenedor, no al revés. Entonces, cuando monté el volumen en un directorio local vacío (esperando que aparecieran los archivos en el contenedor), en su lugar, el directorio local vacío se montó en el contenedor, ocultando los archivos que existían en el contenedor y haciendo que la aplicación pareciera que tenía Perdió sus datos (bueno, porque los tenía ). En realidad, el hecho de que el contenedor Docker incluso funcione sin un Volumen montado es un efecto secundario, y podría decirse que es perjudicial. Esa no es la forma en que se pretende que funcione. ¡Se espera que todos los datos que se escriban en la ubicación del Volumen dentro del contenedor sean desechables!

(Por cierto, comencé a usar Docker a través de Kitematic, que extraerá, creará e iniciará un contenedor en un solo paso sin preguntarte dónde quieres montar tus volúmenes , que es parte de lo que me dio la idea equivocada, creo ... ahora personalmente crea que no debe iniciar el contenedor hasta que haya montado los Volúmenes en algún lugar o haya decidido explícitamente no hacerlo.)

Por lo tanto, el uso previsto de un contenedor Docker suele ser (y debería) ejecutar la aplicación dentro del contenedor que actúa sobre los datos fuera del contenedor, es decir, en los Volúmenes que se montan en su sistema local. Eso significa que debería poder simplemente destruir el contenedor si algo va mal con él e iniciar otra copia montada en los mismos Volúmenes; usted recupera todos sus datos porque, en primer lugar, no estaba en el contenedor.

Por lo tanto, la respuesta de @styonsk es la correcta: si está utilizando Docker correctamente, debería poder destruir el contenedor y encender uno nuevo. Por un lado, esto suena como una exageración, pero por otro lado, el objetivo de la aplicación en contenedores es que no tiene que saber qué está sucediendo en su interior y, posiblemente, no ... ¿cómo sabe el único? ¿La cosa rota después de un cierre impuro es que el archivo httpd.pid todavía está allí? ¡Podría haber muchas más cosas que no sabes! Eso es discutible para lo que es la abstracción.

Si ese modelo no funciona para su caso de uso, o simplemente no le gusta, la respuesta probablemente sea que no debería usar un contenedor Docker. Eso tampoco es algo malo, es solo que puedes estar tratando de poner un tornillo de cabeza plana con un controlador Phillips. Es posible que solo necesite un entorno VM ligero pero de pila completa.

Answer 4

La reconstrucción / recreación podría ayudar. docker-compose up --build --force-recreate <service-name>

Además, es posible que al host (servidor físico) no le quede espacio en el disco.

Answer 5

No deberías tener que destruir el contenedor. Ya que no detuviste correctamente el contenedor, todavía hay piezas colgando. Específicamente, la red todavía está conectada al contenedor.

prueba: docker network list

Verás algo como:

NETWORK ID          NAME                             DRIVER              SCOPE
3d8f4b8ce4e5        bridge                           bridge              local
5ec8cb6bbe44        folderNameOfContainer_default    bridge              local
2503d2978229        host                             host                local

Entonces todo lo que necesitas hacer es desconectar:

docker network disconnect folderNameOfContainer_default my_container_name

También está bien docker-compose down , pero estrictamente hablando no es necesario.

Answer 6

Tratar:

docker-compose down

Para destruir cualquier entorno que ya se esté ejecutando.