どうやら私のハードドライブがいっぱいだったため、数分前にコンピューターがクラッシュしました。リカバリモードで起動した後、/ var/logのsyslogファイルが64GBであることがわかりました。ファイルの最後を別のパーティションに保存してから削除しました。どうやらdockerが問題だったようです。ファイルの最後でこれがたくさん見つかり、200%のCPUで常にdockerプロセスが実行されていたためです。ログをクリアしてDockerを終了すると、すべてが正常に見えます。
Nov 15 01:44:08 Elemental docker.dockerd[1120]:
time="2019-11-15T01:44:08.727060251Z" level=error
msg="failed to get event" error="rpc error: code =
Unavailable desc = all SubConns are in TransientFailure, latest connection
error: connection error: desc = \"transport: Error
while dialing dial unix /run/containerd/containerd.sock:
connect: permission denied\"" module=libcontainerd namespace=plugins.moby
Nov 15 01:44:08 Elemental docker.dockerd[1120]: time="2019-11-15T01:44:08.727116701Z"
...
等々。この問題が再発しないことを願っていますが、ここで何が起こったのかを知りたいのです。
Aptとsnapを同時に使用してdockerパッケージをインストールしました。したがって、この問題は、スナップパッケージシステムからdockerを削除することで修正されます。
# apt list --installed | grep docker
docker/bionic,now 1.5-1build1 AMD64 [installed]
docker-ce/bionic,now 5:19.03.5~3-0~ubuntu-bionic AMD64 [installed]
docker-ce-cli/bionic,now 5:19.03.5~3-0~ubuntu-bionic AMD64 [installed,automatic]
# snap list | grep docker
docker 18.09.9 418 stable canonical✓ -
# snap remove docker
docker removed
Cannonicalの誰かが数時間前に物事をねじ込みました-ランチパッドで追跡されています- https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/185272
私のシステムは昨日dockerのみでインストールされ、他の人たちと同じです-syslogはディスク上の空き領域全体を殺し、snapからdockerをパージするのを助けました。
複数のDockerサービスが実行されています。 dockerdが、containerdの別のインストール済みシステムにアクセスしようとしているようです。
私の場合、teamcityエージェントとDockerのインストールが競合していました。
Sudo apt-get purge docker-ce
Sudo apt autoremove
Sudo rm -rf /var/lib/docker
Sudo truncate -s 0 /var/log/syslog
上記のコマンドを実行して再起動しました。すべてうまくいった。
私にも起こりました。それが起こったのはスナップ更新だったのでしょうか。
ID Status Spawn Ready Summary
17 Done today at 00:34 UTC today at 00:34 UTC Auto-refresh snap "docker"
Ubuntuのdocker.ioパッケージをアンインストール+再インストールすると、この問題が発生しますが、何らかの理由で、Dockerのスナップもインストールしていたため、競合が発生しました。
Name Version Rev Tracking Publisher Notes
core 16-2.42.1 8039 stable canonical✓ core
docker 18.09.9 418 stable canonical✓ -
しかし、私が今までにdocker snapパッケージをインストールしたことを覚えていません...しかし、これは結局のところテストシステムであり、他の誰かがそれが良いアイデアだと思ったかもしれません...
私もこの問題に遭遇したので、他の人がここに迷い込んだ場合に備えて、私にとってうまくいった解決策を説明できます。私は最初にクリス・ソンの提案を試しましたが、それはうまくいきませんでした。
症状は次のとおりです。
200 +%CPUで実行されるdockerb、およびkillコマンドで常に再起動します
フィリップZが見たように、巨大なファイルがsyslogに入力されています。私が今朝来たとき、それは私のハードドライブ全体を700GBのファイルで満たしていました。
フリストが巨大なファイルを削除して、実際に作業できるようにします。再び満杯になりますが、少し時間がかかります。
Sudo truncate -s 0 /var/log/syslog
次に、スナップDockerインストールを削除します。これはdocker-ceではなく、私にとっての問題でした
Sudo snap stop docker
Sudo snap remove docker
必要かどうかはわかりませんが、先に進んでスナップも完全に削除しました
Sudo apt purge snap
上部にdockerbが表示されなくなります。次に、ログトランケータを再実行して、上記のコマンドの実行中に書き込まれたジャンクを削除できます。私のように台無しにしてsyslogを完全に削除した場合は、新しいsyslogに正しいアクセス許可を付与してください。
Sudo cd /var/log
Sudo touch syslog
Sudo chown syslog:adm syslog
Sudo service rsyslog restart
今夜からここでも同じ問題。
Dockerコンテナー(mosquitto/influxdb/grafana)は、それぞれのポートでアクセスできません。
--force
を使用するまで、コンテナを停止できません。
すべてのコンテナを強制停止しますが、各コンテナの再起動に関するメッセージは常に同じです:
"docker: Error response from daemon: all SubConns are in TransientFailure"
私は Silvioのパッケージ削除 を行いました。次に、Dockerデーモンを再起動するために、これらのコマンドをrootとして実行しました。
systemctl unmask docker.service
systemctl unmask docker.socket
systemctl start docker.service
service docker start
今は良いようです。 @Silvioに感謝します。
Ubuntuでスペース不足の警告を受けました。
スペースが足りないので、どの繰り返しログがめちゃくちゃ/ var/logになっているか分析できません
しかし、最新のログはあなたとまったく同じです。
どのプロセスがディスクに最も多く書き込むかを確認しようとしましたが、DockerのCPU%が250を超えていることがわかりました。
snap changes | grep docker
dockerスナップが単独でインストールされているようです
54 Done yesterday at 23:31 EST yesterday at 23:31 EST Auto-refresh snap "docker
Sudo snap remove docker --purge
dockerスナップを取り外し、すぐにスペースを解放する必要があります