web-dev-qa-db-ja.com

既存のPIDファイルのため、Dockerコンテナが起動しません

Dockerコンテナを起動すると、既存のpidファイルが原因で失敗します。

[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

見つからないので、このようなファイルを削除するにはどうすればよいですか。

[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
dockerpid
22
sebelk

試してください：

docker-compose down

既に実行中の環境を破棄するため。

29
styonsk

あまりにも多くのフラストレーションの後、私は壊れた薬用容器でこれを解決しました：

Http pidファイルの名前/パスが何であるかを知る必要があります。以下の例では、/run/Apache2/Apache2.pidコンテナ内。それができたら、次を実行します。

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

これが行うことは、コンテナを起動し、すぐにコマンドを実行してPIDファイルを削除しようとすることです。コンテナプロセスがすぐに失敗した場合、これはうまくいかない可能性があります。それを数回実行してみてください、あなたはパンチに打ち勝つかもしれません。

私のPIDファイルの場所を見つけるために、@ sebelkに似た何かをしましたが、tarファイルを展開する代わりに、その内容をリストして正しいファイル名を探すことで時間を節約しました...のように：

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

これはばかげています。おそらく、コンテナの内容を調べるのにもっと良い方法があります。理想的には、他の方法でPIDファイルの名前を見つけることができます（コメントを歓迎します！）。

悟り

上記の答えは有用ですが、私とここにいる他の多くの人がDockerを根本的なレベルで誤解していることに気付きました。実際、以下の@styonskのダウン投票された答えは正しいものです。そして、@ avijendrのそれに対する批判的なコメントも正しいです。それはコンテナ内のデータを破壊しますが、それは問題ではありません。説明します。

私はもともと、Dockerは「chrootのようだが優れている」と言われました。それは真実ですが、誤解を招きます。 chroot刑務所では、あなたのデータは刑務所の中に住んでいます（もちろん、刑務所に入れられたプロセスは他にどのようにそれを見るでしょうか？）。そのため、Dockerの使用を開始したとき、ボリューム機能はコンテナ内のデータを取得する方法であり、ローカルシステムにボリュームをマウントして、その内容を確認できると考えました。それを試してみると、コンテナがすべてのデータを失ったかのように、コンテナアプリがそのように動作し、ローカルのマウントされた場所には何もなかったので、本当に気が狂いました！間違って間違って間違って。

Dockerのボリュームは、ローカルデータ/ファイルをコンテナーにマウントしますが、その逆ではありません。そのため、ボリュームを空のローカルディレクトリにマウントすると（コンテナ内のファイルが表示されると予想される）、代わりに空のローカルディレクトリがコンテナにマウントされ、コンテナ内に存在するファイルが非表示になり、アプリがそのように見えますデータを失いました（それはhadであるため）。実際には、ボリュームがマウントされていなくてもDockerコンテナが機能するという事実は副作用であり、ほぼ間違いなく有害なものです。それが機能することを意図した方法ではありません。コンテナ内のボリュームの場所に書き込まれるデータはすべて、使い捨てであることが期待されています！

（ちなみに、私はKitematicを介してDockerを使い始めました。これは、1ステップでコンテナをプル、作成、およびstartしますボリュームをマウントする場所を尋ねることなく私が思うに間違った考えを与えたものの...私は個人的に、ボリュームをどこかにマウントするか、そうしないことを明示的に決定するまで、コンテナを開始すべきではないと考えています）

そのため、Dockerコンテナの使用目的は、通常、アプリケーション内部に作用するコンテナ外部のデータコンテナ、つまりボリューム内のローカルシステムにマウントされます。つまり、should何か問題が発生した場合にコンテナを破棄し、同じボリュームにマウントされた別のコピーを開始できることを意味します-コンテナ内にないため、すべてのデータを取得できますそもそも。

したがって、@ styonskの答えは正しい答えです。Dockerを正しく使用している場合、コンテナを破棄して新しいコンテナを起動することができます。一方ではこれはやり過ぎのように聞こえますが、他方では、コンテナ化されたアプリケーションのポイントは、内部で何が起こっているのかを知る必要がないということです。クリーンシャットダウン後に壊れたのは、httpd.pidファイルがまだ残っていることです。あなたが知らないもっとめちゃくちゃになるかもしれません！それはほぼ間違いなく抽象化の目的です。

そのモデルがユースケースで機能しない場合（または単に気に入らない場合）、答えはおそらくDockerコンテナーを使用すべきではないということです。それも悪いことではありません、それはあなたがプラスドライバーで皿ネジを入れようとしているかもしれないということです。代わりに軽量でフルスタックのVM環境が必要な場合があります。

20
S'pht'Kr

再構築/再作成が役立つ場合があります。 docker-compose up --build --force-recreate <service-name>

また、ホスト（物理サーバー）にディスク容量が残っていない可能性があります。

5
luckydonald

コンテナを破壊する必要はありません。コンテナを適切に停止しなかったため、まだ断片がぶら下がっています。具体的には、ネットワークはまだコンテナに接続されています。

試してください：docker network list

次のように表示されます。

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

その後、あなたがする必要があるのは、切断するだけです：

docker network disconnect folderNameOfContainer_default my_container_name

docker-compose downも同様ですが、厳密に言うと必要ではありません。

0
jonlink

ポールのコメントとドッカーのドキュメントに基づいて、私は解決策を見つけました：

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

その後、いくつかのマイナーな修正を実行し、/ var/run/httpd上の一時ファイルを削除し、変更をコミットする必要があります。その後、コンテナーを再度起動できます。

詳細は https://docs.docker.com/reference/commandline/cli/#importDockerコマンドライン

0
sebelk

どういうわけかダウンだけは私のために働いていません。私にとってこれまでの最善の解決策は、次のようなbashファイルを作成することでした。自分で何度もテストし、必要なハックを行いました。

#!/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
0
Abhijit Gujar