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

提供: Eospedia
移動: 案内検索
(rootユーザーだとGPU使えるけどノーマルユーザーだとGPU使えない)
 
(同じ利用者による、間の5版が非表示)
行1: 行1:
== rootユーザーだとGPU使えるけどノーマルユーザーだとGPU使えない ==
+
= '''ホストマシンデバイス関連''' =
 +
== コンテナ内でノーマルユーザーだとGPUが使えない ==
 +
===症状===
 
rootユーザー
 
rootユーザー
 
<pre>
 
<pre>
 
(host)$ docker exec -it relion-docker bash
 
(host)$ docker exec -it relion-docker bash
  
(docker)[root@relion-docker softwares]# nvidia-smi
+
(container)[root@relion-docker softwares]# nvidia-smi
 
Sat May 18 09:35:06 2019
 
Sat May 18 09:35:06 2019
 
+-----------------------------------------------------------------------------+
 
+-----------------------------------------------------------------------------+
行30: 行32:
 
(host)$ docker exec -u kttn -it relion-docker bash
 
(host)$ docker exec -u kttn -it relion-docker bash
  
(docker)[kttn@relion-docker ~]$ nvidia-smi
+
(container)[kttn@relion-docker ~]$ nvidia-smi
 
Failed to initialize NVML: Insufficient Permissions
 
Failed to initialize NVML: Insufficient Permissions
 
</pre>
 
</pre>
 +
 +
===原因===
 +
ホストマシンにVirtualGLをインストールしてあり、インストール時の設定でGPUデバイスの所有者グループがvglusersに書き換えられていたため。
 +
 +
===対処===
 +
コンテナ内で vglusers というグループを作り、ノーマルユーザーをvglusersに追加すれば、GPUデバイスを使えるようになった。
 +
<pre>
 +
(contianer) $ sudo groupadd -g <ホストマシンにおけるvglusersのGID> vglusers
 +
(contianer) $ sudo usermod -aG vglusers <non-rootユーザーのユーザー名>
 +
</pre>
 +
 +
あるいは、ホストマシンでVirtualGLをアンインストールするか。(所有グループがrootに戻るか要確認)
 +
 +
= '''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>
 +
 +
/var/run/sshdというディレクトリをあらかじめ作っておかないといけないらしい。
 +
 +
===対処===
 +
Dockerfileに、sshdのコマンドを走らせる前に
 +
<pre>
 +
RUN mkdir -p /var/run/sshd
 +
</pre>
 +
を書き加えて再ビルドしたら大丈夫になった。
 +
 +
= '''ネットワーク関係''' =
 +
== マシンを再起動したらswarm(overlayネットワーク)が機能しなくなった ==
 +
=== 症状 ===
 +
あるoverlayネットワークに参加しているコンテナがswarmワーカーノード上にあって、計算機の再起動後にdocker startでコンテナ再起動しようとしたところ、以下のようなエラーが出て再起動してくれなかった。
 +
<pre>
 +
Error response from daemon: Could not attach to network asuaxn22bff1sq8pqqay2sg64: context deadline exceeded
 +
Error: failed to start containers: <コンテナ名>
 +
</pre>
 +
 +
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>
 +
 +
= '''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?
 +
 +
=== 原因 ===
 +
* 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>
 +
 +
=== 対処 ===
 +
対処中

2020年11月17日 (火) 13: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

対処

対処中