「Dockerトラブルシューティング」の版間の差分

提供: Eospedia
移動: 案内検索
(CMD ["/usr/sbin/sshd", "-D"] してるのにコンテナ立ち上げてもすぐExitしてしまうんだけど)
 
行1: 行1:
== rootユーザーだとGPU使えるけどノーマルユーザーだとGPU使えない ==
+
= '''ホストマシンデバイス関連''' =
=== <u>症状</u> ===
+
== コンテナ内でノーマルユーザーだとGPUが使えない ==
 +
===症状===
 
rootユーザー
 
rootユーザー
 
<pre>
 
<pre>
行35: 行36:
 
</pre>
 
</pre>
  
 +
===原因===
 +
ホストマシンにVirtualGLをインストールしてあり、インストール時の設定でGPUデバイスの所有者グループがvglusersに書き換えられていたため。
  
全くわからん
+
===対処===
 
+
コンテナ内で vglusers というグループを作り、ノーマルユーザーをvglusersに追加すれば、GPUデバイスを使えるようになった。
Ubuntu14.04でDocker動かしてた頃は特に問題起きなかったんだが、てことはホスト側の問題?
+
 
+
 
+
===<u>対処</u>===
+
まさかのVirtualGLのせいだった。GPUデバイスの所有者グループがvglusersに書き換えられる問題。→ [[NVIDIA Dockerのインストール]] の下の方。問題児か。(アップグレード前のホストマシンUbuntu 14.04時代はまだVirtualGL入れてなかったので、それで問題が起きなかった)
+
 
+
対処策
+
 
<pre>
 
<pre>
 
(contianer) $ sudo groupadd -g <ホストマシンにおけるvglusersのGID> vglusers
 
(contianer) $ sudo groupadd -g <ホストマシンにおけるvglusersのGID> vglusers
行50: 行46:
 
</pre>
 
</pre>
  
 +
あるいは、ホストマシンでVirtualGLをアンインストールするか。(所有グループがrootに戻るか要確認)
  
vgl厄介だな。。
+
= '''Dockerfile関連''' =
 +
== CMD ["/usr/sbin/sshd", "-D"] を入れても外からsshアクセスできない ==
 +
===症状===
 +
Dockerfileの最後に
 +
<pre>
 +
CMD ["/usr/sbin/sshd", "-D"]
 +
</pre>
 +
を書いて、コンテナを -d オプション付きで立ち上げれば外からsshアクセスできると思ったが、できない。
  
 +
===原因===
 +
ビルドしてrunしたコンテナのログを確認すると
 +
<pre>
 +
$ docker logs upbeat_liskov  # upbeat_liskovはコンテナの名前
  
 +
Missing privilege separation directory: /var/run/sshd
 +
</pre>
  
== CMD ["/usr/sbin/sshd", "-D"] してるのにコンテナ立ち上げてもすぐExitしてしまうんだけど==
+
/var/run/sshdというディレクトリをあらかじめ作っておかないといけないらしい。
なんで? ネットの情報だと run -d でsshアクセス可能な状態になってくれる感じなんだがそうならない
+
  
* https://stackoverflow.com/questions/54024367/docker-container-exiting-immediately-if-run-as-non-root-user
+
===対処===
* https://github.com/ansible/ansible-container/issues/141
+
Dockerfileに、sshdのコマンドを走らせる前に
 +
<pre>
 +
RUN mkdir -p /var/run/sshd
 +
</pre>
 +
を書き加えて再ビルドしたら大丈夫になった。
  
 +
= '''ネットワーク関係''' =
 +
== マシンを再起動したらswarm(overlayネットワーク)が機能しなくなった ==
 +
=== 症状 ===
 +
あるoverlayネットワークに参加しているコンテナがswarmワーカーノード上にあって、計算機の再起動後にdocker startでコンテナ再起動しようとしたところ、以下のようなエラーが出て再起動してくれなかった。
 
<pre>
 
<pre>
$ docker logs upbeat_liskov
+
Error response from daemon: Could not attach to network asuaxn22bff1sq8pqqay2sg64: context deadline exceeded
 +
Error: failed to start containers: <コンテナ名>
 +
</pre>
  
