Slurm Troubleshooting Guide

This guide is meant as a tool to help system administrators or operators troubleshoot Slurm failures and restore services.
このガイドは、システム管理者またはオペレーターがSlurm障害のトラブルシューティングを行い、サービスを復元するのに役立つツールを目的としています。
 The Frequently Asked Questions document may also prove useful.
よくある質問のドキュメントも役立つ場合があります。

Slurm is not responding

  1. Execute "scontrol ping" to determine if the primary and backup controllers are responding.
    「scontrolping」を実行して、プライマリコントローラとバックアップコントローラが応答しているかどうかを確認します。
  2. If it responds for you, this could be a networking or configuration problem specific to some user or node in the cluster.
    応答する場合、これはクラスター内の一部のユーザーまたはノードに固有のネットワークまたは構成の問題である可能性があります。
  3. If not responding, directly login to the machine and try again to rule out network and configuration problems.
    応答しない場合は、マシンに直接ログインして、ネットワークと構成の問題を除外するために再試行してください。
  4. If still not responding, check if there is an active slurmctld daemon by executing "ps -el | grep slurmctld".
    それでも応答しない場合は、「ps -el | grep slurmctld」を実行して、アクティブなslurmctldデーモンがあるかどうかを確認します。
  5. If slurmctld is not running, restart it (typically as user root using the command "/etc/init.d/slurm start").
    slurmctldが実行されていない場合は、再起動します（通常、コマンド「/etc/init.d/slurmstart」を使用してユーザーrootとして）。
     You should check the log file (SlurmctldLog in the slurm.conf file) for an indication of why it failed.
    ログファイル（slurm.confファイルのSlurmctldLog）をチェックして、失敗した理由を確認する必要があります。
  6. If slurmctld is running but not responding (a very rare situation), then kill and restart it (typically as user root using the commands "/etc/init.d/slurm stop" and then "/etc/init.d/slurm start").
    slurmctldが実行されているが応答しない場合（非常にまれな状況）、それを強制終了して再起動します（通常、ユーザーrootとして、コマンド「/etc/init.d/slurmstop」を使用してから「/etc/init.d/slurmstart」を使用します）。 "）。
  7. If it hangs again, increase the verbosity of debug messages (increase SlurmctldDebug in the slurm.conf file) and restart.
    再びハングする場合は、デバッグメッセージの冗長性を高め（slurm.confファイルのSlurmctldDebugを増やします）、再起動します。
     Again check the log file for an indication of why it failed.
    再度ログファイルをチェックして、失敗した理由を確認してください。
  8. If it continues to fail without an indication as to the failure mode, restart without preserving state (typically as user root using the commands "/etc/init.d/slurm stop" and then "/etc/init.d/slurm startclean").
    失敗モードを示さずに失敗し続ける場合は、状態を保持せずに再起動します（通常、ユーザーrootとして、コマンド「/etc/init.d/slurmstop」を使用してから「/etc/init.d/slurmstartclean」を使用します）。 ）。
     Note: All running jobs and other state information will be lost.
    注：実行中のすべてのジョブおよびその他の状態情報は失われます。

Jobs are not getting scheduled

This is dependent upon the scheduler used by Slurm.
これは、Slurmが使用するスケジューラーに依存します。
 Executing the command "scontrol show config | grep SchedulerType" to determine this.
これを判別するには、コマンド「scontrol show config | grepSchedulerType」を実行します。
 For any scheduler, you can check priorities of jobs using the command "scontrol show job".
どのスケジューラーでも、コマンド「scontrolshowjob」を使用してジョブの優先順位を確認できます。

  • If the scheduler type is builtin, then jobs will be executed in the order of submission for a given partition.
    スケジューラタイプが組み込まれている場合、ジョブは特定のパーティションの送信順に実行されます。
     Even if resources are available to initiate jobs immediately, it will be deferred until no previously submitted job is pending.
    ジョブをすぐに開始するためのリソースが利用可能であっても、以前に送信されたジョブが保留になるまで延期されます。
  • If the scheduler type is backfill, then jobs will generally be executed in the order of submission for a given partition with one exception: later submitted jobs will be initiated early if doing so does not delay the expected execution time of an earlier submitted job.
    スケジューラタイプがバックフィルの場合、ジョブは通常、特定のパーティションの送信順に実行されますが、例外が1つあります。それが先に送信されたジョブの予想実行時間を遅らせない場合、後で送信されたジョブは早期に開始されます。
     In order for backfill scheduling to be effective, users jobs should specify reasonable time limits.
    バックフィルスケジューリングを効果的にするには、ユーザージョブで適切な時間制限を指定する必要があります。
     If jobs do not specify time limits, then all jobs will receive the same time limit (that associated with the partition), and the ability to backfill schedule jobs will be limited.
    ジョブで時間制限が指定されていない場合、すべてのジョブが同じ時間制限（パーティションに関連付けられている時間制限）を受け取り、スケジュールジョブを埋め戻す機能が制限されます。
     The backfill scheduler does not alter job specifications of required or excluded nodes, so jobs which specify nodes will substantially reduce the effectiveness of backfill scheduling.
    バックフィルスケジューラは、必須ノードまたは除外ノードのジョブ仕様を変更しないため、ノードを指定するジョブは、バックフィルスケジューリングの効果を大幅に低下させます。
     See the backfill documentation for more details.
    詳細については、埋め戻しのドキュメントを参照してください。

