le conteneur Docker ne démarre pas car un fichier pid existant
Lorsque je démarre un conteneur Docker, il échoue car un fichier pid existant:
[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
Comment puis-je supprimer un tel fichier, car je ne le trouve pas.
[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
Essayer:
docker-compose down
Pour détruire tous les environnements en cours d'exécution.
Après beaucoup trop de frustration, j'ai résolu ceci dans mon conteneur de phabricator cassé:
Vous devez savoir quel est le nom/chemin du fichier pid http. Dans l'exemple ci-dessous, il se trouve à /run/Apache2/Apache2.pid à l'intérieur du conteneur. Une fois que vous avez cela, vous lancez ce qui suit:
docker start [container_id]; docker exec [container_id] rm /run/Apache2/Apache2.pid
Cela permet de démarrer le conteneur, puis d'essayer immédiatement d'exécuter la commande pour supprimer le fichier PID, en espérant que le temps que le dockeur de processus soit censé démarrer ait le temps d'échouer. Si votre processus de conteneur échoue rapidement, cela pourrait ne pas fonctionner pour vous. Essayez de l'exécuter plusieurs fois et vous pourriez le battre au poing.
Pour trouver l'emplacement de mon fichier PID, j'ai fait quelque chose de similaire à @sebelk, mais au lieu de développer le fichier tar, j'ai gagné du temps en listant simplement son contenu et en recherchant le bon nom de fichier ... comme ceci:
docker export [container_id] > /tmp/brokecontainercontents.tar
tar -tf /tmp/brokecontainercontents.tar | less
C'est idiot, et il y a probablement une bien meilleure façon de regarder à travers le contenu du conteneur. Idéalement, vous pouvez trouver le nom du fichier PID d'une autre manière (commentaires bienvenus!).
Épiphanie
La réponse ci-dessus est utile, mais je réalise maintenant que Docker et moi-même avons mal compris à un niveau fondamental. En fait, la réponse ci-dessous de @ styonsk est la bonne. Et le commentaire critique de @ avijendr à ce sujet est également correct: cela détruira des données dans le conteneur - mais cela ne devrait pas avoir d'importance. Je vais t'expliquer.
On m'avait dit à l'origine que Docker était "comme un chroot mais meilleur" C'est la vérité mais trompeuse. Dans une prison chroot, vos données sont stockées à l'intérieur de la prison (bien sûr, comment le processus en prison le verrait-il autrement?). Ainsi, lorsque j'ai commencé à utiliser Docker, je pensais que la fonctionnalité Volumes était un moyen d'obtenir des données dans le conteneur: vous pouviez monter le volume sur votre système local et voir ce qu'il contenait. Lorsque j’ai essayé, j’ai vraiment eu peur parce que c’était comme si le conteneur LOSS avait perdu toutes mes données - l’application Conteneur agissait de la sorte et il n’y avait rien dans l’emplacement monté local! Faux Faux Faux.
Les volumes dans Docker montent vos données/fichiers locaux dans le conteneur, et non l'inverse. Ainsi, lorsque j'ai monté le volume dans un répertoire local vide (en espérant que les fichiers du conteneur apparaissent), le répertoire local vide a été monté dans le conteneur, masquant les fichiers qui existaient dans le conteneur et donnant à l'application le même aspect. perdu ses données (enfin, car il avait ). En réalité, le fait que le conteneur Docker fonctionne même sans Volume monté est un effet secondaire, et peut-être même nocif. Ce n'est pas la façon dont il est destiné à fonctionner. Toutes les données écrites à l'emplacement du volume dans le conteneur devraient être jetables!
(Incidemment, j'ai commencé à utiliser Docker via Kitematic, qui extrait, crée et démarre un conteneur en une étape sans vous demander où vous voulez monter vos volumes , ce qui explique en partie ce qui m'a mal donné. idée, je pense ... Je pense personnellement que le conteneur ne doit pas être démarré tant que vous n'avez pas monté les volumes quelque part ou décidé explicitement de ne pas le faire.)
Par conséquent, l’utilisation prévue d’un conteneur Docker est généralement (et devrait être) d’exécuter l’application application inside le conteneur qui agit sur les données externes le conteneur, c’est-à-dire dans les volumes montés sur votre disque système. Cela signifie que vous devriez pouvoir simplement détruire le conteneur si quelque chose ne va pas et commencer une autre copie montée sur les mêmes volumes - vous récupérez toutes vos données car elles ne figuraient pas dans le conteneur dans le premier endroit.
Par conséquent, la réponse de @ styonsk est la bonne: si vous utilisez Docker correctement, vous devriez être capable de détruire le conteneur et d’en lancer un nouveau. D'une part, cela ressemble à une surdose, mais d'un autre côté, le but de l'application conteneurisée est que vous ne devez pas savoir ce qui se passe à l'intérieur de celle-ci et que vous ne le savez peut-être pas ... comment connaître le seul chose cassée après un arrêt impur est que le fichier httpd.pid est toujours là? Il pourrait y avoir beaucoup plus de dégâts que vous ne connaissez pas! C'est sans doute ce que l'abstraction est pour.
Si ce modèle ne fonctionne pas pour votre cas d'utilisation - ou si vous ne l'aimez tout simplement pas -, la réponse est probablement que vous ne devriez pas utiliser un conteneur Docker. Ce n'est pas une mauvaise chose non plus, c'est simplement que vous essayez peut-être de mettre une vis à tête plate avec un tournevis Phillips. Vous aurez peut-être simplement besoin d'un environnement VM léger mais à pile complète.
Reconstruire/recréer pourrait aider. docker-compose up --build --force-recreate <service-name>
En outre, l'hôte (serveur physique) peut ne plus avoir d'espace disque.
Vous ne devriez pas avoir besoin de détruire le conteneur. Puisque vous n'avez pas correctement arrêté le conteneur, il reste encore des morceaux. Plus précisément, le réseau est toujours connecté au conteneur.
essayez: docker network list
Vous verrez quelque chose comme:
NETWORK ID NAME DRIVER SCOPE
3d8f4b8ce4e5 bridge bridge local
5ec8cb6bbe44 folderNameOfContainer_default bridge local
2503d2978229 Host Host local
Ensuite, tout ce que vous avez à faire est de vous déconnecter:
docker network disconnect folderNameOfContainer_default my_container_name
docker-compose down convient également, mais à proprement parler, cela n'est pas nécessaire.
Sur la base des commentaires de Paul et de la documentation de docker, j'ai trouvé la solution:
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
Ensuite, je dois effectuer des corrections mineures, supprimer des fichiers temporaires sur/var/run/httpd, valider les modifications et pouvoir ensuite redémarrer mon conteneur.
Plus d'informations sur https://docs.docker.com/reference/commandline/cli/#importLigne de commande Docker
d'une manière ou d'une autre, le duvet ne fonctionne pas pour moi. La meilleure solution pour moi jusqu’à présent était de créer un fichier bash comme indiqué ci-dessous. testé plusieurs fois moi-même, il a fait le bidouillage nécessaire.
#!/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