Missing privilege separation directory: /var/run/sshd
+
swarmのマスターノードで docker node ls すると、ワーカーノードのSTATUSが軒並み Down となっていた。
 +
 
 +
=== 原因 ===
 +
推測。
 +
 
 +
swarm通信用のポートはfirewall-cmdで開けるが、--permanentオプションを付けて実行しないと、計算機再起動した際に設定が消えるらしい。上記問題が出た環境は--permanetを付けずにポートを開いていたので、それゆえ再起動した後にポートが閉じてしまってswarm通信ができず、各ノードのSTATUSがDownとなっていたと考えられる。(実際に検証する前にネットワーク設定を消してしまったので検証はできていない)
 +
 
 +
=== 対処 ===
 +
推測。
 +
 
 +
--permanentオプションをつけてfirewall-cmdでポートを改めて開ける。
 +
<pre>
 +
> sudo firewall-cmd --zone=public --add-port=2377/tcp --add-port=7946/tcp --add-port=7946/udp --add-port=4789/udp --permanent
 +
> sudo systemctl restart firewalld.service
 
</pre>
 
</pre>
  
 +
= '''Dockerデーモンのエラー''' =
 +
== /var/lib/docker が read-only file system のため操作不能 ==
 +
=== 症状 ===
 +
swarmに参加しようとすると、以下エラー
 +
* Error response from daemon: unlinkat /var/lib/docker/swarm/certificates: read-only file system
  
/var/run/sshdというディレクトリをあらかじめ作っておかないといけないらしい
+
コンテナを削除しようとすると、以下エラー
 +
* Error response from daemon: container 36060bd231466311ebcbbcbe1a44e25d76e37b43f77b76d2b6f284d8bd8ae157: driver "aufs" failed to remove root filesystem: error removing layers dir for aefdacf5ed56d31750ee2b73381bf0aa24afe93f91d15a7a89a2dbda90b5489f: remove /var/lib/docker/aufs/layers/aefdacf5ed56d31750ee2b73381bf0aa24afe93f91d15a7a89a2dbda90b5489f: read-only file system
 +
 
 +
デーモンを再起動しようとすると、
 +
* Error response from daemon: container 36060bd231466311ebcbbcbe1a44e25d76e37b43f77b76d2b6f284d8bd8ae157: driver "aufs" failed to remove root filesystem: error removing layers dir for aefdacf5ed56d31750ee2b73381bf0aa24afe93f91d15a7a89a2dbda90b5489f: remove /var/lib/docker/aufs/layers/aefdacf5ed56d31750ee2b73381bf0aa24afe93f91d15a7a89a2dbda90b5489f: read-only file system
 +
 
 +
しまいにはdocker psすると
 +
* Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
 +
 
 +
=== 原因 ===
 +
* https://github.com/moby/moby/issues/18010
 +
 
 +
/var/run/docker.sockを載せているファイルシステムに障害が発生して、OSが保護のためにread-onlyでマウントしなおしたのでは、という議論があり、その線で調べてみた。
 +
 
 +
実際、rootユーザーでも本来書き込めるはずの場所にファイル作成などができなくなっている。
 +
 
 +
また、dmesgを確認すると以下のような記述がある。
 +
<pre>
 +
[  375.096148] ata5.00: exception Emask 0x0 SAct 0x4 SErr 0x0 action 0x0
 +
[  375.096195] ata5.00: irq_stat 0x40000008
 +
[  375.096235] ata5.00: failed command: READ FPDMA QUEUED
 +
[  375.096279] ata5.00: cmd 60/08:10:28:47:c6/00:00:03:00:00/40 tag 2 ncq 4096 in
 +
                        res 41/40:08:28:47:c6/00:00:03:00:00/40 Emask 0x409 (media error) <F>
 +
[  375.096334] ata5.00: status: { DRDY ERR }
 +
[  375.096374] ata5.00: error: { UNC }
 +
[  375.096977] ata5.00: configured for UDMA/133
 +
[  375.096990] sd 4:0:0:0: [sda] tag#2 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
 +
[  375.096994] sd 4:0:0:0: [sda] tag#2 Sense Key : Medium Error [current] [descriptor]
 +
[  375.096998] sd 4:0:0:0: [sda] tag#2 Add. Sense: Unrecovered read error - auto reallocate failed
 +