Jobs and nodes are stuck in COMPLETING state

This is typically due to non-killable processes associated with the job.
これは通常、ジョブに関連付けられている強制終了できないプロセスが原因です。
 Slurm will continue to attempt terminating the processes with SIGKILL, but some jobs may be stuck performing I/O and non-killable.
Slurmは引き続きSIGKILLを使用してプロセスの終了を試みますが、一部のジョブはI / Oの実行でスタックし、強制終了できない場合があります。
 This is typically due to a file system problem and may be addressed in a couple of ways.
これは通常、ファイルシステムの問題が原因であり、いくつかの方法で対処できます。

  1. Fix the file system and/or reboot the node.
    ファイルシステムを修正するか、ノードを再起動します。
     -OR-
    -または-
  2. Set the node to a DOWN state and then return it to service ("scontrol update NodeName=<node> State=down Reason=hung_proc" and "scontrol update NodeName=<node> State=resume").
    ノードをDOWN状態に設定してから、サービスに戻します（ "scontrol update NodeName = ＜node＞ State = down Reason = hung_proc"および "scontrol update NodeName = ＜node＞ State = resume"）。
     This permits other jobs to use the node, but leaves the non-killable process in place.
    これにより、他のジョブがノードを使用できるようになりますが、強制終了できないプロセスはそのままになります。
     If the process should ever complete the I/O, the pending SIGKILL should terminate it immediately.
    プロセスがI / Oを完了する必要がある場合、保留中のSIGKILLはすぐにI / Oを終了する必要があります。
     -OR-
    -または-
  3. Use the UnkillableStepProgram and UnkillableStepTimeout configuration parameters to automatically respond to processes which can not be killed, by sending email or rebooting the node.
    UnkillableStepProgramおよびUnkillableStepTimeout構成パラメーターを使用して、電子メールを送信するかノードを再起動することにより、強制終了できないプロセスに自動的に応答します。
     For more information, see the slurm.conf documentation.
    詳細については、slurm.confのドキュメントを参照してください。

