「Dockerトラブルシューティング」の版間の差分
(→CMD ["/usr/sbin/sshd", "-D"] してるのにコンテナ立ち上げてもすぐExitしてしまうんだけど) |
|||
(同じ利用者による、間の1版が非表示) | |||
行1: | 行1: | ||
− | == | + | = '''ホストマシンデバイス関連''' = |
− | === | + | == コンテナ内でノーマルユーザーだとGPUが使えない == |
+ | ===症状=== | ||
rootユーザー | rootユーザー | ||
<pre> | <pre> | ||
行35: | 行36: | ||
</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> | <pre> | ||
− | + | RUN mkdir -p /var/run/sshd | |
− | + | ||
</pre> | </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
対処
対処中