[  375.097003] sd 4:0:0:0: [sda] tag#2 CDB: Read(10) 28 00 03 c6 47 28 00 00 08 00
 +
[  375.097006] blk_update_request: I/O error, dev sda, sector 63325992
 +
[  375.097058] ata5: EH complete
 +
[  375.097063] EXT4-fs error (device sda1): ext4_find_entry:1456: inode #2081132: comm updatedb.mlocat: reading directory lblock 0
 +
[  375.267568] Aborting journal on device sda1-8.
 +
[  375.995157] EXT4-fs error (device sda1): ext4_journal_check_start:56:
 +
[  375.995165] EXT4-fs (sda1): Remounting filesystem read-only
 +
[  375.995248] Detected aborted journal
 +
</pre>
  
→ Dockerfileに RUN mkdir -p /var/run/sshd 加えて再ビルドしたら大丈夫になった。
+
=== 対処 ===
 +
対処中

2020年11月17日 (火) 22:32時点における最新版

ホストマシンデバイス関連

コンテナ内でノーマルユーザーだとGPUが使えない

症状

rootユーザー

(host)$ docker exec -it relion-docker bash

(container)[root@relion-docker softwares]# nvidia-smi
Sat May 18 09:35:06 2019
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 418.74       Driver Version: 418.74       CUDA Version: 10.1     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 1080    Off  | 00000000:05:00.0  On |                  N/A |
| 29%   44C    P8     7W / 180W |     72MiB /  8119MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
|   1  GeForce GTX 1080    Off  | 00000000:06:00.0 Off |                  N/A |
| 27%   41C    P8     6W / 180W |      2MiB /  8119MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
|   2  GeForce GTX 1080    Off  | 00000000:09:00.0 Off |                  N/A |
| 27%   37C    P8     6W / 180W |      2MiB /  8119MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
|   3  GeForce GTX 1080    Off  | 00000000:0A:00.0 Off |                  N/A |
| 27%   37C    P8     6W / 180W |      2MiB /  8119MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

ノーマルユーザー(Dockerイメージビルド時に作成済みのユーザー)

(host)$ docker exec -u kttn -it relion-docker bash

(container)[kttn@relion-docker ~]$ nvidia-smi
Failed to initialize NVML: Insufficient Permissions

原因

ホストマシンにVirtualGLをインストールしてあり、インストール時の設定でGPUデバイスの所有者グループがvglusersに書き換えられていたため。

対処

コンテナ内で vglusers というグループを作り、ノーマルユーザーをvglusersに追加すれば、GPUデバイスを使えるようになった。

(contianer) $ sudo groupadd -g <ホストマシンにおけるvglusersのGID> vglusers
(contianer) $ sudo usermod -aG vglusers <non-rootユーザーのユーザー名>

あるいは、ホストマシンでVirtualGLをアンインストールするか。(所有グループがrootに戻るか要確認)

Dockerfile関連

CMD ["/usr/sbin/sshd", "-D"] を入れても外からsshアクセスできない

症状

Dockerfileの最後に

CMD ["/usr/sbin/sshd", "-D"]

を書いて、コンテナを -d オプション付きで立ち上げれば外からsshアクセスできると思ったが、できない。

原因

ビルドしてrunしたコンテナのログを確認すると

$ docker logs upbeat_liskov  # upbeat_liskovはコンテナの名前

Missing privilege separation directory: /var/run/sshd

/var/run/sshdというディレクトリをあらかじめ作っておかないといけないらしい。

対処

Dockerfileに、sshdのコマンドを走らせる前に

RUN mkdir -p /var/run/sshd

を書き加えて再ビルドしたら大丈夫になった。

ネットワーク関係

マシンを再起動したらswarm(overlayネットワーク)が機能しなくなった

症状

あるoverlayネットワークに参加しているコンテナがswarmワーカーノード上にあって、計算機の再起動後にdocker startでコンテナ再起動しようとしたところ、以下のようなエラーが出て再起動してくれなかった。

Error response from daemon: Could not attach to network asuaxn22bff1sq8pqqay2sg64: context deadline exceeded
Error: failed to start containers: <コンテナ名>