Nodes are getting set to a DOWN state

  1. Check the reason why the node is down using the command "scontrol show node <name>".
    コマンド「scontrolshownode ＜name＞」を使用して、ノードがダウンしている理由を確認します。
     This will show the reason why the node was set down and the time when it happened.
    これにより、ノードが設定された理由とそれが発生した時刻が表示されます。
     If there is insufficient disk space, memory space, etc. compared to the parameters specified in the slurm.conf file then either fix the node or change slurm.conf.
    slurm.confファイルで指定されたパラメータと比較してディスク容量やメモリ容量などが不足している場合は、ノードを修正するか、slurm.confを変更してください。
  2. If the reason is "Not responding", then check communications between the control machine and the DOWN node using the command "ping <address>" being sure to specify the NodeAddr values configured in slurm.conf.
    理由が「応答しない」の場合は、コマンド「ping ＜address＞」を使用して、制御マシンとDOWNノード間の通信を確認し、slurm.confで構成されているNodeAddr値を必ず指定してください。
     If ping fails, then fix the network or addresses in slurm.conf.
    pingが失敗した場合は、slurm.confでネットワークまたはアドレスを修正してください。
  3. Next, login to a node that Slurm considers to be in a DOWN state and check if the slurmd daemon is running with the command "ps -el | grep slurmd".
    次に、SlurmがDOWN状態であると見なすノードにログインし、コマンド「ps -el | grepslurmd」を使用してslurmdデーモンが実行されているかどうかを確認します。
     If slurmd is not running, restart it (typically as user root using the command "/etc/init.d/slurm start").
    slurmdが実行されていない場合は、再起動します（通常、コマンド「/etc/init.d/slurmstart」を使用してユーザーrootとして）。
     You should check the log file (SlurmdLog in the slurm.conf file) for an indication of why it failed.
    ログファイル（slurm.confファイルのSlurmdLog）をチェックして、失敗した理由を確認する必要があります。
     You can get the status of the running slurmd daemon by executing the command "scontrol show slurmd" on the node of interest.
    対象のノードでコマンド「scontrolshowslurmd」を実行すると、実行中のslurmdデーモンのステータスを取得できます。
     Check the value of "Last slurmctld msg time" to determine if the slurmctld is able to communicate with the slurmd.
    「Lastslurmctldmsg time」の値をチェックして、slurmctldがslurmdと通信できるかどうかを判別します。
  4. If slurmd is running but not responding (a very rare situation), then kill and restart it (typically as user root using the commands "/etc/init.d/slurm stop" and then "/etc/init.d/slurm start").
    slurmdが実行されているが応答しない場合（非常にまれな状況）、それを強制終了して再起動します（通常、ユーザーrootとして、コマンド「/etc/init.d/slurmstop」を使用してから「/etc/init.d/slurmstart」を使用します）。 "）。
  5. If still not responding, try again to rule out network and configuration problems.
    それでも応答しない場合は、ネットワークと構成の問題を除外してみてください。
  6. If still not responding, increase the verbosity of debug messages (increase SlurmdDebug in the slurm.conf file) and restart.
    それでも応答しない場合は、デバッグメッセージの詳細度を上げ（slurm.confファイルのSlurmdDebugを増やします）、再起動します。
     Again check the log file for an indication of why it failed.
    再度ログファイルをチェックして、失敗した理由を確認してください。
  7. If still not responding without an indication as to the failure mode, restart without preserving state (typically as user root using the commands "/etc/init.d/slurm stop" and then "/etc/init.d/slurm startclean").
    それでも障害モードを示さずに応答しない場合は、状態を保持せずに再起動します（通常、ユーザーrootとして、コマンド「/etc/init.d/slurmstop」を使用してから「/etc/init.d/slurmstartclean」を使用します）。 。
     Note: All jobs and other state information on that node will be lost.
    注：そのノード上のすべてのジョブおよびその他の状態情報は失われます。

Networking and configuration problems

  1. Check the controller and/or slurmd log files (SlurmctldLog and SlurmdLog in the slurm.conf file) for an indication of why it is failing.
    コントローラやslurmdログファイル（slurm.confファイルのSlurmctldLogおよびSlurmdLog）をチェックして、失敗する理由を確認してください。
  2. Check for consistent slurm.conf and credential files on the node(s) experiencing problems.
    問題が発生しているノードで、一貫性のあるslurm.confファイルと資格情報ファイルを確認します。
  3. If this is user-specific problem, check that the user is configured on the controller computer(s) as well as the compute nodes.
    これがユーザー固有の問題である場合は、ユーザーがコントローラーコンピューターと計算ノードで構成されていることを確認してください。
     The user doesn't need to be able to login, but his user ID must exist.
    ユーザーはログインできる必要はありませんが、ユーザーIDが存在している必要があります。
  4. Check that compatible versions of Slurm exists on all of the nodes (execute "sinfo -V" or "rpm -qa | grep slurm").
    互換性のあるバージョンのSlurmがすべてのノードに存在することを確認します（「sinfo-V」または「rpm-qa | grepslurm」を実行します）。
     The Slurm version number contains three period-separated numbers that represent both the major Slurm release and maintenance release level.
    Slurmのバージョン番号には、主要なSlurmリリースとメンテナンスリリースレベルの両方を表す3つの期間区切りの番号が含まれています。
     The first two parts combine together to represent the major release, and match the year and month of that major release.
    最初の2つの部分は、メジャーリリースを表すために組み合わされ、そのメジャーリリースの年と月に一致します。
     The third number in the version designates a specific maintenance level:
    バージョンの3番目の番号は、特定のメンテナンスレベルを示します。
     year.month.maintenance-release (e.g. 17.11.5 is major Slurm release 17.11, and maintenance version 5).
    year.month.maintenance-release（たとえば、17.11.5はメジャーSlurmリリース17.11、およびメンテナンスバージョン5です）。
     Thus version 17.11.x was initially released in November 2017.
    したがって、バージョン17.11.xは最初に2017年11月にリリースされました。
     Slurm daemons will support RPCs and state files from the two previous major releases (e.g. a version 17.11.x SlurmDBD will support slurmctld daemons and commands with a version of 17.11.x, 17.02.x or 16.05.x).
    Slurmデーモンは、以前の2つのメジャーリリースのRPCと状態ファイルをサポートします（たとえば、バージョン17.11.x SlurmDBDは、バージョン17.11.x、17.02.x、または16.05.xのslurmctldデーモンとコマンドをサポートします）。

Last modified 26 April 2019