【Team JINIAC】　トラブルシュート （LinuxのPermission設定）

この記事で分かること

• LinuxのPermission設定の種類
• groupとothersの挙動の違い
• シェルコマンド実行時やシェル実行時の挙動

はじめに

私は、Team JINIAC内では「セーフティーネット」と呼んでいた、松尾・岩澤研が用意する標準コードをベースに事前学習を担当していました。
チーム開発では、個人開発の時とは違う、自分ではコントロールできない様々な制約があります。
今回は、そんな中からPermission関係で起こったエラーを取り上げて、トラブル解決までの道のりと、振り返って得た知見を紹介したいと思います。

エラー発生にいたるまでの状況（概要）

1. 全チームがアクセス可能な共有ディスク上で、実行環境を構築し、シングルノードで事前学習のパラメーター調整を行っていました。
2. その後、サーバーメンテナンスを実施し、共有ディスクの権限対応が行われました。
   • 自チームの共有ディスクにしかアクセスできなくなるというアナウンスでした。
3. サーバーメンテナンスの翌日から、マルチノードの実行をはじめました。

エラーの内容

シェルスクリプトで、以下のコマンドを実行したところ、中身が空白であるhostfileが作成されました。

# Creates a hostfile.
script_dir=$(dirname "$0")
hostfile="${script_dir}/hostfile_jobid-${SLURM_JOB_ID}"
nodes=$(scontrol show hostnames $SLURM_JOB_NODELIST)

for node in $nodes
do
  gpu_count=$(ssh ${node} "nvidia-smi --query-gpu=name --format=csv,noheader | wc -l")
  echo "${node} slots=${gpu_count}"
done > "${hostfile}"

echo "hostfile = ${hostfile}"
cat ${hostfile}
echo ""

前提として知っていた知識

前提として知っていた知識

• Linuxのpermission設定の種類
  Linuxのpermissionには大きく３つの種類があり、ファイルのpermissionとディレクトリのpermissionでは、少し意味合いが異なります。

  • ファイルの場合

  種類	表記	意味
  read	r	ファイルの内容を読むことができる権限
  write	w	ファイルの内容を変更できる権限
  execute	x	ファイルを実行することができる権限

  • ディレクトリの場合
    | 種類 | 表記 | 意味 |
    | ---- | ---- | ---- |
    | read | r | ディレクトリの中身を見ることができる権限 |
    | write | w | ディレクトリ内にファイルを作成、削除、名称変更することができる権限 |
    | execute | x | ディレクトリを開くことができる権限 |

• permissionのカテゴリ
  Linuxのpermissionは、次の3つのカテゴリに分かれています。

  • 所有者（owner）
  • グループ（group）
  • その他（others）

• permissionの表示
  ls -lコマンドを使うと、ファイルやディレクトリの権限を確認できます。

drwxrwxr-x

出力結果については、d|rwx|rwx|r-x|に分けると、理解がしやすいです。

• 最初の１バイトは種類を表します。例えば、dはディレクトリであること、-はファイルであることなどです。
• 次の３バイトは、ownerに与えられた権限を表します。r,w,xはそれぞれread,write,executeの権限があるかどうかを示しています。
• 次の３バイトは、groupに与えられた権限を表します。
• 最後の３バイトは、othersに与えられた権限を表します。

エラー原因を考えた過程（発生時）

エラー原因を考えた過程

• シェルスクリプトが実行できていることから、コードは問題ない
• script_dirのpermissionは、drwxrwxr-x
• script_dirは、他のチームメンバーがオーナーだったが、hostfileが作成されたことから、実行者にgroupのpermissionが割り振られている
• groupのpermissionが割り振られているにも関わらず、hostfileが書き込めないのは、writeのpermissionがないような（othersのpermissionに従ったような）動き　→　原因が分からない

暫定対策

原因解明に行き詰ったこと、エラー発生から２時間以上経過し、時間を無駄にしたくなかったことから、とりあえずこのコードを実行しなくても済む方法として、hostfileを手動で作成し、script_dir上に事前に配置することにしました。

【発展編】真の原因推定（後日調査から）

とりあえず、暫定対策でエラー回避したものの、どうにも気持ちが悪いのでもう少し深堀りして調査してみました。

groupのpermissionが割り振られているにも関わらず、hostfileが書き込めないのは、writeのpermissionがないような（othersのpermissionに従ったような）動き

が起こる条件は、どのような場合か考えてみました。
コードの一部を再掲します。

for node in $nodes
do
  gpu_count=$(ssh ${node} "nvidia-smi --query-gpu=name --format=csv,noheader | wc -l")
  echo "${node} slots=${gpu_count}"
done > "${hostfile}"

echo "hostfile = ${hostfile}"
cat ${hostfile}
echo ""

推定１

このプロジェクトでは、計算処理を行う際、

• 一旦ログインノードにログインしたうえで、
• リソースを指定して、計算ノードに処理を投げる。

という手順を踏んでいました。
思い返すと、.bashrcを書き換える処理をしたことが原因で、ログインノードのユーザと計算ノードのユーザが不一致になり、処理実行時に適切なpermission設定にならなかったのではと考えています。
このコードの中で、echoやcatはread権限があれば実行可能ですが、write権限が必要な部分は、リダイレクト>の部分になります。
したがって、hostfileへの書き込みができなかったのではないかと推定します。

推定２

もう一つ考える可能性は、ssh接続の失敗です。
当時、マルチノード接続を試し始めたこともあり、頻繁に接続設定を変更していました。
このコードの中で、nvidia-smiコマンドは、計算ノードへのssh接続ができていていなければ、結果を返すことはできません。結果として、空白の結果を返してしまった可能性も推定できます。

いずれにせよ、こういった可能性に気付くためには、まだまだ経験を積む必要があると痛感しました。

おわりに

この記事が、みなさまのトラブルシュートの一助になれば幸いです。

この成果は、NEDO（国立研究開発法人新エネルギー・産業技術総合開発機構）の助成事業「ポスト５Ｇ情報通信システム基盤強化研究開発事業」（JPNP20017）の結果得られたものです。