swarmのマスターノードで docker node ls すると、ワーカーノードのSTATUSが軒並み Down となっていた。

原因

推測。

swarm通信用のポートはfirewall-cmdで開けるが、--permanentオプションを付けて実行しないと、計算機再起動した際に設定が消えるらしい。上記問題が出た環境は--permanetを付けずにポートを開いていたので、それゆえ再起動した後にポートが閉じてしまってswarm通信ができず、各ノードのSTATUSがDownとなっていたと考えられる。(実際に検証する前にネットワーク設定を消してしまったので検証はできていない)

対処

推測。

--permanentオプションをつけてfirewall-cmdでポートを改めて開ける。

> sudo firewall-cmd --zone=public --add-port=2377/tcp --add-port=7946/tcp --add-port=7946/udp --add-port=4789/udp --permanent
> sudo systemctl restart firewalld.service

Dockerデーモンのエラー

/var/lib/docker が read-only file system のため操作不能

症状

swarmに参加しようとすると、以下エラー

  • Error response from daemon: unlinkat /var/lib/docker/swarm/certificates: read-only file system

コンテナを削除しようとすると、以下エラー

  • Error response from daemon: container 36060bd231466311ebcbbcbe1a44e25d76e37b43f77b76d2b6f284d8bd8ae157: driver "aufs" failed to remove root filesystem: error removing layers dir for aefdacf5ed56d31750ee2b73381bf0aa24afe93f91d15a7a89a2dbda90b5489f: remove /var/lib/docker/aufs/layers/aefdacf5ed56d31750ee2b73381bf0aa24afe93f91d15a7a89a2dbda90b5489f: read-only file system

デーモンを再起動しようとすると、

  • Error response from daemon: container 36060bd231466311ebcbbcbe1a44e25d76e37b43f77b76d2b6f284d8bd8ae157: driver "aufs" failed to remove root filesystem: error removing layers dir for aefdacf5ed56d31750ee2b73381bf0aa24afe93f91d15a7a89a2dbda90b5489f: remove /var/lib/docker/aufs/layers/aefdacf5ed56d31750ee2b73381bf0aa24afe93f91d15a7a89a2dbda90b5489f: read-only file system

しまいにはdocker psすると

  • Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

原因

/var/run/docker.sockを載せているファイルシステムに障害が発生して、OSが保護のためにread-onlyでマウントしなおしたのでは、という議論があり、その線で調べてみた。

実際、rootユーザーでも本来書き込めるはずの場所にファイル作成などができなくなっている。

また、dmesgを確認すると以下のような記述がある。

[  375.096148] ata5.00: exception Emask 0x0 SAct 0x4 SErr 0x0 action 0x0
[  375.096195] ata5.00: irq_stat 0x40000008
[  375.096235] ata5.00: failed command: READ FPDMA QUEUED
[  375.096279] ata5.00: cmd 60/08:10:28:47:c6/00:00:03:00:00/40 tag 2 ncq 4096 in
                        res 41/40:08:28:47:c6/00:00:03:00:00/40 Emask 0x409 (media error) <F>
[  375.096334] ata5.00: status: { DRDY ERR }
[  375.096374] ata5.00: error: { UNC }
[  375.096977] ata5.00: configured for UDMA/133
[  375.096990] sd 4:0:0:0: [sda] tag#2 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  375.096994] sd 4:0:0:0: [sda] tag#2 Sense Key : Medium Error [current] [descriptor] 
[  375.096998] sd 4:0:0:0: [sda] tag#2 Add. Sense: Unrecovered read error - auto reallocate failed
[  375.097003] sd 4:0:0:0: [sda] tag#2 CDB: Read(10) 28 00 03 c6 47 28 00 00 08 00
[  375.097006] blk_update_request: I/O error, dev sda, sector 63325992
[  375.097058] ata5: EH complete
[  375.097063] EXT4-fs error (device sda1): ext4_find_entry:1456: inode #2081132: comm updatedb.mlocat: reading directory lblock 0
[  375.267568] Aborting journal on device sda1-8.
[  375.995157] EXT4-fs error (device sda1): ext4_journal_check_start:56: 
[  375.995165] EXT4-fs (sda1): Remounting filesystem read-only
[  375.995248] Detected aborted journal

対処

対処中