Frequently Asked Questions

For Management

For Users

For Administrators

For Management

Why should I use Slurm or other Free Open Source Software (FOSS)?
Slurmまたは他の無料のオープンソースソフトウェア（FOSS）を使用する必要があるのはなぜですか？

Free Open Source Software (FOSS) does not mean that it is without cost.
無料のオープンソースソフトウェア（FOSS）が無料であるという意味ではありません。
 It does mean that the you have access to the code so that you are free to use it, study it, and/or enhance it.
それは、あなたが自由にそれを使用し、それを研究し、そして/またはそれを強化するためにあなたがそのコードにアクセスできることを意味します。
 These reasons contribute to Slurm (and FOSS in general) being subject to active research and development worldwide, displacing proprietary software in many environments.
これらの理由により、Slurm（およびFOSS全般）は世界中で活発な研究開発の対象となり、多くの環境で独自仕様のソフトウェアに取って代わっています。
 If the software is large and complex, like Slurm or the Linux kernel, then while there is no license fee, its use is not without cost.
SlurmやLinuxカーネルのようにソフトウェアが大きく複雑な場合、ライセンス料はかかりませんが、その使用には費用がかかります。

If your work is important, you'll want the leading Slurm experts at your disposal to keep your systems operating at peak efficiency.
あなたの仕事が重要な場合は、システムを最高の効率で運用し続けるために、自由に使える主要なSlurmエキスパートが必要です。
 While Slurm has a global development community incorporating leading edge technology, SchedMD personnel have developed most of the code and can provide competitively priced commercial support.
Slurmには最先端のテクノロジーを組み込んだグローバルな開発コミュニティがありますが、SchedMDの担当者はほとんどのコードを開発しており、低価格の商用サポートを提供できます。
 SchedMD works with various organizations to provide a range of support options ranging from remote level-3 support to 24x7 on-site personnel.
SchedMDはさまざまな組織と連携して、リモートレベル3サポートから24時間365日のオンサイト担当者まで、幅広いサポートオプションを提供しています。
 Customers switching from commercial workload mangers to Slurm typically report higher scalability, better performance and lower costs.
商用のワークロードマネージャーからSlurmに切り替える顧客は、通常、より高いスケーラビリティ、より良いパフォーマンス、より低いコストを報告します。

For Users

Why is my job/node in a COMPLETING state?
ジョブ/ノードがCOMPLETING状態になるのはなぜですか？

When a job is terminating, both the job and its nodes enter the COMPLETING state.
ジョブが終了すると、ジョブとそのノードの両方がCOMPLETING状態になります。
 As the Slurm daemon on each node determines that all processes associated with the job have terminated, that node changes state to IDLE or some other appropriate state for use by other jobs.
各ノードのSlurmデーモンが、ジョブに関連付けられているすべてのプロセスが終了したと判断すると、そのノードは状態をIDLEまたは他の適切な状態に変更して、他のジョブで使用できるようにします。
 When every node allocated to a job has determined that all processes associated with it have terminated, the job changes state to COMPLETED or some other appropriate state (e.g. FAILED).
ジョブに割り当てられたすべてのノードが、それに関連付けられたすべてのプロセスが終了したと判断すると、ジョブは状態をCOMPLETEDまたはその他の適切な状態（たとえば、FAILED）に変更します。
 Normally, this happens within a second.
通常、これは1秒以内に発生します。
 However, if the job has processes that cannot be terminated with a SIGKILL signal, the job and one or more nodes can remain in the COMPLETING state for an extended period of time.
ただし、SIGKILLシグナルで終了できないプロセスがジョブにある場合、ジョブと1つ以上のノードが長時間COMPLETING状態のままになることがあります。
 This may be indicative of processes hung waiting for a core file to complete I/O or operating system failure.
これは、コアファイルがI / Oまたはオペレーティングシステムの障害を完了するのを待っているプロセスがハングしていることを示している可能性があります。
 If this state persists, the system administrator should check for processes associated with the job that cannot be terminated then use the scontrol command to change the node's state to DOWN (e.g. "scontrol update NodeName=name State=DOWN Reason=hung_completing"), reboot the node, then reset the node's state to IDLE (e.g. "scontrol update NodeName=name State=RESUME").
この状態が続く場合、システム管理者は、終了できないジョブに関連付けられたプロセスを確認してから、scontrolコマンドを使用してノードの状態をDOWNに変更します（「scontrol update NodeName = name State = DOWN Reason = hung_completing」など）、再起動します。ノード、次にノードの状態をIDLEにリセットします（例： "scontrol update NodeName = name State = RESUME"）。
 Note that setting the node DOWN will terminate all running or suspended jobs associated with that node.
ノードをDOWNに設定すると、そのノードに関連付けられている実行中または一時停止中のすべてのジョブが終了します。
 An alternative is to set the node's state to DRAIN until all jobs associated with it terminate before setting it DOWN and re-booting.
別の方法としては、ノードの状態をDRAINに設定し、それに関連するすべてのジョブを終了してから、DOWNに設定して再起動する方法があります。

Note that Slurm has two configuration parameters that may be used to automate some of this process.
Slurmには、このプロセスの一部を自動化するために使用できる2つの構成パラメーターがあることに注意してください。
 UnkillableStepProgram specifies a program to execute when non-killable processes are identified.
UnkillableStepProgramは、強制終了できないプロセスが識別されたときに実行するプログラムを指定します。
 UnkillableStepTimeout specifies how long to wait for processes to terminate.
UnkillableStepTimeoutは、プロセスが終了するまで待機する時間を指定します。
 See the "man slurm.conf" for more information about these parameters.
これらのパラメーターの詳細については、「man slurm.conf」を参照してください。

Why are my resource limits not propagated?
リソース制限が反映されないのはなぜですか？

When the srun command executes, it captures the resource limits in effect at submit time on the node where srun executes.
srunコマンドが実行されると、srunが実行されるノードでの送信時に有効なリソース制限を取得します。
 These limits are propagated to the allocated nodes before initiating the user's job.
これらの制限は、ユーザーのジョブを開始する前に、割り当てられたノードに伝達されます。
 The Slurm daemons running on the allocated nodes then try to establish identical resource limits for the job being initiated.
割り当てられたノードで実行されているSlurmデーモンは、開始されているジョブに対して同一のリソース制限を確立しようとします。
 There are several possible reasons for not being able to establish those resource limits.
これらのリソース制限を確立できない理由はいくつか考えられます。

  • The hard resource limits applied to Slurm's slurmd daemon are lower than the user's soft resources limits on the submit host.
    Slurmのslurmdデーモンに適用されるハードリソース制限は、サブミットホスト上のユーザーのソフトリソース制限よりも低くなっています。
     Typically the slurmd daemon is initiated by the init daemon with the operating system default limits.
    通常、slurmdデーモンは、オペレーティングシステムのデフォルトの制限でinitデーモンによって開始されます。
     This may be addressed either through use of the ulimit command in the /etc/sysconfig/slurm file or enabling PAM in Slurm.
    これは、/ etc / sysconfig / slurmファイルでulimitコマンドを使用するか、SlurmでPAMを有効にすることで対処できます。
  • The user's hard resource limits on the allocated node are lower than the same user's soft hard resource limits on the node from which the job was submitted.
    割り当てられたノード上のユーザーのハードリソース制限は、ジョブの送信元のノード上の同じユーザーのソフトハードリソース制限よりも低くなっています。
     It is recommended that the system administrator establish uniform hard resource limits for users on all nodes within a cluster to prevent this from occurring.
    システム管理者は、クラスタ内のすべてのノードのユーザーに対して、これが発生しないようにハードリソース制限を統一することをお勧めします。
  • PropagateResourceLimits or PropagateResourceLimitsExcept parameters are configured in slurm.conf and avoid propagation of specified limits.
    PropagateResourceLimitsまたはPropagateResourceLimitsExceptパラメータはslurm.confで設定され、指定された制限の伝播を回避します。

NOTE: This may produce the error message "Can't propagate RLIMIT_...".
注：これにより、「RLIMIT _...を伝播できません」というエラーメッセージが表示される場合があります。
 The error message is printed only if the user explicitly specifies that the resource limit should be propagated or the srun command is running with verbose logging of actions from the slurmd daemon (e.g. "srun -d6 ...").
エラーメッセージが表示されるのは、リソース制限を伝達する必要があることをユーザーが明示的に指定した場合、またはslurmdデーモンからのアクションの詳細なログを使用してsrunコマンドが実行されている場合のみです（「srun -d6 ...」など）。

Why is my job not running?
なぜ私の仕事が実行されないのですか？

The answer to this question depends on a lot of factors. The main one is which scheduler is used by Slurm. Executing the command
この質問への答えは、多くの要因に依存します。主なものは、Slurmが使用するスケジューラーです。コマンドを実行する

scontrol show config | grep SchedulerType

will supply this information. 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 your job 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 section for more details. For any scheduler, you can check priorities of jobs using the command scontrol show job.
詳細については、バックフィルのセクションを参照してください。どのスケジューラーでも、コマンドscontrol show jobを使用してジョブの優先順位を確認できます。
 Other reasons can include waiting for resources, memory, qos, reservations, etc.
その他の理由には、リソース、メモリ、QoS、予約などの待機が含まれます。
 As a guideline, issue an scontrol show job <jobid> and look at the field State and Reason to investigate the cause.
ガイドラインとして、scontrol showジョブを発行します そして、原因を調査するためにフィールドの状態と理由を見てください。

Why does the srun --overcommit option not permit multiple jobs to run on nodes?
srun --overcommitオプションが複数のジョブのノードでの実行を許可しないのはなぜですか？

The --overcommit option is a means of indicating that a job or job step is willing to execute more than one task per processor in the job's allocation.
--overcommitオプションは、ジョブまたはジョブステップが、ジョブの割り当てでプロセッサごとに複数のタスクを実行する意思があることを示す手段です。
 For example, consider a cluster of two processor nodes.
たとえば、2つのプロセッサノードのクラスタを考えます。
 The srun execute line may be something of this sort
srun実行行はこのようなものかもしれません

srun --ntasks=4 --nodes=1 a.out

This will result in not one, but two nodes being allocated so that each of the four tasks is given its own processor.
これにより、1つではなく2つのノードが割り当てられ、4つのタスクのそれぞれに独自のプロセッサが割り当てられます。
 Note that the srun --nodes option specifies a minimum node count and optionally a maximum node count.
srun --nodesオプションは、最小ノード数とオプションで最大ノード数を指定することに注意してください。
 A command line of
コマンドライン

srun --ntasks=4 --nodes=1-1 a.out

would result in the request being rejected.
リクエストは拒否されます。
 If the --overcommit option is added to either command line, then only one node will be allocated for all four tasks to use.
--overcommitオプションをいずれかのコマンドラインに追加すると、使用する4つのタスクすべてに1つのノードのみが割り当てられます。

More than one job can execute simultaneously on the same compute resource (e.g. CPU) through the use of srun's --oversubscribe option in conjunction with the OverSubscribe parameter in Slurm's partition configuration.
Slurmのパーティション構成でOverSubscribeパラメータと組み合わせてsrunの--oversubscribeオプションを使用することにより、複数のジョブを同じコンピューティングリソース（CPUなど）で同時に実行できます。
 See the man pages for srun and slurm.conf for more information.
詳細については、srunおよびslurm.confのマニュアルページを参照してください。

Why is my job killed prematurely?
なぜ私の仕事は時期尚早に殺されるのですか？

Slurm has a job purging mechanism to remove inactive jobs (resource allocations) before reaching its time limit, which could be infinite.
Slurmには、時間制限に達する前に非アクティブなジョブ（リソース割り当て）を削除するジョブパージメカニズムがあります。
 This inactivity time limit is configurable by the system administrator.
この非アクティブ時間制限は、システム管理者が構成できます。
 You can check its value with the command
次のコマンドで値を確認できます

scontrol show config | grep InactiveLimit

The value of InactiveLimit is in seconds.
InactiveLimitの値は秒単位です。
 A zero value indicates that job purging is disabled.
ゼロの値は、ジョブのパージが無効であることを示します。
 A job is considered inactive if it has no active job steps or if the srun command creating the job is not responding.
アクティブなジョブステップがない場合、またはジョブを作成するsrunコマンドが応答しない場合、ジョブは非アクティブであると見なされます。
 In the case of a batch job, the srun command terminates after the job script is submitted.
バッチジョブの場合、ジョブスクリプトが送信されると、srunコマンドは終了します。
 Therefore batch job pre- and post-processing is limited to the InactiveLimit.
したがって、バッチジョブの前処理と後処理はInactiveLimitに制限されます。
 Contact your system administrator if you believe the InactiveLimit value should be changed.
InactiveLimit値を変更する必要があると思われる場合は、システム管理者に連絡してください。

Why are my srun options ignored?
srunオプションが無視されるのはなぜですか？

Everything after the command srun is examined to determine if it is a valid option for srun.
コマンドsrunの後のすべてが検査され、それがsrunの有効なオプションであるかどうかが判別されます。
 The first token that is not a valid option for srun is considered the command to execute and everything after that is treated as an option to the command. For example:
srunの有効なオプションではない最初のトークンは、実行するコマンドと見なされ、その後のすべてはコマンドのオプションとして扱われます。例えば：

srun -N2 hostname -pdebug

srun processes "-N2" as an option to itself.
srunはそれ自身のオプションとして「-N2」を処理します。
 "hostname" is the command to execute and "-pdebug" is treated as an option to the hostname command.
「hostname」は実行するコマンドで、「-pdebug」はホスト名コマンドのオプションとして扱われます。
 This will change the name of the computer on which Slurm executes the command - Very bad, Don't run this command as user root!
これにより、Slurmがコマンドを実行するコンピューターの名前が変更されます-非常に悪い。ユーザーrootとしてこのコマンドを実行しないでください。

Why is the Slurm backfill scheduler not starting my job?
Slurmバックフィルスケジューラがジョブを開始しないのはなぜですか？

The most common problem is failing to set job time limits.
最も一般的な問題は、ジョブの時間制限を設定できないことです。
 If all jobs have the same time limit (for example the partition's time limit), then backfill will not be effective.
すべてのジョブに同じ制限時間（たとえば、パーティションの制限時間）がある場合、バックフィルは有効になりません。
 Note that partitions can have both default and maximum time limits, which can be helpful in configuring a system for effective backfill scheduling.
パーティションにはデフォルトと最大の両方の時間制限を設定できることに注意してください。これは、効果的なバックフィルスケジューリングのためにシステムを構成するのに役立ちます。

In addition, there are a multitude of backfill scheduling parameters which can impact which jobs are considered for backfill scheduling, such as the maximum number of jobs tested per user.
さらに、ユーザーごとにテストされるジョブの最大数など、バックフィルスケジューリングの対象となるジョブに影響を与える可能性のある多数のバックフィルスケジューリングパラメーターがあります。
 For more information see the slurm.conf man page and check the configuration of SchedulingParameters on your system.
詳細については、slurm.confのマニュアルページを参照し、システムのSchedulingParametersの設定を確認してください。

How can I run multiple jobs from within a single script?
単一のスクリプト内から複数のジョブを実行するにはどうすればよいですか？

A Slurm job is just a resource allocation.
Slurmジョブは単なるリソース割り当てです。
 You can execute many job steps within that allocation, either in parallel or sequentially.
その割り当て内の多くのジョブステップを並列または順次に実行できます。
 Some jobs actually launch thousands of job steps this way.
一部のジョブは、実際にこの方法で何千ものジョブステップを起動します。
 The job steps will be allocated nodes that are not already allocated to other job steps.
ジョブステップには、他のジョブステップにまだ割り当てられていないノードが割り当てられます。
 This essentially provides a second level of resource management within the job for the job steps.
これは基本的に、ジョブステップのジョブ内で第2レベルのリソース管理を提供します。

How can I run a job within an existing job allocation?
既存のジョブ割り当て内でジョブを実行するにはどうすればよいですか？

There is an srun option --jobid that can be used to specify a job's ID.
ジョブのIDを指定するために使用できるsrunオプション--jobidがあります。
 For a batch job or within an existing resource allocation, the environment variable SLURM_JOB_ID has already been defined, so all job steps will run within that job allocation unless otherwise specified.
バッチジョブの場合、または既存のリソース割り当て内では、環境変数SLURM_JOB_IDがすでに定義されているため、特に指定しない限り、すべてのジョブステップはそのジョブ割り当て内で実行されます。
 The one exception to this is when submitting batch jobs.
これに対する1つの例外は、バッチジョブを送信する場合です。
 When a batch job is submitted from within an existing batch job, it is treated as a new job allocation request and will get a new job ID unless explicitly set with the --jobid option.
既存のバッチジョブ内からバッチジョブが送信されると、それは新しいジョブ割り当て要求として扱われ、-jobidオプションで明示的に設定されていない限り、新しいジョブIDを取得します。
 If you specify that a batch job should use an existing allocation, that job allocation will be released upon the termination of that batch job.
バッチジョブで既存の割り当てを使用するように指定した場合、そのジョブの割り当ては、そのバッチジョブの終了時に解放されます。

How does Slurm establish the environment for my job?
Slurmは私の仕事のための環境をどのように確立しますか？

Slurm processes are not run under a shell, but directly exec'ed by the slurmd daemon (assuming srun is used to launch the processes).
Slurmプロセスはシェルの下では実行されませんが、slurmdデーモンによって直接実行されます（プロセスの起動にsrunが使用されると想定）。
 The environment variables in effect at the time the srun command is executed are propagated to the spawned processes.
srunコマンドの実行時に有効な環境変数は、生成されたプロセスに伝達されます。
 The ~/.profile and ~/.bashrc scripts are not executed as part of the process launch.
〜/ .profileおよび〜/ .bashrcスクリプトは、プロセスの起動の一部として実行されません。
 You can also look at the --export option of srun and sbatch.
srunとsbatchの--exportオプションも確認できます。
 See man pages for details.
詳細については、manページを参照してください。

How can I get shell prompts in interactive mode?
対話モードでシェルプロンプトを取得するにはどうすればよいですか？

srun --pty bash -i
Srun's --pty option runs task zero in pseudo terminal mode.
Srunの--ptyオプションは、タスク0を疑似ターミナルモードで実行します。
 Bash's -i option tells it to run in interactive mode (with prompts).
Bashの-iオプションは、対話モード（プロンプト付き）で実行するように指示します。
You can also configure SallocDefaultCommand in slurm.conf to automatically launch a shell, e.g.:
slurm.confでSallocDefaultCommandを設定して、シェルを自動的に起動することもできます。例：
 

SallocDefaultCommand="srun -n1 -N1 --mem-per-cpu=0 --pty --preserve-env --cpu-bind=no --mpi=none $SHELL"

And then run salloc directly which will provide you an allocation with an interactive shell console.
次に、sallocを直接実行して、対話型シェルコンソールで割り当てを行います。

How can I get the task ID in the output or error file name for a batch job?
バッチジョブの出力またはエラーファイル名でタスクIDを取得するにはどうすればよいですか？

If you want separate output by task, you will need to build a script containing this specification. For example:
タスクごとに個別の出力が必要な場合は、この仕様を含むスクリプトを作成する必要があります。例えば：

$ cat test
#!/bin/sh
echo begin_test
srun -o out_%j_%t hostname

$ sbatch -n7 -o out_%j test
sbatch: Submitted batch job 65541

$ ls -l out*
-rw-rw-r--  1 jette jette 11 Jun 15 09:15 out_65541
-rw-rw-r--  1 jette jette  6 Jun 15 09:15 out_65541_0
-rw-rw-r--  1 jette jette  6 Jun 15 09:15 out_65541_1
-rw-rw-r--  1 jette jette  6 Jun 15 09:15 out_65541_2
-rw-rw-r--  1 jette jette  6 Jun 15 09:15 out_65541_3
-rw-rw-r--  1 jette jette  6 Jun 15 09:15 out_65541_4
-rw-rw-r--  1 jette jette  6 Jun 15 09:15 out_65541_5
-rw-rw-r--  1 jette jette  6 Jun 15 09:15 out_65541_6

$ cat out_65541
begin_test

$ cat out_65541_2
tdev2

Can the make command utilize the resources allocated to a Slurm job?
makeコマンドはSlurmジョブに割り当てられたリソースを利用できますか？

Yes. There is a patch available for GNU make version 3.81 available as part of the Slurm distribution in the file contribs/make-3.81.slurm.patch. For GNU make version 4.0 you can use the patch in the file contribs/make-4.0.slurm.patch.
はい。ファイルcontribs / make-3.81.slurm.patchのSlurmディストリビューションの一部として利用可能なGNU makeバージョン3.81で利用可能なパッチがあります。GNU makeバージョン4.0の場合、ファイルcontribs / make-4.0.slurm.patchでパッチを使用できます。
 This patch will use Slurm to launch tasks across a job's current resource allocation.
このパッチは、Slurmを使用して、ジョブの現在のリソース割り当て全体でタスクを起動します。
 Depending upon the size of modules to be compiled, this may or may not improve performance.
コンパイルするモジュールのサイズによっては、パフォーマンスが向上する場合と向上しない場合があります。
 If most modules are thousands of lines long, the use of additional resources should more than compensate for the overhead of Slurm's task launch.
ほとんどのモジュールが数千行の長さである場合、追加のリソースを使用することで、Slurmのタスク起動のオーバーヘッドを十分に補うことができます。
 Use with make's -j option within an existing Slurm allocation.
既存のSlurm割り当て内でmakeの-jオプションを使用します。
 Outside of a Slurm allocation, make's behavior will be unchanged.
Slurm割り当て以外では、makeの動作は変更されません。

Can tasks be launched with a remote (pseudo) terminal?
リモート（疑似）端末でタスクを起動できますか？

You have several ways to do so, the recommended ones are the following:
これにはいくつかの方法がありますが、推奨される方法は次のとおりです。

The simplest method is to make use of srun's --pty option, (e.g. srun --pty bash -i).
最も簡単な方法は、srunの--ptyオプションを使用することです（例：srun --pty bash -i）。
 Srun's --pty option runs task zero in pseudo terminal mode.
Srunの--ptyオプションは、タスク0を疑似ターミナルモードで実行します。
 Bash's -i option instructs it to run in interactive mode (with prompts).
Bashの-iオプションは、対話モード（プロンプト付き）で実行するように指示します。

In addition to that method you have the option to define the SallocDefaultCommand to run a task in pseudo terminal mode directly, so you get the prompt just invoking salloc:
その方法に加えて、タスクを疑似端末モードで直接実行するSallocDefaultCommandを定義するオプションがあるため、sallocを呼び出すだけでプロンプトが表示されます。
 

SallocDefaultCommand="srun -n1 -N1 --mem-per-cpu=0 --pty --preserve-env --cpu-bind=no --mpi=none $SHELL"

Finally you can make use of X11 feature and run a graphical terminal. (e.g. srun xterm).
最後に、X11機能を利用してグラフィカル端末を実行できます。（例：srun xterm）。

What does "srun: Force Terminated job" indicate?
「srun：Force Terminated job」は何を示していますか？

The srun command normally terminates when the standard output and error I/O from the spawned tasks end.
通常、srunコマンドは、生成されたタスクからの標準出力とエラーI / Oが終了すると終了します。
 This does not necessarily happen at the same time that a job step is terminated.
これは、ジョブステップの終了と同時に発生するとは限りません。
 For example, a file system problem could render a spawned task non-killable at the same time that I/O to srun is pending.
たとえば、ファイルシステムの問題により、srunするI / Oが保留されているときに、生成されたタスクを強制終了できなくなる可能性があります。
 Alternately a network problem could prevent the I/O from being transmitted to srun.
または、ネットワークの問題により、I / Oがsrunに送信されない場合があります。
 In any event, the srun command is notified when a job step is terminated, either upon reaching its time limit or being explicitly killed.
いずれの場合も、ジョブステップが制限時間に達するか、明示的に強制終了されると、ジョブステップが終了すると、srunコマンドに通知されます。
 If the srun has not already terminated, the message "srun: Force Terminated job" is printed.
srunがまだ終了していない場合は、「srun：Force Terminated job」というメッセージが出力されます。
 If the job step's I/O does not terminate in a timely fashion thereafter, pending I/O is abandoned and the srun command exits.
その後、ジョブステップのI / Oが適時に終了しない場合、保留中のI / Oは破棄され、srunコマンドは終了します。

What does this mean: "srun: First task exited 30s ago" followed by "srun Job Failed"?
これはどういう意味ですか：「srun：最初のタスクは30秒前に終了しました」に続いて「srun Job Failed」

The srun command monitors when tasks exit. By default, 30 seconds after the first task exists, the job is killed.
srunコマンドは、タスクがいつ終了するかを監視します。デフォルトでは、最初のタスクが存在してから30秒後に、ジョブは強制終了されます。
 This typically indicates some type of job failure and continuing to execute a parallel job when one of the tasks has exited is not normally productive.
これは通常、ある種のジョブの失敗を示し、タスクの1つが終了したときに並列ジョブの実行を継続しても通常は生産的ではありません。
 This behavior can be changed using srun's --wait=<time> option to either change the timeout period or disable the timeout altogether. See srun's man page for details.
この動作は、srunの--wait =を使用して変更できます。タイムアウト期間を変更するか、タイムアウトを完全に無効にするオプション。詳細については、srunのmanページを参照してください。

Why is my MPI job failing due to the locked memory (memlock) limit being too low?
ロックされたメモリ（memlock）の制限が低すぎるためにMPIジョブが失敗するのはなぜですか？

By default, Slurm propagates all of your resource limits at the time of job submission to the spawned tasks.
デフォルトでは、Slurmはジョブの送信時に、生成されたタスクにすべてのリソース制限を伝達します。
 This can be disabled by specifically excluding the propagation of specific limits in the slurm.conf file.
これは、slurm.confファイルで特定の制限の伝播を明確に除外することで無効にできます。
 For example PropagateResourceLimitsExcept=MEMLOCK might be used to prevent the propagation of a user's locked memory limit from a login node to a dedicated node used for his parallel job.
たとえば、PropagateResourceLimitsExcept = MEMLOCKを使用して、ユーザーのロックされたメモリ制限が、ログインノードから並列ジョブに使用される専用ノードに伝達されないようにすることができます。
 If the user's resource limit is not propagated, the limit in effect for the slurmd daemon will be used for the spawned job.
ユーザーのリソース制限が伝搬されない場合、slurwnデーモンに有効な制限が、生成されたジョブに使用されます。
 A simple way to control this is to ensure that user root has a sufficiently large resource limit and ensuring that slurmd takes full advantage of this limit.
これを制御する簡単な方法は、ユーザーrootに十分なリソース制限があることを確認し、slurmdがこの制限を最大限に活用できるようにすることです。
 For example, you can set user root's locked memory limit ulimit to be unlimited on the compute nodes (see "man limits.conf") and ensuring that slurmd takes full advantage of this limit (e.g. by adding "LimitMEMLOCK=infinity" to your systemd's slurmd.service file).
たとえば、ユーザールートのロックされたメモリ制限ulimitを計算ノードで無制限に設定し（「man limits.conf」を参照）、slurmdがこの制限を最大限に活用できるようにします（たとえば、systemdの「LimitMEMLOCK = infinity」を追加することにより） slurmd.serviceファイル）。
 It may also be desirable to lock the slurmd daemon's memory to help ensure that it keeps responding if memory swapping begins.
また、slurmdデーモンのメモリをロックして、メモリスワッピングが開始された場合にデーモンが応答し続けることを保証することが望ましい場合もあります。
 A sample /etc/sysconfig/slurm which can be read from systemd is shown below.
systemdから読み取ることができるサンプル/ etc / sysconfig / slurmを以下に示します。
 Related information about PAM is also available.
PAMに関する関連情報も利用できます。

#
# Example /etc/sysconfig/slurm
#
# Memlocks the slurmd process's memory so that if a node
# starts swapping, the slurmd will continue to respond
SLURMD_OPTIONS="-M"

Why is my batch job that launches no job steps being killed?
ジョブステップを起動しないバッチジョブが強制終了されるのはなぜですか？

Slurm has a configuration parameter InactiveLimit intended to kill jobs that do not spawn any job steps for a configurable period of time.
Slurmには、構成可能な期間ジョブステップを生成しないジョブを強制終了することを目的とした構成パラメーターInactiveLimitがあります。
 Your system administrator may modify the InactiveLimit to satisfy your needs.
システム管理者は、必要に応じてInactiveLimitを変更できます。
 Alternately, you can just spawn a job step at the beginning of your script to execute in the background.
または、スクリプトの最初にジョブステップを生成して、バックグラウンドで実行することもできます。
 It will be purged when your script exits or your job otherwise terminates.
スクリプトが終了するか、ジョブが終了するとパージされます。
 A line of this sort near the beginning of your script should suffice:
スクリプトの冒頭付近にあるこの種の行で十分です：

srun -N1 -n1 sleep 999999 &

How do I run specific tasks on certain nodes in my allocation?
割り当ての特定のノードで特定のタスクを実行するにはどうすればよいですか？

One of the distribution methods for srun '-m or --distribution' is 'arbitrary'.
srun '-mまたは--distribution'の配布方法の1つは「任意」です。
 This means you can tell Slurm to layout your tasks in any fashion you want.
つまり、タスクを任意の方法でレイアウトするようにSlurmに指示できます。
 For instance if I had an allocation of 2 nodes and wanted to run 4 tasks on the first node and 1 task on the second and my nodes allocated from SLURM_JOB_NODELIST where tux[0-1] my srun line would look like this:

たとえば、2つのノードの割り当てがあり、最初のノードで4つのタスクを実行し、2番目のノードで1つのタスクを実行したい場合、tux [0-1]のSLURM_JOB_NODELISTから割り当てられたノードでは、srun行は次のようになります。

srun -n5 -m arbitrary -w tux[0,0,0,0,1] hostname
srun -n5 -m任意-w tux [0,0,0,0,1]ホスト名


If I wanted something similar but wanted the third task to be on tux 1 I could run this:

同様のものが必要だが、3番目のタスクをtux 1にしたい場合は、次のように実行できます。

srun -n5 -m arbitrary -w tux[0,0,1,0,0] hostname
srun -n5 -m任意-w tux [0,0,1,0,0]ホスト名


Here is a simple Perl script named arbitrary.pl that can be ran to easily lay out tasks on nodes as they are in SLURM_JOB_NODELIST.
以下は、arrunary.plという名前のシンプルなPerlスクリプトで、SLURM_JOB_NODELISTにあるノードにタスクを簡単にレイアウトするために実行できます。

#!/usr/bin/perl
my @tasks = split(',', $ARGV[0]);
my @nodes = `scontrol show hostnames $SLURM_JOB_NODELIST`;
my $node_cnt = $#nodes + 1;
my $task_cnt = $#tasks + 1;

if ($node_cnt < $task_cnt) {
	print STDERR "ERROR: You only have $node_cnt nodes, but requested layout on $task_cnt nodes.\n";
	$task_cnt = $node_cnt;
}

my $cnt = 0;
my $layout;
foreach my $task (@tasks) {
	my $node = $nodes[$cnt];
	last if !$node;
	chomp($node);
	for(my $i=0; $i < $task; $i++) {
		$layout .= "," if $layout;
		$layout .= "$node";
	}
	$cnt++;
}
print $layout;

We can now use this script in our srun line in this fashion.
これで、このスクリプトをこの方法でsrun行で使用できます。


srun -m arbitrary -n5 -w `arbitrary.pl 4,1` -l hostname
srun -m任意-n5 -w `arbitrary.pl 4,1` -lホスト名


This will layout 4 tasks on the first node in the allocation and 1 task on the second node.
これにより、割り当ての最初のノードに4つのタスクが配置され、2番目のノードに1つのタスクが配置されます。

How can I temporarily prevent a job from running (e.g. place it into a hold state)?
ジョブの実行を一時的に防ぐにはどうすればよいですか（たとえば、ジョブをホールド状態にするなど）？

The easiest way to do this is to change a job's earliest begin time (optionally set at job submit time using the --begin option).
これを行う最も簡単な方法は、ジョブの最も早い開始時刻を変更することです（オプションで、ジョブの送信時に--beginオプションを使用して設定します）。
 The example below places a job into hold state (preventing its initiation for 30 days) and later permitting it to start now.
以下の例では、ジョブを保留状態（30日間は開始を禁止）にし、後で今すぐ開始することを許可しています。

$ scontrol update JobId=1234 StartTime=now+30days
... later ...
$ scontrol update JobId=1234 StartTime=now

Why are jobs not getting the appropriate memory limit?
ジョブが適切なメモリ制限を取得しないのはなぜですか？

This is probably a variation on the locked memory limit problem described above.
これはおそらく、上記のロックされたメモリ制限の問題のバリエーションです。
 Use the same solution for the AS (Address Space), RSS (Resident Set Size), or other limits as needed.
AS（アドレススペース）、RSS（常駐セットサイズ）、または必要に応じて他の制限に対して同じソリューションを使用します。

Is an archive available of messages posted to the slurm-users mailing list?
slurm-usersメーリングリストに投稿されたメッセージのアーカイブはありますか？

Yes, it is at http://groups.google.com/group/slurm-users
はい、http：//groups.google.com/group/slurm-usersにあります

Can I change my job's size after it has started running?
実行開始後にジョブのサイズを変更できますか？

Slurm supports the ability to both increase and decrease the size of jobs.
Slurmは、ジョブのサイズを拡大および縮小する機能の両方をサポートしています。
 While the size of a pending job may be changed with few restrictions, several significant restrictions apply to changing the size of a running job, as noted below:
保留中のジョブのサイズはわずかな制限で変更される可能性がありますが、以下に示すように、実行中のジョブのサイズの変更にはいくつかの重要な制限が適用されます。

  1. Requesting fewer hardware resources, and changing partition, qos, reservation, licenses, etc. is only allowed for pending jobs.
    要求するハードウェアリソースを減らし、パーティション、QoS、予約、ライセンスなどを変更することは、保留中のジョブに対してのみ許可されます。
  2. Job(s) changing size must not be in a suspended state, including jobs suspended for gang scheduling. The jobs must be in a state of pending or running.
    サイズを変更するジョブは、ギャングスケジューリングのために一時停止されたジョブを含め、一時停止状態であってはなりません。ジョブは保留中または実行中の状態でなければなりません。
  3. Job expansion for running jobs is disabled by default.
    実行中のジョブのジョブ拡張は、デフォルトでは無効になっています。
     Site administrators can enable this capability by setting SchedulerParameters=permit_job_expansion in slurm.conf
    サイト管理者は、slurm.confでSchedulerParameters = permit_job_expansionを設定することにより、この機能を有効にできます

Use the scontrol command to change a job's size either by specifying a new node count (NumNodes=) for the job or identify the specific nodes (NodeList=) that you want the job to retain.
scontrolコマンドを使用して、ジョブの新しいノード数（NumNodes =）を指定するか、ジョブに保持する特定のノード（NodeList =）を指定して、ジョブのサイズを変更します。
 Any job steps running on the nodes which are relinquished by the job will be killed unless initiated with the --no-kill option.
--no-killオプションで開始しない限り、ジョブによって解放されたノードで実行されているジョブステップはすべて強制終了されます。
 After the job size is changed, some environment variables created by Slurm containing information about the job's environment will no longer be valid and should either be removed or altered (e.g. SLURM_JOB_NODES, SLURM_JOB_NODELIST and SLURM_NTASKS).
ジョブサイズが変更されると、ジョブの環境に関する情報を含むSlurmによって作成された一部の環境変数は無効になり、削除または変更する必要があります（SLURM_JOB_NODES、SLURM_JOB_NODELIST、SLURM_NTASKSなど）。
 The scontrol command will generate a script that can be executed to reset local environment variables.
scontrolコマンドは、ローカル環境変数をリセットするために実行できるスクリプトを生成します。
 You must retain the SLURM_JOB_ID environment variable in order for the srun command to gather information about the job's current state and specify the desired node and/or task count in subsequent srun invocations.
srunコマンドがジョブの現在の状態に関する情報を収集し、後続のsrun呼び出しで目的のノードやタスクの数を指定できるように、SLURM_JOB_ID環境変数を保持する必要があります。
 A new accounting record is generated when a job is resized, showing the job to have been resubmitted and restarted at the new size.
ジョブのサイズが変更されると、新しいアカウンティングレコードが生成され、ジョブが再送信され、新しいサイズで再起動されたことが示されます。
 An example is shown below.
以下に例を示します。

#!/bin/bash
srun my_big_job
scontrol update JobId=$SLURM_JOB_ID NumNodes=2
. slurm_job_${SLURM_JOB_ID}_resize.sh
srun -N2 my_small_job
rm slurm_job_${SLURM_JOB_ID}_resize.*

Increasing a job's size
ジョブのサイズを増やす

Directly increasing the size of a running job would adversely affect the scheduling of pending jobs.
実行中のジョブのサイズを直接増やすと、保留中のジョブのスケジューリングに悪影響を及ぼします。
 For the sake of fairness in job scheduling, expanding a running job requires the user to submit a new job, but specify the option --dependency=expand:<jobid>.
ジョブのスケジュールを公平にするために、実行中のジョブを展開するには、ユーザーが新しいジョブを送信する必要がありますが、オプション--dependency = expandを指定します。。
 This option tells Slurm that the job, when scheduled, can be used to expand the specified jobid.
このオプションは、スケジュールされたジョブを使用して、指定されたジョブIDを展開できることをSlurmに通知します。
 Other job options would be used to identify the required resources (e.g. task count, node count, node features, etc.).
他のジョブオプションは、必要なリソースを識別するために使用されます（タスク数、ノード数、ノード機能など）。
 This new job's time limit will be automatically set to reflect the end time of the job being expanded.
この新しいジョブの制限時間は、拡張されるジョブの終了時間を反映するように自動的に設定されます。
 This new job's generic resources specification will be automatically set equal to that of the job being merged to.
この新しいジョブの総称リソース仕様は、マージされるジョブの仕様に自動的に等しく設定されます。
 This is due to the current Slurm restriction of all nodes associated with a job needing to have the same generic resource specification (i.e. a job can not have one GPU on one node and two GPUs on another node), although this restriction may be removed in the future.
これは、ジョブに関連付けられたすべてのノードの現在のSlurm制限によるものです。同じ汎用リソース指定が必要です（つまり、ジョブは1つのノードに1つのGPUと別のノードに2つのGPUを持つことはできません）。ただし、この制限は未来。
 This restriction can pose some problems when both jobs can be allocated resources on the same node, in which case the generic resources allocated to the new job will be released.
この制限は、両方のジョブに同じノード上のリソースを割り当てることができる場合にいくつかの問題を引き起こす可能性があります。その場合、新しいジョブに割り当てられた汎用リソースが解放されます。
 If the jobs are allocated resources on different nodes, the generic resources associated with the resulting job allocation after the merge will be consistent as expected.
ジョブに異なるノードのリソースが割り当てられている場合、マージ後のジョブの割り当てに関連する一般的なリソースは、期待どおりに一貫します。
 Any licenses associated with the new job will be added to those available in the job being merged to.
新しいジョブに関連付けられているライセンスは、マージされるジョブで使用可能なライセンスに追加されます。
 Note that partition and Quality Of Service (QOS) limits will be applied independently to the new job allocation so the expanded job may exceed size limits configured for an individual job.
パーティションとサービスの品質（QOS）の制限は、新しいジョブの割り当てに個別に適用されるため、拡張されたジョブは、個々のジョブに構成されたサイズ制限を超える可能性があることに注意してください。

After the new job is allocated resources, merge that job's allocation into that of the original job by executing:
新しいジョブにリソースが割り当てられたら、次のコマンドを実行して、そのジョブの割り当てを元のジョブの割り当てにマージします。

scontrol update jobid=<jobid> NumNodes=0
scontrol update jobid = NumNodes = 0

The jobid above is that of the job to relinquish its resources.
上記のジョブIDは、そのリソースを放棄するジョブのものです。
 To provide more control over when the job expansion occurs, the resources are not merged into the original job until explicitly requested.
ジョブの拡張が発生するタイミングをより詳細に制御するために、明示的に要求されるまで、リソースは元のジョブにマージされません。
 These resources will be transferred to the original job and the scontrol command will generate a script to reset variables in the second job's environment to reflect its modified resource allocation (which would be no resources).
これらのリソースは元のジョブに転送され、scontrolコマンドはスクリプトを生成して、2番目のジョブの環境で変数をリセットし、変更されたリソース割り当て（リソースがない）を反映します。
 One would normally exit this second job at this point, since it has no associated resources.
関連するリソースがないため、通常、この時点でこの2番目のジョブを終了します。
 In order to generate a script to modify the environment variables for the expanded job, execute:
拡張ジョブの環境変数を変更するスクリプトを生成するには、次を実行します。

scontrol update jobid=<jobid> NumNodes=ALL
scontrol update jobid = NumNodes = ALL

Then execute the script generated.
次に、生成されたスクリプトを実行します。
 Note that this command does not change the original job's size, but only generates the script to change its environment variables.
このコマンドは元のジョブのサイズを変更せず、環境変数を変更するスクリプトを生成するだけであることに注意してください。
 Until the environment variables are modified (e.g. the job's node count, CPU count, hostlist, etc.), any srun command will only consider the resources in the original resource allocation.
環境変数（ジョブのノード数、CPU数、ホストリストなど）が変更されるまで、srunコマンドは元のリソース割り当てのリソースのみを考慮します。
 Note that the original job may have active job steps at the time of its expansion, but they will not be affected by the change.
元のジョブは展開時にアクティブなジョブステップを持っている可能性がありますが、変更による影響はありません。
 An example of the procedure is shown below in which the original job allocation waits until the second resource allocation request can be satisfied.
手順の例を以下に示します。この場合、元のジョブ割り当ては、2番目のリソース割り当て要求が満たされるまで待機します。
 The job requesting additional resources could also use the sbatch command and permit the original job to continue execution at its initial size.
追加のリソースを要求するジョブは、sbatchコマンドを使用して、元のジョブが初期サイズで実行を継続できるようにすることもできます。
 Note that the development of additional user tools to manage Slurm resource allocations is planned in the future to make this process both simpler and more flexible.
Slurmリソース割り当てを管理するための追加のユーザーツールの開発は、このプロセスをより簡単でより柔軟にするために、将来計画されていることに注意してください。

$ salloc -N4 -C haswell bash
salloc: Granted job allocation 65542
$ srun hostname
icrm1
icrm2
icrm3
icrm4

$ salloc -N4 -C knl,snc4,flat --dependency=expand:$SLURM_JOB_ID bash
salloc: Granted job allocation 65543
$ scontrol update jobid=$SLURM_JOB_ID NumNodes=0
To reset Slurm environment variables, execute
  For bash or sh shells:  . ./slurm_job_65543_resize.sh
  For csh shells:         source ./slurm_job_65543_resize.csh
$ exit
exit
salloc: Relinquishing job allocation 65543

$ scontrol update jobid=$SLURM_JOB_ID NumNodes=ALL
To reset Slurm environment variables, execute
  For bash or sh shells:  . ./slurm_job_65542_resize.sh
  For csh shells:         source ./slurm_job_65542_resize.csh
$ . ./slurm_job_${SLURM_JOB_ID}_resize.sh

$ srun hostname
icrm1
icrm2
icrm3
icrm4
icrm5
icrm6
icrm7
icrm8
$ exit
exit
salloc: Relinquishing job allocation 65542

Why is my MPICH2 or MVAPICH2 job not running with Slurm? Why does the DAKOTA program not run with Slurm?
MPICH2またはMVAPICH2ジョブがSlurmで実行されないのはなぜですか？DAKOTAプログラムがSlurmで実行されないのはなぜですか？

The Slurm library used to support MPICH2 or MVAPICH2 references a variety of symbols.
MPICH2またはMVAPICH2をサポートするために使用されるSlurmライブラリは、さまざまなシンボルを参照します。
 If those symbols resolve to functions or variables in your program rather than the appropriate library, the application will fail.
これらのシンボルが適切なライブラリではなくプログラム内の関数または変数に解決されると、アプリケーションは失敗します。
 For example DAKOTA, versions 5.1 and older, contains a function named regcomp, which will get used rather than the POSIX regex functions.
たとえば、DAKOTA、バージョン5.1以前には、POSIX regex関数ではなく使用されるregcompという名前の関数が含まれています。
 Rename DAKOTA's function and references from regcomp to something else to make it work properly.
DAKOTAの関数と参照の名前をregcompから別の名前に変更して、正しく機能するようにします。

Why does squeue (and "scontrol show jobid") sometimes not display a job's estimated start time?
squeue（および「scontrol show jobid」）がジョブの推定開始時刻を表示しないことがあるのはなぜですか？

When the backfill scheduler is configured, it provides an estimated start time for jobs that are candidates for backfill.
バックフィルスケジューラを構成すると、バックフィルの候補となるジョブの推定開始時間が提供されます。
 Pending jobs with dependencies will not have an estimate as it is difficult to predict what resources will be available when the jobs they are dependent on terminate.
依存関係のある保留中のジョブは、依存しているジョブが終了したときに使用可能なリソースを予測することが難しいため、見積もりはありません。
 Also note that the estimate is better for jobs expected to start soon, as most running jobs end before their estimated time.
また、ほとんどの実行中のジョブは推定時間より前に終了するため、推定はすぐに開始されることが予想されるジョブの方が優れていることにも注意してください。
 There are other restrictions on backfill that may apply. See the backfill section for more details.
適用される可能性のあるバックフィルには他にも制限があります。詳細については、バックフィルのセクションを参照してください。

How can I run an Ansys program with Slurm?
SlurmでAnsysプログラムを実行するにはどうすればよいですか？

If you are talking about an interactive run of the Ansys app, then you can use this simple script (it is for Ansys Fluent):
Ansysアプリのインタラクティブな実行について話している場合は、次の簡単なスクリプトを使用できます（Ansys Fluent用です）。

$ cat ./fluent-srun.sh
#!/usr/bin/env bash
HOSTSFILE=.hostlist-job$SLURM_JOB_ID
if [ "$SLURM_PROCID" == "0" ]; then
   srun hostname -f > $HOSTSFILE
   fluent -t $SLURM_NTASKS -cnf=$HOSTSFILE -ssh 3d
   rm -f $HOSTSFILE
fi
exit 0

To run an interactive session, use srun like this:
インタラクティブセッションを実行するには、次のようにsrunを使用します。

$ srun -n <tasks> ./fluent-srun.sh

How can a job in a complete or failed state be requeued?
完了または失敗した状態のジョブをどのように再キューイングできますか？

Slurm supports requeueing jobs in a done or failed state. Use the command:
Slurmは、完了または失敗した状態のジョブの再キューイングをサポートしています。次のコマンドを使用します。

scontrol requeue job_id

The job will then be requeued back in the PENDING state and scheduled again.
その後、ジョブはPENDING状態で再度キューに入れられ、再度スケジュールされます。
 See man(1) scontrol.
man（1）scontrolを参照してください。

Consider a simple job like this:
このような簡単な仕事を考えてみましょう：

$cat zoppo
#!/bin/sh
echo "hello, world"
exit 10

$sbatch -o here ./zoppo
Submitted batch job 10

The job finishes in FAILED state because it exits with a non zero value.
ジョブはゼロ以外の値で終了するため、FAILED状態で終了します。
 We can requeue the job back to the PENDING state and the job will be dispatched again.
ジョブをPENDING状態に再キューイングすると、ジョブが再びディスパッチされます。
 

$ scontrol requeue 10
$ squeue
     JOBID PARTITION  NAME     USER   ST   TIME  NODES NODELIST(REASON)
      10      mira    zoppo    david  PD   0:00    1   (NonZeroExitCode)
$ squeue
    JOBID PARTITION   NAME     USER ST     TIME  NODES NODELIST(REASON)
      10      mira    zoppo    david  R    0:03    1      alanz1

Slurm supports requeuing jobs in a hold state with the command:
Slurmは、次のコマンドを使用して、ホールド状態のジョブの再キューイングをサポートします。

'scontrol requeuehold job_id'

The job can be in state RUNNING, SUSPENDED, COMPLETED or FAILED before being requeued.
ジョブは、キューに再登録される前に、RUNNING、SUSPENDED、COMPLETED、またはFAILEDの状態になる可能性があります。

$ scontrol requeuehold 10
$ squeue
    JOBID PARTITION  NAME     USER ST       TIME  NODES NODELIST(REASON)
    10      mira    zoppo    david PD       0:00      1 (JobHeldUser)

Slurm documentation refers to CPUs, cores and threads.
Slurmのドキュメントでは、CPU、コア、スレッドについて言及しています。
 What exactly is considered a CPU?
正確には何がCPUと見なされますか？

If your nodes are configured with hyperthreading, then a CPU is equivalent to a hyperthread.
ノードがハイパースレッディングで構成されている場合、CPUはハイパースレッドと同等です。
 Otherwise a CPU is equivalent to a core.
それ以外の場合、CPUはコアと同等です。
 You can determine if your nodes have more than one thread per core using the command "scontrol show node" and looking at the values of "ThreadsPerCore".
「scontrol show node」コマンドを使用して「ThreadsPerCore」の値を確認すると、ノードにコアごとに複数のスレッドがあるかどうかを確認できます。

Note that even on systems with hyperthreading enabled, the resources will generally be allocated to jobs at the level of a core (see NOTE below).
ハイパースレッディングが有効になっているシステムでも、リソースは通常、コアのレベルでジョブに割り当てられることに注意してください（下記の注を参照）。
 Two different jobs will not share a core except through the use of a partition OverSubscribe configuration parameter.
2つの異なるジョブは、パーティションのOverSubscribe構成パラメーターを使用しない限り、コアを共有しません。
 For example, a job requesting resources for three tasks on a node with ThreadsPerCore=2 will be allocated two full cores.
たとえば、ThreadsPerCore = 2のノードで3つのタスクのリソースを要求するジョブには、2つのフルコアが割り当てられます。
 Note that Slurm commands contain a multitude of options to control resource allocation with respect to base boards, sockets, cores and threads.
Slurmコマンドには、ベースボード、ソケット、コア、スレッドに関するリソース割り当てを制御するための多数のオプションが含まれていることに注意してください。

(NOTE: An exception to this would be if the system administrator configured SelectTypeParameters=CR_CPU and each node's CPU count without its socket/core/thread specification.
（注：これに対する例外は、システム管理者がSelectTypeParameters = CR_CPUを構成し、各ノードのソケット/コア/スレッド指定なしのCPU数を構成した場合です。
 In that case, each thread would be independently scheduled as a CPU.
その場合、各スレッドは独立してCPUとしてスケジュールされます。
 This is not a typical configuration.)
これは一般的な構成ではありません。）

What is the difference between the sbatch and srun commands?
sbatchコマンドとsrunコマンドの違いは何ですか？

The srun command has two different modes of operation.
srunコマンドには、2つの異なる操作モードがあります。
 First, if not run within an existing job (i.e. not within a Slurm job allocation created by salloc or sbatch), then it will create a job allocation and spawn an application.
まず、既存のジョブ内で実行されていない場合（つまり、sallocまたはsbatchによって作成されたSlurmジョブ割り当て内ではない場合）、ジョブ割り当てが作成され、アプリケーションが生成されます。
 If run within an existing allocation, the srun command only spawns the application.
既存の割り当て内で実行する場合、srunコマンドはアプリケーションのみを生成します。
 For this question, we will only address the first mode of operation and compare creating a job allocation using the sbatch and srun commands.
この質問では、最初の操作モードのみを取り上げ、sbatchコマンドとsrunコマンドを使用したジョブ割り当ての作成を比較します。

The srun command is designed for interactive use, with someone monitoring the output.
srunコマンドはインタラクティブな使用のために設計されており、誰かが出力を監視しています。
 The output of the application is seen as output of the srun command, typically at the user's terminal.
アプリケーションの出力は、通常はユーザーの端末で、srunコマンドの出力と見なされます。
 The sbatch command is designed to submit a script for later execution and its output is written to a file.
sbatchコマンドは、後で実行するためにスクリプトを送信するように設計されており、その出力はファイルに書き込まれます。
 Command options used in the job allocation are almost identical.
ジョブの割り当てで使用されるコマンドオプションはほとんど同じです。
 The most noticeable difference in options is that the sbatch command supports the concept of job arrays, while srun does not.
オプションの最も顕著な違いは、sbatchコマンドがジョブ配列の概念をサポートするのに対し、srunはサポートしないことです。
 Another significant difference is in fault tolerance.
もう1つの大きな違いは、フォールトトレランスです。
 Failures involving sbatch jobs typically result in the job being requeued and executed again, while failures involving srun typically result in an error message being generated with the expectation that the user will respond in an appropriate fashion.
sbatchジョブに関連する障害では、通常、ジョブが再度キューに入れられて再度実行されますが、srunに関連する障害では、通常、ユーザーが適切に応答することを期待してエラーメッセージが生成されます。

Can squeue output be color coded?
squeueの出力を色分けできますか？

The squeue command output is not color coded, but other tools can be used to add color. One such tool is ColorWrapper (https://github.com/rrthomas/cw).
squeueコマンドの出力は色分けされていませんが、他のツールを使用して色を追加できます。そのようなツールの1つがColorWrapper（https://github.com/rrthomas/cw）です。
 A sample ColorWrapper configuration file and output are shown below.
ColorWrapper設定ファイルのサンプルと出力を以下に示します。

path /bin:/usr/bin:/sbin:/usr/sbin:<env>
usepty
base green+
match red:default (Resources)
match black:default (null)
match black:cyan N/A
regex cyan:default  PD .*$
regex red:default ^\d*\s*C .*$
regex red:default ^\d*\s*CG .*$
regex red:default ^\d*\s*NF .*$
regex white:default ^JOBID.*

Can Slurm export an X11 display on an allocated compute node?
Slurmは割り当てられた計算ノードでX11ディスプレイをエクスポートできますか？

You can use the X11 builtin feature starting at version 17.11.
バージョン11.11以降のX11組み込み機能を使用できます。
 It is enabled by setting PrologFlags=x11 in slurm.conf.
slurm.confでPrologFlags = x11を設定すると有効になります。
 Other X11 plugins must be deactivated.
他のX11プラグインは無効にする必要があります。
Run it as shown:
次のように実行します。
 

$ ssh -X user@login1
$ srun -n1 --pty --x11 xclock

An alternative for older versions is to build and install an optional SPANK plugin for that functionality.
古いバージョンの代替手段は、その機能用のオプションのSPANKプラグインをビルドしてインストールすることです。
 Instructions to build and install the plugin follow.
プラグインをビルドしてインストールする手順は次のとおりです。
 This SPANK plugin will not work if used in combination with native X11 support so you must disable it compiling Slurm with --disable-x11.
このSPANKプラグインは、ネイティブX11サポートと組み合わせて使用​​すると機能しないため、-disable-x11でSlurmをコンパイルして無効にする必要があります。
 This plugin relies on openssh library and it provides features such as GSSAPI support.
このプラグインはopensshライブラリに依存し、GSSAPIサポートなどの機能を提供します。

Update the Slurm installation path as needed:
必要に応じてSlurmインストールパスを更新します。

# It may be obvious, but don't forget the -X on ssh
$ ssh -X alex@testserver.com

# Get the plugin
$ mkdir git
$ cd git
$ git clone https://github.com/hautreux/slurm-spank-x11.git
$ cd slurm-spank-x11

# Manually edit the X11_LIBEXEC_PROG macro definition
$ vi slurm-spank-x11.c
$ vi slurm-spank-x11-plug.c
$ grep "define X11_" slurm-spank-x11.c
#define X11_LIBEXEC_PROG "/opt/slurm/17.02/libexec/slurm-spank-x11"
$ grep "define X11_LIBEXEC_PROG" slurm-spank-x11-plug.c
#define X11_LIBEXEC_PROG "/opt/slurm/17.02/libexec/slurm-spank-x11"


# Compile
$ gcc -g -o slurm-spank-x11 slurm-spank-x11.c
$ gcc -g -I/opt/slurm/17.02/include -shared -fPIC -o x11.so slurm-spank-x11-plug.c

# Install
$ mkdir -p /opt/slurm/17.02/libexec
$ install -m 755 slurm-spank-x11 /opt/slurm/17.02/libexec
$ install -m 755 x11.so /opt/slurm/17.02/lib/slurm

# Configure
$ echo -e "optional x11.so" >> /opt/slurm/17.02/etc/plugstack.conf
$ cd ~/tests

# Run
$ srun -n1 --pty --x11 xclock
alex@node1's password:

Why is the srun --u/--unbuffered option adding a carriage character return to my output?
srun --u /-unbufferedオプションがキャリッジリターンを出力に追加するのはなぜですか？

The libc library used by many programs internally buffers output rather than writing it immediately.
多くのプログラムで使用されるlibcライブラリは、出力をすぐに書き込むのではなく、内部でバッファリングします。
 This is done for performance reasons.
これは、パフォーマンス上の理由で行われます。
 The only way to disable this internal buffering is to configure the program to write to a pseudo terminal (PTY) rather than to a regular file.
この内部バッファリングを無効にする唯一の方法は、通常のファイルではなく疑似端末（PTY）に書き込むようにプログラムを構成することです。
 This configuration causes some implementations of libc to prepend the carriage return character before all line feed characters.
この構成により、libcの一部の実装では、すべての改行文字の前に復帰文字が付加されます。
 Removing the carriage return character would result in desired formatting in some instances, while causing bad formatting in other cases.
キャリッジリターン文字を削除すると、場合によっては適切なフォーマットになりますが、それ以外の場合はフォーマットが悪くなります。
 In any case, Slurm is not adding the carriage return character, but displaying the actual program's output.
いずれにせよ、Slurmは復帰文字を追加していませんが、実際のプログラムの出力を表示しています。

Why is sview not coloring/highlighting nodes properly?
sviewがノードを適切に色付け/強調表示しないのはなぜですか？

sview color-coding is affected by the GTK theme.
sviewの色分けはGTKテーマの影響を受けます。
 The node status grid is made up of button widgets and certain GTK themes don't show the color setting as desired.
ノードステータスグリッドはボタンウィジェットで構成されており、特定のGTKテーマは希望どおりに色設定を表示しません。
 Changing GTK themes can restore proper color-coding.
GTKテーマを変更すると、適切な色分けが復元されます。

For Administrators

How is job suspend/resume useful?
ジョブの一時停止/再開はどのように役立ちますか？

Job suspend/resume is most useful to get particularly large jobs initiated in a timely fashion with minimal overhead.
ジョブの一時停止/再開は、特に大きなジョブを最小限のオーバーヘッドでタイムリーに開始するのに最も役立ちます。
 Say you want to get a full-system job initiated.
システム全体のジョブを開始したいとします。
 Normally you would need to either cancel all running jobs or wait for them to terminate.
通常、実行中のすべてのジョブをキャンセルするか、ジョブが終了するまで待つ必要があります。
 Canceling jobs results in the loss of their work to that point from their beginning.
ジョブをキャンセルすると、最初からその時点までの作業が失われます。
 Waiting for the jobs to terminate can take hours, depending upon your system configuration.
システム構成によっては、ジョブが終了するまで数時間かかる場合があります。
 A more attractive alternative is to suspend the running jobs, run the full-system job, then resume the suspended jobs.
より魅力的な代替手段は、実行中のジョブを一時停止し、システム全体のジョブを実行してから、一時停止したジョブを再開することです。
 This can easily be accomplished by configuring a special queue for full-system jobs and using a script to control the process.
これは、フルシステムジョブ用の特別なキューを構成し、スクリプトを使用してプロセスを制御することで簡単に実現できます。
 The script would stop the other partitions, suspend running jobs in those partitions, and start the full-system partition.
スクリプトは他のパーティションを停止し、それらのパーティションで実行中のジョブを一時停止し、システム全体のパーティションを開始します。
 The process can be reversed when desired.
必要に応じて、プロセスを逆にすることができます。
 One can effectively gang schedule (time-slice) multiple jobs using this mechanism, although the algorithms to do so can get quite complex.
このメカニズムを使用すると、複数のジョブのスケジュール（タイムスライス）を効率的に連動させることができますが、そのためのアルゴリズムは非常に複雑になる可能性があります。
 Suspending and resuming a job makes use of the SIGSTOP and SIGCONT signals respectively, so swap and disk space should be sufficient to accommodate all jobs allocated to a node, either running or suspended.
ジョブの一時停止と再開はそれぞれSIGSTOPシグナルとSIGCONTシグナルを使用するため、実行中または一時停止中のノードに割り当てられたすべてのジョブに対応するには、スワップ領域とディスク領域で十分です。

Why is a node shown in state DOWN when the node has registered for service?
ノードがサービスに登録されているのに、ノードがDOWN状態で表示されるのはなぜですか？

The configuration parameter ReturnToService in slurm.conf controls how DOWN nodes are handled.
slurm.confの構成パラメーターReturnToServiceは、DOWNノードの処理方法を制御します。
 Set its value to one in order for DOWN nodes to automatically be returned to service once the slurmd daemon registers with a valid node configuration.
slurmdデーモンが有効なノード構成に登録されると、DOWNノードが自動的にサービスに戻るように、その値を1に設定します。
 A value of zero is the default and results in a node staying DOWN until an administrator explicitly returns it to service using the command "scontrol update NodeName=whatever State=RESUME".
ゼロの値がデフォルトであり、管理者がコマンド「scontrol update NodeName = whatever State = RESUME」を使用して明示的にサービスに戻すまで、ノードはDOWNのままです。
 See "man slurm.conf" and "man scontrol" for more details.
詳細については、「man slurm.conf」および「man scontrol」を参照してください。

What happens when a node crashes?
ノードがクラッシュするとどうなりますか？

A node is set DOWN when the slurmd daemon on it stops responding for SlurmdTimeout as defined in slurm.conf.
slurm.confで定義されているように、ノードのslurmdデーモンがSlurmdTimeoutの応答を停止すると、ノードはDOWNに設定されます。
 The node can also be set DOWN when certain errors occur or the node's configuration is inconsistent with that defined in slurm.conf.
特定のエラーが発生した場合、またはノードの構成がslurm.confで定義されたものと一致しない場合、ノードをDOWNに設定することもできます。
 Any active job on that node will be killed unless it was submitted with the srun option --no-kill.
そのノード上のアクティブなジョブは、srunオプション--no-killを使用して送信されない限り、強制終了されます。
 Any active job step on that node will be killed.
そのノード上のアクティブなジョブステップはすべて強制終了されます。
 See the slurm.conf and srun man pages for more information.
詳細については、slurm.confおよびsrunのmanページを参照してください。

How can I control the execution of multiple jobs per node?
ノードごとに複数のジョブの実行を制御するにはどうすればよいですか？

There are two mechanisms to control this.
これを制御するメカニズムは2つあります。
 If you want to allocate individual processors on a node to jobs, configure SelectType=select/cons_res.
ノード上の個々のプロセッサをジョブに割り当てる場合は、SelectType = select / cons_resを構成します。
 See Consumable Resources in Slurm for details about this configuration.
この構成の詳細については、Slurmの消費可能なリソースを参照してください。
 If you want to allocate whole nodes to jobs, configure configure SelectType=select/linear.
ノード全体をジョブに割り当てる場合は、configure SelectType = select / linearを構成します。
 Each partition also has a configuration parameter OverSubscribe that enables more than one job to execute on each node.
各パーティションには、各ノードで複数のジョブを実行できるようにする構成パラメーターOverSubscribeもあります。
 See man slurm.conf for more information about these configuration parameters.
これらの構成パラメーターの詳細については、man slurm.confを参照してください。

When the Slurm daemon starts, it prints "cannot resolve X plugin operations" and exits.
Slurmデーモンが起動すると、「Xプラグイン操作を解決できません」と出力して終了します。
 What does this mean?
これは何を意味するのでしょうか？

This means that symbols expected in the plugin were not found by the daemon.
これは、プラグインで予期されるシンボルがデーモンによって検出されなかったことを意味します。
 This typically happens when the plugin was built or installed improperly or the configuration file is telling the plugin to use an old plugin (say from the previous version of Slurm).
これは通常、プラグインが正しく構築またはインストールされていないか、構成ファイルがプラグインに古いプラグインを使用するように指示している場合に発生します（たとえば、Slurmの以前のバージョンから）。
 Restart the daemon in verbose mode for more information (e.g. "slurmctld -Dvvvvv").
詳細については、デーモンを詳細モードで再起動してください（例： "slurmctld -Dvvvvv"）。

How can I exclude some users from pam_slurm?
一部のユーザーをpam_slurmから除外するにはどうすればよいですか？

CAUTION: Please test this on a test machine/VM before you actually do this on your Slurm computers.
注意：実際にSlurmコンピューターでテストする前に、テストマシン/ VMでテストしてください。

Step 1. Make sure pam_listfile.so exists on your system.
手順1.システムにpam_listfile.soが存在することを確認します。
 The following command is an example on Redhat 6:
次のコマンドはRedhat 6の例です。

ls -la /lib64/security/pam_listfile.so

Step 2. Create user list (e.g. /etc/ssh/allowed_users):
ステップ2.ユーザーリストを作成します（例：/ etc / ssh / allowed_users）：

# /etc/ssh/allowed_users
root
myadmin

And, change file mode to keep it secret from regular users(Optional):
そして、ファイルモードを変更して、通常のユーザーからそれを秘密に保ちます（オプション）：

chmod 600 /etc/ssh/allowed_users

NOTE: root is not necessarily listed on the allowed_users, but I feel somewhat safe if it's on the list.
注：rootは必ずしもallowed_usersに記載されているわけではありませんが、リストに記載されていれば多少安全だと感じています。

Step 3. On /etc/pam.d/sshd, add pam_listfile.so with sufficient flag before pam_slurm.so (e.g. my /etc/pam.d/sshd looks like this):
ステップ3. /etc/pam.d/sshdで、pam_slurm.soの前に十分なフラグを付けてpam_listfile.soを追加します（たとえば、/ etc / pam.d / sshdは次のようになります）。

#%PAM-1.0
auth       required     pam_sepermit.so
auth       include      password-auth
account    sufficient   pam_listfile.so item=user sense=allow file=/etc/ssh/allowed_users onerr=fail
account    required     pam_slurm.so
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    optional     pam_keyinit.so force revoke
session    include      password-auth

(Information courtesy of Koji Tanaka, Indiana University)
（情報提供：インディアナ大学田中浩二）

How can I dry up the workload for a maintenance period?
メンテナンス期間のワークロードをどのように枯渇させることができますか？

Create a resource reservation as described b.
説明に従ってリソース予約を作成しますb。
 Slurm's Resource Reservation Guide.
Slurmのリソース予約ガイド。

How can PAM be used to control a user's limits on or access to compute nodes?
PAMを使用して、計算ノードに対するユーザーの制限またはアクセスを制御するにはどうすればよいですか？

To control a user's limits on a compute node:
計算ノードでのユーザーの制限を制御するには：

First, enable Slurm's use of PAM by setting UsePAM=1 in slurm.conf.
まず、slurm.confでUsePAM = 1を設定して、SlurmによるPAMの使用を有効にします。

Second, establish PAM configuration file(s) for Slurm in /etc/pam.conf or the appropriate files in the /etc/pam.d directory (e.g. /etc/pam.d/sshd by adding the line "account required pam_slurm.so".
次に、/ etc / pam.conf内のSlurmのPAM構成ファイル、または/etc/pam.dディレクトリ内の適切なファイル（/etc/pam.d/sshdなど）に、「account required pam_slurm。そう"。
 A basic configuration you might use is:
使用できる基本的な構成は次のとおりです。

account  required  pam_unix.so
account  required  pam_slurm.so
auth     required  pam_localuser.so
session  required  pam_limits.so

Third, set the desired limits in /etc/security/limits.conf.
3番目に、/ etc / security / limits.confで必要な制限を設定します。
 For example, to set the locked memory limit to unlimited for all users:
たとえば、すべてのユーザーに対してロックされたメモリ制限を無制限に設定するには、次のようにします。

*   hard   memlock   unlimited
*   soft   memlock   unlimited

Finally, you need to disable Slurm's forwarding of the limits from the session from which the srun initiating the job ran.
最後に、ジョブを開始したsrunが実行されたセッションからのSlurmによる制限の転送を無効にする必要があります。
 By default all resource limits are propagated from that session.
デフォルトでは、すべてのリソース制限がそのセッションから伝達されます。
 For example, adding the following line to slurm.conf will prevent the locked memory limit from being propagated:PropagateResourceLimitsExcept=MEMLOCK.
たとえば、slurm.confに次の行を追加すると、ロックされたメモリ制限が伝達されなくなります。PropagateResourceLimitsExcept= MEMLOCK。

To control a user's access to a compute node:
計算ノードへのユーザーのアクセスを制御するには：

The pam_slurm_adopt and pam_slurm modules prevent users from logging into nodes that they have not been allocated (except for user root, which can always login).
pam_slurm_adoptモジュールとpam_slurmモジュールは、割り当てられていないノードにユーザーがログインできないようにします（常にログインできるユーザーrootを除く）。
 They are both included with the Slurm distribution.
どちらもSlurmディストリビューションに含まれています。

The pam_slurm_adopt module is highly recommended for most installations, and is documented in its own guide.
pam_slurm_adoptモジュールは、ほとんどのインストールで強く推奨されており、独自のガイドに記載されています。

pam_slurm is older and less functional.
pam_slurmは古く、機能的ではありません。
 These modules are built by default for RPM packages, but can be disabled using the .rpmmacros option "%_without_pam 1" or by entering the command line option "--without pam" when the configure program is executed.
これらのモジュールはRPMパッケージのデフォルトでビルドされますが、.rpmmacrosオプション "％_without_pam 1"を使用するか、configureプログラムの実行時にコマンドラインオプション "--without pam"を入力することで無効にできます。
 Their source code is in the "contribs/pam" and "contribs/pam_slurm_adopt" directories respectively.
それらのソースコードはそれぞれ「contribs / pam」および「contribs / pam_slurm_adopt」ディレクトリにあります。

The use of either pam_slurm_adopt or pam_slurm does not require UsePAM being set. The two uses of PAM are independent.
pam_slurm_adoptまたはpam_slurmを使用する場合、UsePAMを設定する必要はありません。PAMの2つの使用法は独立しています。

Why are jobs allocated nodes and then unable to initiate programs on some nodes?
ジョブがノードに割り当てられ、一部のノードでプログラムを開始できないのはなぜですか？

This typically indicates that the time on some nodes is not consistent with the node on which the slurmctld daemon executes.
これは通常、一部のノードの時間が、slurmctldデーモンが実行されるノードと一致していないことを示しています。
 In order to initiate a job step (or batch job), the slurmctld daemon generates a credential containing a time stamp.
ジョブステップ（またはバッチジョブ）を開始するために、slurmctldデーモンはタイムスタンプを含む資格情報を生成します。
 If the slurmd daemon receives a credential containing a time stamp later than the current time or more than a few minutes in the past, it will be rejected.
slurmdデーモンが、現在時刻よりも後のタイムスタンプまたは過去数分よりも長いタイムスタンプを含む資格情報を受け取った場合、それは拒否されます。
 If you check in the SlurmdLogFile on the nodes of interest, you will likely see messages of this sort: "Invalid job credential from <some IP address>: Job credential expired."
対象のノードでSlurmdLogFileをチェックインすると、次のようなメッセージが表示される可能性があります。 ：ジョブ資格情報の有効期限が切れています。」
 Make the times consistent across all of the nodes and all should be well.
すべてのノードで時間を一致させ、すべてが適切である必要があります。

Why does slurmctld log that some nodes are not responding even if they are not in any partition?
一部のノードがどのパーティションにもない場合でも、slurmctldが応答していないことをログに記録するのはなぜですか？

The slurmctld daemon periodically pings the slurmd daemon on every configured node, even if not associated with any partition.
slurmctldデーモンは、パーティションに関連付けられていない場合でも、構成されたすべてのノードのslurmdデーモンに定期的にpingします。
 You can control the frequency of this ping with the SlurmdTimeout configuration parameter in slurm.conf.
このpingの頻度は、slurm.confのSlurmdTimeout構成パラメーターで制御できます。

How should I relocate the primary or backup controller?
プライマリコントローラまたはバックアップコントローラを再配置するにはどうすればよいですか？

If the cluster's computers used for the primary or backup controller will be out of service for an extended period of time, it may be desirable to relocate them.
プライマリコントローラーまたはバックアップコントローラーに使用されているクラスターのコンピューターが長期間サービスを停止する場合は、それらを再配置することが望ましい場合があります。
 In order to do so, follow this procedure:
これを行うには、次の手順に従います。

  1. Stop all Slurm daemons
    すべてのSlurmデーモンを停止します
  2. Modify the SlurmctldHost values in the slurm.conf file
    slurm.confファイルのSlurmctldHost値を変更します
  3. Distribute the updated slurm.conf file to all nodes
    更新されたslurm.confファイルをすべてのノードに配布します
  4. Copy the StateSaveLocation directory to the new host and make sure the permissions allow the SlurmUser to read and write it.
    StateSaveLocationディレクトリーを新しいホストにコピーし、許可がSlurmUserによる読み取りと書き込みを許可していることを確認します。
  5. Restart all Slurm daemons
    すべてのSlurmデーモンを再起動します

There should be no loss of any running or pending jobs.
実行中または保留中のジョブが失われることはありません。
 Ensure that any nodes added to the cluster have a current slurm.conf file installed.
クラスターに追加されたすべてのノードに最新のslurm.confファイルがインストールされていることを確認します。
 CAUTION: If two nodes are simultaneously configured as the primary controller (two nodes on which SlurmctldHost specify the local host and the slurmctld daemon is executing on each), system behavior will be destructive.
注意：2つのノードが同時にプライマリコントローラーとして構成されている場合（SlurmctldHostがローカルホストを指定し、slurmctldデーモンがそれぞれで実行されている2つのノード）、システムの動作が破壊されます。
 If a compute node has an incorrect SlurmctldHost parameter, that node may be rendered unusable, but no other harm will result.
計算ノードに誤ったSlurmctldHostパラメーターがある場合、そのノードは使用できなくなる可能性がありますが、その他の害は発生しません。

Can multiple Slurm systems be run in parallel for testing purposes?
テスト目的で複数のSlurmシステムを並行して実行できますか？

Yes, this is a great way to test new versions of Slurm.
はい、これはSlurmの新しいバージョンをテストする優れた方法です。
 Just install the test version in a different location with a different slurm.conf.
slurm.confが異なる別の場所にテストバージョンをインストールするだけです。
 The test system's slurm.conf should specify different pathnames and port numbers to avoid conflicts.
テストシステムのslurm.confでは、競合を避けるために異なるパス名とポート番号を指定する必要があります。
 The only problem is if more than one version of Slurm is configured with burst_buffer/* plugins or others that may interact with external system APIs.
唯一の問題は、複数のバージョンのSlurmが、burst_buffer / *プラグイン、または外部システムAPIと相互作用する可能性のある他のプラグインで構成されている場合です。
 In that case, there can be conflicting API requests from the different Slurm systems.
その場合、異なるSlurmシステムからのAPIリクエストが競合する可能性があります。
 This can be avoided by configuring the test system with burst_buffer/none.
これは、burst_buffer / noneを使用してテストシステムを構成することで回避できます。

Can Slurm emulate a larger cluster?
Slurmはより大きなクラスターをエミュレートできますか？

Yes, this can be useful for testing purposes.
はい、これはテスト目的で役立ちます。
 It has also been used to partition "fat" nodes into multiple Slurm nodes.
また、「脂肪」ノードを複数のSlurmノードに分割するためにも使用されています。
 There are two ways to do this.
これを行うには2つの方法があります。
 The best method for most conditions is to run one slurmd daemon per emulated node in the cluster as follows.
ほとんどの状況に最適な方法は、次のように、クラスター内のエミュレートされたノードごとに1つのslurmdデーモンを実行することです。

  1. When executing the configure program, use the option --enable-multiple-slurmd (or add that option to your ~/.rpmmacros file).
    configureプログラムを実行するときは、オプション--enable-multiple-slurmdを使用します（または〜/ .rpmmacrosファイルにそのオプションを追加します）。
  2. Build and install Slurm in the usual manner.
    通常の方法でSlurmをビルドしてインストールします。
  3. In slurm.conf define the desired node names (arbitrary names used only by Slurm) as NodeName along with the actual address of the physical node in NodeHostname.
    slurm.confで、目的のノード名（Slurmでのみ使用される任意の名前）をNodeHostnameの物理ノードの実際のアドレスと共にNodeNameとして定義します。
     Multiple NodeName values can be mapped to a single NodeHostname.
    複数のNodeName値を単一のNodeHostnameにマップできます。
     Note that each NodeName on a single physical node needs to be configured to use a different port number (set Port to a unique value on each line for each node).
    単一の物理ノードの各NodeNameは、異なるポート番号を使用するように構成する必要があることに注意してください（Portを各ノードの各行で一意の値に設定します）。
     You will also want to use the "%n" symbol in slurmd related path options in slurm.conf (SlurmdLogFile and SlurmdPidFile).
    また、slurm.confのslurmd関連のパスオプション（SlurmdLogFileおよびSlurmdPidFile）で「％n」記号を使用することもできます。
  4. When starting the slurmd daemon, include the NodeName of the node that it is supposed to serve on the execute line (e.g. "slurmd -N hostname").
    slurmdデーモンを起動するときは、実行行で機能することになっているノードのNodeNameを含めます（たとえば、「slurmd -N hostname」）。
  5. This is an example of the slurm.conf file with the emulated nodes and ports configuration.
    これは、エミュレートされたノードとポートの構成を含むslurm.confファイルの例です。
     Any valid value for the CPUs, memory or other valid node resources can be specified.
    CPU、メモリ、またはその他の有効なノードリソースに有効な値を指定できます。
NodeName=dummy26[1-100] NodeHostName=achille Port=[6001-6100] NodeAddr=127.0.0.1 CPUs=4 RealMemory=6000
PartitionName=mira Default=yes Nodes=dummy26[1-100]

See the Programmers Guide for more details about configuring multiple slurmd support.
複数のslurmdサポートの構成の詳細については、プログラマガイドを参照してください。

In order to emulate a really large cluster, it can be more convenient to use a single slurmd daemon.
非常に大きなクラスターをエミュレートするには、単一のslurmdデーモンを使用する方が便利です。
 That daemon will not be able to launch many tasks, but can suffice for developing or testing scheduling software.
そのデーモンは多くのタスクを起動することはできませんが、スケジューリングソフトウェアの開発またはテストには十分です。
 Do not run job steps with more than a couple of tasks each or execute more than a few jobs at any given time.
一度に2つ以上のタスクを含むジョブステップを実行したり、同時にいくつかのジョブを実行したりしないでください。
 Doing so may result in the slurmd daemon exhausting its memory and failing.
これを行うと、slurmdデーモンがメモリを使い果たして失敗する可能性があります。
 Use this method with caution.
この方法は注意して使用してください。

  1. Execute the configure program with your normal options plus --enable-front-end (this will define HAVE_FRONT_END in the resulting config.h file.
    通常のオプションと--enable-front-endを指定してconfigureプログラムを実行します（これにより、生成されるconfig.hファイルでHAVE_FRONT_ENDが定義されます。
  2. Build and install Slurm in the usual manner.
    通常の方法でSlurmをビルドしてインストールします。
  3. In slurm.conf define the desired node names (arbitrary names used only by Slurm) as NodeName along with the actual name and address of the one physical node in NodeHostName and NodeAddr.
    slurm.confで、NodeHostNameとNodeAddrの1つの物理ノードの実際の名前とアドレスとともに、目的のノード名（Slurmでのみ使用される任意の名前）をNodeNameとして定義します。
     Up to 64k nodes can be configured in this virtual cluster.
    この仮想クラスターでは、最大64kのノードを構成できます。
  4. Start your slurmctld and one slurmd daemon.
    slurmctldと1つのslurmdデーモンを起動します。
     It is advisable to use the "-c" option to start the daemons without trying to preserve any state files from previous executions.
    「-c」オプションを使用して、以前の実行からの状態ファイルを保存しようとせずにデーモンを起動することをお勧めします。
     Be sure to use the "-c" option when switching from this mode too.
    このモードから切り替える場合も、必ず「-c」オプションを使用してください。
  5. Create job allocations as desired, but do not run job steps with more than a couple of tasks.
    必要に応じてジョブの割り当てを作成しますが、2つ以上のタスクでジョブステップを実行しないでください。
$ ./configure --enable-debug --enable-front-end --prefix=... --sysconfdir=...
$ make install
$ grep NodeHostName slurm.conf
NodeName=dummy[1-1200] NodeHostName=localhost NodeAddr=127.0.0.1
$ slurmctld -c
$ slurmd -c
$ sinfo
PARTITION AVAIL  TIMELIMIT NODES  STATE NODELIST
pdebug*      up      30:00  1200   idle dummy[1-1200]
$ cat tmp
#!/bin/bash
sleep 30
$ srun -N200 -b tmp
srun: jobid 65537 submitted
$ srun -N200 -b tmp
srun: jobid 65538 submitted
$ srun -N800 -b tmp
srun: jobid 65539 submitted
$ squeue
JOBID PARTITION  NAME   USER  ST  TIME  NODES NODELIST(REASON)
65537    pdebug   tmp  jette   R  0:03    200 dummy[1-200]
65538    pdebug   tmp  jette   R  0:03    200 dummy[201-400]
65539    pdebug   tmp  jette   R  0:02    800 dummy[401-1200]

Can Slurm emulate nodes with more resources than physically exist on the node?
Slurmは、ノードに物理的に存在するよりも多くのリソースを持つノードをエミュレートできますか？

Yes. In the slurm.conf file, configure SlurmdParameters=config_overrides and specify any desired node resource specifications (CPUs, Sockets, CoresPerSocket, ThreadsPerCore, and/or TmpDisk).
はい。slurm.confファイルで、SlurmdParameters = config_overridesを構成し、必要なノードリソース仕様（CPU、ソケット、CoresPerSocket、ThreadsPerCore、TmpDisk、あるいはその両方）を指定します。
 Slurm will use the resource specification for each node that is given in slurm.conf and will not check these specifications against those actually found on the node.
Slurmはslurm.confで指定された各ノードのリソース仕様を使用し、これらの仕様をノードで実際に検出された仕様と照合しません。
 The system would best be configured with TaskPlugin=task/none, so that launched tasks can run on any available CPU under operating system control.
システムはTaskPlugin = task / noneで構成するのが最適です。これにより、起動されたタスクは、オペレーティングシステムの制御下で使用可能な任意のCPUで実行できます。

What does a "credential replayed" error in the SlurmdLogFile indicate?
SlurmdLogFileの「資格情報の再生」エラーは何を示していますか？

This error is indicative of the slurmd daemon not being able to respond to job initiation requests from the srun command in a timely fashion (a few seconds).
このエラーは、slurmdデーモンがsrunコマンドからのジョブ開始要求に適時に（数秒）応答できないことを示しています。
 Srun responds by resending the job initiation request.
Srunは、ジョブ開始要求を再送信して応答します。
 When the slurmd daemon finally starts to respond, it processes both requests.
slurmdデーモンが最終的に応答を開始すると、両方の要求を処理します。
 The second request is rejected and the event is logged with the "credential replayed" error.
2番目の要求は拒否され、イベントは「資格情報の再生」エラーでログに記録されます。
 If you check the SlurmdLogFile and SlurmctldLogFile, you should see signs of the slurmd daemon's non-responsiveness.
SlurmdLogFileとSlurmctldLogFileを確認すると、slurmdデーモンが応答しない兆候が見られるはずです。
 A variety of factors can be responsible for this problem including
さまざまな要因がこの問題の原因である可能性があります

  • Diskless nodes encountering network problems
    ネットワークの問題が発生したディスクレスノード
  • Very slow Network Information Service (NIS)
    非常に遅いネットワーク情報サービス（NIS）
  • The Prolog script taking a long time to complete
    完了するのに長い時間がかかるPrologスクリプト

Configure MessageTimeout in slurm.conf to a value higher than the default 5 seconds.
slurm.confのMessageTimeoutをデフォルトの5秒より高い値に設定します。

What does "Warning: Note very large processing time" in the SlurmctldLogFile indicate?
SlurmctldLogFileの「警告：処理時間が非常に長いことに注意してください」とはどういう意味ですか？

This error is indicative of some operation taking an unexpectedly long time to complete, over one second to be specific.
このエラーは、特定の操作が完了するまでに予想以上に長い時間がかかり、1秒以上かかる操作があることを示しています。
 Setting the value of the SlurmctldDebug configuration parameter to debug2 or higher should identify which operation(s) are experiencing long delays.
SlurmctldDebug構成パラメータの値をdebug2以上に設定すると、長時間の遅延が発生している操作を特定できます。
 This message typically indicates long delays in file system access (writing state information or getting user information).
このメッセージは通常、ファイルシステムアクセスの長い遅延（状態情報の書き込みまたはユーザー情報の取得）を示します。
 Another possibility is that the node on which the slurmctld daemon executes has exhausted memory and is paging.
別の可能性としては、slurmctldデーモンが実行されるノードがメモリを使い果たし、ページングしている可能性があります。
 Try running the program top to check for this possibility.
プログラムtopを実行して、この可能性を確認してください。

Is resource limit propagation useful on a homogeneous cluster?
同種のクラスターでリソース制限の伝播は役に立ちますか？

Resource limit propagation permits a user to modify resource limits and submit a job with those limits.
リソース制限の伝播により、ユーザーはリソース制限を変更し、それらの制限を使用してジョブを送信できます。
 By default, Slurm automatically propagates all resource limits in effect at the time of job submission to the tasks spawned as part of that job.
デフォルトでは、Slurmは、ジョブのサブミット時に有効なすべてのリソース制限を、そのジョブの一部として生成されたタスクに自動的に伝達します。
 System administrators can utilize the PropagateResourceLimits and PropagateResourceLimitsExcept configuration parameters to change this behavior.
システム管理者は、PropagateResourceLimitsおよびPropagateResourceLimitsExcept構成パラメーターを使用して、この動作を変更できます。
 Users can override defaults using the srun --propagate option.
ユーザーは、srun --propagateオプションを使用してデフォルトを上書きできます。
 See "man slurm.conf" and "man srun" for more information about these options.
これらのオプションの詳細については、「man slurm.conf」および「man srun」を参照してください。

Do I need to maintain synchronized clocks on the cluster?
クラスターで同期クロックを維持する必要がありますか？

In general, yes. Having inconsistent clocks may cause nodes to be unusable.
一般的に、はい。一貫性のないクロックがあると、ノードが使用できなくなる可能性があります。
 Slurm log files should contain references to expired credentials. For example:
Slurmログファイルには、期限切れの認証情報への参照が含まれている必要があります。例えば：
 

error: Munge decode failed: Expired credential
ENCODED: Wed May 12 12:34:56 2008
DECODED: Wed May 12 12:01:12 2008

Why are "Invalid job credential" errors generated?
「無効なジョブ資格情報」エラーが生成されるのはなぜですか？

This error is indicative of Slurm's job credential files being inconsistent across the cluster.
このエラーは、Slurmのジョブ資格情報ファイルがクラスター全体で一貫していないことを示しています。
 All nodes in the cluster must have the matching public and private keys as defined by JobCredPrivateKey and JobCredPublicKey in the Slurm configuration file slurm.conf.
クラスター内のすべてのノードには、Slurm構成ファイルslurm.confのJobCredPrivateKeyおよびJobCredPublicKeyで定義されている一致する公開鍵と秘密鍵が必要です。

Why are "Task launch failed on node ... Job credential replayed" errors generated?
「ノードでタスクの起動に失敗しました...ジョブ資格情報が再生されました」というエラーが生成されるのはなぜですか？

This error indicates that a job credential generated by the slurmctld daemon corresponds to a job that the slurmd daemon has already revoked.
このエラーは、slurmctldデーモンによって生成されたジョブ資格情報が、slurmdデーモンがすでに取り消したジョブに対応していることを示しています。
 The slurmctld daemon selects job ID values based upon the configured value of FirstJobId (the default value is 1) and each job gets a value one larger than the previous job.
slurmctldデーモンは、FirstJobIdの構成された値（デフォルト値は1）に基づいてジョブID値を選択し、各ジョブは前のジョブより1つ大きい値を取得します。
 On job termination, the slurmctld daemon notifies the slurmd on each allocated node that all processes associated with that job should be terminated.
ジョブの終了時に、slurmctldデーモンは、割り当てられた各ノードのslurmdに、そのジョブに関連付けられたすべてのプロセスを終了する必要があることを通知します。
 The slurmd daemon maintains a list of the jobs which have already been terminated to avoid replay of task launch requests.
slurmdデーモンは、タスクの起動要求の再生を回避するために、すでに終了したジョブのリストを維持します。
 If the slurmctld daemon is cold-started (with the "-c" option or "/etc/init.d/slurm startclean"), it starts job ID values over based upon FirstJobId.
slurmctldデーモンが（「-c」オプションまたは「/etc/init.d/slurm startclean」を使用して）コールドスタートされている場合、FirstJobIdに基づいてジョブID値を開始します。
 If the slurmd is not also cold-started, it will reject job launch requests for jobs that it considers terminated.
slurmdもコールドスタートされていない場合、終了したと見なされるジョブのジョブ起動要求を拒否します。
 This solution to this problem is to cold-start all slurmd daemons whenever the slurmctld daemon is cold-started.
この問題のこの解決策は、slurmctldデーモンがコールドスタートされるたびに、すべてのslurmdデーモンをコールドスタートすることです。

Can Slurm be used with Globus?
SlurmをGlobusで使用できますか？

Yes. Build and install Slurm's Torque/PBS command wrappers along with the Perl APIs from Slurm's contribs directory and configure Globus to use those PBS commands.
はい。SlurmのcontribsディレクトリからPerl APIとともにSlurmのTorque / PBSコマンドラッパーをビルドしてインストールし、それらのPBSコマンドを使用するようにGlobusを構成します。
 Note there are RPMs available for both of these packages, named torque and perlapi respectively.
これらのパッケージの両方で利用可能なRPMがあり、それぞれトルクとperlapiと名付けられています。

What causes the error "Unable to accept new connection: Too many open files"?
「新しい接続を受け入れることができません：開いているファイルが多すぎます」というエラーの原因は何ですか？

The srun command automatically increases its open file limit to the hard limit in order to process all of the standard input and output connections to the launched tasks.
srunコマンドは、起動されたタスクへのすべての標準入出力接続を処理するために、開いているファイルの制限をハード制限に自動的に増やします。
 It is recommended that you set the open file hard limit to 8192 across the cluster.
クラスター全体で、オープンファイルのハード制限を8192に設定することをお勧めします。

Why does the setting of SlurmdDebug fail to log job step information at the appropriate level?
SlurmdDebugの設定がジョブステップ情報を適切なレベルでログに記録できないのはなぜですか？

There are two programs involved here.
ここには2つのプログラムが関係しています。
 One is slurmd, which is a persistent daemon running at the desired debug level.
1つはslurmdです。これは、目的のデバッグレベルで実行される永続的なデーモンです。
 The second program is slurmstepd, which executes the user job and its debug level is controlled by the user.
2番目のプログラムはslurmstepdで、ユーザージョブを実行し、そのデバッグレベルはユーザーによって制御されます。
 Submitting the job with an option of --debug=# will result in the desired level of detail being logged in the SlurmdLogFile plus the output of the program.
--debug =＃のオプションを指定してジョブを送信すると、SlurmdLogFileとプログラムの出力に、必要な詳細レベルが記録されます。

Why aren't pam_slurm.so, auth_none.so, or other components in a Slurm RPM?
Slurm RPMにpam_slurm.so、auth_none.so、またはその他のコンポーネントがないのはなぜですか？

It is possible that at build time the required dependencies for building the library are missing.
ビルド時に、ライブラリのビルドに必要な依存関係が欠落している可能性があります。
 If you want to build the library then install pam-devel and compile again.
ライブラリをビルドする場合は、pam-develをインストールして、再度コンパイルします。
 See the file slurm.spec in the Slurm distribution for a list of other options that you can specify at compile time with rpmbuild flags and your rpmmacros file.
rpmbuildフラグとrpmmacrosファイルを使用してコンパイル時に指定できるその他のオプションのリストについては、Slurmディストリビューションのslurm.specファイルを参照してください。
 The auth_none plugin is in a separate RPM and not built by default.
auth_noneプラグインは別のRPMにあり、デフォルトではビルドされません。
 Using the auth_none plugin means that Slurm communications are not authenticated, so you probably do not want to run in this mode of operation except for testing purposes.
auth_noneプラグインを使用することは、Slurm通信が認証されないことを意味します。したがって、テスト目的を除いて、この操作モードで実行したくないでしょう。
 If you want to build the auth_none RPM then add --with auth_none on the rpmbuild command line or add %_with_auth_none to your ~/rpmmacros file.
auth_none RPMをビルドする場合は、rpmbuildコマンドラインで--with auth_noneを追加するか、％/ with_auth_noneを〜/ rpmmacrosファイルに追加します。
 See the file slurm.spec in the Slurm distribution for a list of other options.
他のオプションのリストについては、Slurmディストリビューションのslurm.specファイルを参照してください。

Why should I use the slurmdbd instead of the regular database plugins?
通常のデータベースプラグインの代わりにslurmdbdを使用する必要があるのはなぜですか？

While the normal storage plugins will work fine without the added layer of the slurmdbd there are some great benefits to using the slurmdbd.
通常のストレージプラグインはslurmdbdのレイヤーを追加しなくても正常に動作しますが、slurmdbdを使用することにはいくつかの大きな利点があります。

  1. Added security. Using the slurmdbd you can have an authenticated connection to the database.
    セキュリティを追加しました。slurmdbdを使用すると、データベースへの認証された接続を確立できます。
  2. Offloading processing from the controller. With the slurmdbd there is no slowdown to the controller due to a slow or overloaded database.
    コントローラーからの処理のオフロード。slurmdbdを使用すると、データベースの速度が低下したり、データベースが過負荷になったりしても、コントローラーの速度が低下することはありません。
  3. Keeping enterprise wide accounting from all Slurm clusters in one database. The slurmdbd is multi-threaded and designed to handle all the accounting for the entire enterprise.
    すべてのSlurmクラスターからの企業全体の会計を1つのデータベースに保持します。slurmdbdはマルチスレッドであり、企業全体のすべてのアカウンティングを処理するように設計されています。
  4. With the database plugins you can query with sacct accounting stats from any node Slurm is installed on. With the slurmdbd you can also query any cluster using the slurmdbd from any other cluster's nodes. Other tools like sreport are also available.
    データベースプラグインを使用すると、Slurmがインストールされている任意のノードからsacctアカウンティング統計でクエリを実行できます。slurmdbdを使用すると、他のクラスターのノードからslurmdbdを使用して任意のクラスターをクエリすることもできます。sreportなどの他のツールも使用できます。

How can I build Slurm with debugging symbols?
デバッグシンボルを使用してSlurmをビルドするにはどうすればよいですか？

When configuring, run the configure script with --enable-developer option.
構成するときは、-enable-developerオプションを指定して構成スクリプトを実行します。
 That will provide asserts, debug messages and the -Werror flag, that will in turn activate --enable-debug.
これにより、アサート、デバッグメッセージ、および-Werrorフラグが提供され、次に--enable-debugがアクティブになります。
With the --enable-debug flag, the code will be compiled with -ggdb3 and -g -O1 -fno-strict-aliasing flags that will produce extra debugging information.
--enable-debugフラグを使用すると、コードは-ggdb3および-g -O1 -fno-strict-aliasingフラグを使用してコンパイルされ、追加のデバッグ情報が生成されます。
 Another possible option to use is --disable-optimizations that will set -O0.
使用できるもう1つのオプションは、-O0を設定する--disable-optimizationsです。
 See also auxdir/x_ac_debug.m4 for more details.
詳細については、auxdir / x_ac_debug.m4も参照してください。

How can I easily preserve drained node information between major Slurm updates?
Slurmの主要な更新間でドレインされたノード情報を簡単に保持するにはどうすればよいですか？

Major Slurm updates generally have changes in the state save files and communication protocols, so a cold-start (without state) is generally required.
Slurmのメジャーアップデートでは通常、状態保存ファイルと通信プロトコルが変更されるため、通常はコールドスタート（状態なし）が必要です。
 If you have nodes in a DRAIN state and want to preserve that information, you can easily build a script to preserve that information using the sinfo command.
ノードがDRAIN状態でその情報を保持したい場合は、sinfoコマンドを使用して、その情報を保持するスクリプトを簡単に作成できます。
 The following command line will report the Reason field for every node in a DRAIN state and write the output in a form that can be executed later to restore state.
次のコマンドラインは、DRAIN状態のすべてのノードのReasonフィールドを報告し、後で実行して状態を復元できる形式で出力を書き込みます。
 

sinfo -t drain -h -o "scontrol update nodename='%N' state=drain reason='%E'"

Why doesn't the HealthCheckProgram execute on DOWN nodes?
HealthCheckProgramがDOWNノードで実行されないのはなぜですか？

Hierarchical communications are used for sending this message.
このメッセージの送信には階層通信が使用されます。
 If there are DOWN nodes in the communications hierarchy, messages will need to be re-routed.
通信階層にDOWNノードがある場合は、メッセージを再ルーティングする必要があります。
 This limits Slurm's ability to tightly synchronize the execution of the HealthCheckProgram across the cluster, which could adversely impact performance of parallel applications.
これにより、クラスター全体でHealthCheckProgramの実行を緊密に同期するSlurmの機能が制限され、並列アプリケーションのパフォーマンスに悪影響を与える可能性があります。
 The use of CRON or node startup scripts may be better suited to ensure that HealthCheckProgram gets executed on nodes that are DOWN in Slurm.
CRONまたはノード起動スクリプトの使用は、SlurmでダウンしているノードでHealthCheckProgramが確実に実行されるようにするのに適している場合があります。

What is the meaning of the error "Batch JobId=# missing from batch node <node> (not found BatchStartTime after startup)"?
「バッチノードにバッチジョブID =＃がありません」というエラーの意味は何ですか （起動後にBatchStartTimeが見つかりません） "？

A shell is launched on node zero of a job's allocation to execute the submitted program.
シェルは、ジョブの割り当てのノード0で起動され、送信されたプログラムを実行します。
 The slurmd daemon executing on each compute node will periodically report to the slurmctld what programs it is executing.
各計算ノードで実行されているslurmdデーモンは、実行しているプログラムをslurmctldに定期的に報告します。
 If a batch program is expected to be running on some node (i.e. node zero of the job's allocation) and is not found, the message above will be logged and the job canceled.
バッチプログラムが何らかのノード（つまり、ジョブの割り当てのノード0）で実行されていると予想され、見つからない場合、上記のメッセージがログに記録され、ジョブがキャンセルされます。
 This typically is associated with exhausting memory on the node or some other critical failure that cannot be recovered from.
これは通常、ノードのメモリの枯渇、または回復できないその他の重大な障害に関連しています。

What does the message "srun: error: Unable to accept connection: Resources temporarily unavailable" indicate?
「srun：エラー：接続を受け入れることができません：リソースが一時的に利用できません」というメッセージは何を示していますか？

This has been reported on some larger clusters running SUSE Linux when a user's resource limits are reached.
これは、ユーザーのリソース制限に達したときに、SUSE Linuxを実行している一部の大規模クラスターで報告されています。
 You may need to increase limits for locked memory and stack size to resolve this problem.
この問題を解決するには、ロックされたメモリとスタックサイズの制限を増やす必要がある場合があります。

How could I automatically print a job's Slurm job ID to its standard output?
ジョブのSlurmジョブIDを標準出力に自動的に印刷するにはどうすればよいですか？

The configured TaskProlog is the only thing that can write to the job's standard output or set extra environment variables for a job or job step.
構成されたTaskPrologは、ジョブの標準出力に書き込むか、ジョブまたはジョブステップに追加の環境変数を設定できる唯一のものです。
 To write to the job's standard output, precede the message with "print ".
ジョブの標準出力に書き込むには、メッセージの前に「print」を付けます。
 To export environment variables, output a line of this form "export name=value".
環境変数をエクスポートするには、「export name = value」という形式の行を出力します。
 The example below will print a job's Slurm job ID and allocated hosts for a batch job only.
以下の例では、ジョブのSlurmジョブIDと、バッチジョブにのみ割り当てられたホストを出力します。
 

#!/bin/sh
#
# Sample TaskProlog script that will print a batch job's
# job ID and node list to the job's stdout
#

if [ X"$SLURM_STEP_ID" = "X" -a X"$SLURM_PROCID" = "X"0 ]
then
  echo "print =========================================="
  echo "print SLURM_JOB_ID = $SLURM_JOB_ID"
  echo "print SLURM_JOB_NODELIST = $SLURM_JOB_NODELIST"
  echo "print =========================================="
fi

Why are user processes and srun running even though the job is supposed to be completed?
ジョブが完了しているはずなのに、ユーザープロセスとsrunが実行されているのはなぜですか？

Slurm relies upon a configurable process tracking plugin to determine when all of the processes associated with a job or job step have completed.
Slurmは、構成可能なプロセス追跡プラグインに依存して、ジョブまたはジョブステップに関連付けられたすべてのプロセスがいつ完了したかを判断します。
 Those plugins relying upon a kernel patch can reliably identify every process.
カーネルパッチに依存するプラグインは、すべてのプロセスを確実に識別できます。
 Those plugins dependent upon process group IDs or parent process IDs are not reliable.
プロセスグループIDまたは親プロセスIDに依存するプラグインは信頼できません。
 See the ProctrackType description in the slurm.conf man page for details.
詳細については、slurm.confのmanページにあるProctrackTypeの説明を参照してください。
 We rely upon the cgroup plugin for most systems.
ほとんどのシステムではcgroupプラグインに依存しています。

How can I prevent the slurmd and slurmstepd daemons from being killed when a node's memory is exhausted?
ノードのメモリが使い果たされたときにslurmdとslurmstepdデーモンが強制終了されるのを防ぐにはどうすればよいですか？

You can set the value in the /proc/self/oom_adj for slurmd and slurmstepd by initiating the slurmd daemon with the SLURMD_OOM_ADJ and/or SLURMSTEPD_OOM_ADJ environment variables set to the desired values.
SLURMD_OOM_ADJまたはSLURMSTEPD_OOM_ADJ環境変数を目的の値に設定してslurmdデーモンを開始することにより、slururdおよびslurmstepdの/ proc / self / oom_adjに値を設定できます。
 A value of -17 typically will disable killing.
値-17は通常、強制終了を無効にします。

I see the host of my calling node as 127.0.1.1 instead of the correct IP address. Why is that?
呼び出し元ノードのホストが正しいIPアドレスではなく127.0.1.1として表示されます。何故ですか？

Some systems by default will put your host in the /etc/hosts file as something like
一部のシステムでは、デフォルトで/ etc / hostsファイルに次のようにホストを配置します

127.0.1.1	snowflake.llnl.gov	snowflake

This will cause srun and Slurm commands to use the 127.0.1.1 address instead of the correct address and prevent communications between nodes.
これにより、srunおよびSlurmコマンドは正しいアドレスの代わりに127.0.1.1アドレスを使用し、ノード間の通信を妨げます。
 The solution is to either remove this line or configure a different NodeAddr that is known by your other nodes.
解決策は、この行を削除するか、他のノードが認識している別のNodeAddrを構成することです。

The CommunicationParameters=NoInAddrAny configuration parameter is subject to this same problem, which can also be addressed by removing the actual node name from the "127.0.1.1" as well as the "127.0.0.1" addresses in the /etc/hosts file.
CommunicationParameters = NoInAddrAny構成パラメーターもこの同じ問題の影響を受けます。この問題は、/ etc / hostsファイルの「127.0.1.1」および「127.0.0.1」アドレスから実際のノード名を削除することによっても対処できます。
 It is ok if they point to localhost, but not the actual name of the node.
localhostを指していても問題ありませんが、実際のノード名は指していません。

How can I stop Slurm from scheduling jobs?
Slurmでジョブのスケジュールを停止するにはどうすればよいですか？

You can stop Slurm from scheduling jobs on a per partition basis by setting that partition's state to DOWN.
Slurmがパーティションの状態をDOWNに設定することにより、パーティションごとにジョブをスケジュールするのを停止できます。
 Set its state UP to resume scheduling. For example:
状態をUPに設定して、スケジューリングを再開します。例えば：
 

$ scontrol update PartitionName=foo State=DOWN
$ scontrol update PartitionName=bar State=UP

Can I update multiple jobs with a single scontrol command?
1つのscontrolコマンドで複数のジョブを更新できますか？

No, but you can probably use squeue to build the script taking advantage of its filtering and formatting options. For example:
いいえ。ただし、squeueを使用して、フィルタリングとフォーマットのオプションを利用してスクリプトを作成できます。例えば：
 

$ squeue -tpd -h -o "scontrol update jobid=%i priority=1000" >my.script

Can Slurm be used to run jobs on Amazon's EC2?
Slurmを使用してAmazonのEC2でジョブを実行できますか？

Yes, here is a description of Slurm use with Amazon's EC2 courtesy of Ashley Pittman:
はい、アシュリーピットマンの厚意により、AmazonのEC2でのSlurmの使用について説明します。

I do this regularly and have no problem with it, the approach I take is to start as many instances as I want and have a wrapper around ec2-describe-instances that builds a /etc/hosts file with fixed hostnames and the actual IP addresses that have been allocated.
私はこれを定期的に行って問題はありません。私が取るアプローチは、必要な数のインスタンスを開始し、固定ホスト名と実際のIPアドレスを含む/ etc / hostsファイルを構築するec2-describe-instancesのラッパーを使用することです。割り当てられています。
 The only other step then is to generate a slurm.conf based on how many node you've chosen to boot that day.
次に、他の唯一の手順は、その日に起動するように選択したノードの数に基づいてslurm.confを生成することです。
 I run this wrapper script on my laptop and it generates the files and they rsyncs them to all the instances automatically.
私はラップトップでこのラッパースクリプトを実行すると、ファイルが生成され、自動的にすべてのインスタンスにrsyncされます。

One thing I found is that Slurm refuses to start if any nodes specified in the slurm.conf file aren't resolvable, I initially tried to specify cloud[0-15] in slurm.conf, but then if I configure less than 16 nodes in /etc/hosts this doesn't work so I dynamically generate the slurm.conf as well as the hosts file.
私が見つけた1つのことは、slurm.confファイルで指定されたノードが解決できない場合、Slurmが起動を拒否することです。最初にslurm.confでcloud [0-15]を指定しようとしましたが、16ノード未満を構成した場合/ etc / hostsではこれは機能しないため、slurm.confおよびhostsファイルを動的に生成します。

As a comment about EC2 I run just run generic AMIs and have a persistent EBS storage device which I attach to the first instance when I start up.
EC2についてのコメントとして、私は一般的なAMIを実行し、起動時に最初のインスタンスに接続する永続的なEBSストレージデバイスを実行しています。
 This contains a /usr/local which has my software like Slurm, pdsh and MPI installed which I then copy over the /usr/local on the first instance and NFS export to all other instances.
これには、Slurm、pdsh、MPIなどのソフトウェアがインストールされた/ usr / localが含まれており、最初のインスタンスの/ usr / localにコピーし、他のすべてのインスタンスにNFSエクスポートします。
 This way I have persistent home directories and a very simple first-login script that configures the virtual cluster for me.
このように、永続的なホームディレクトリと、仮想クラスターを構成する非常に単純な初回ログインスクリプトを用意しています。

If a Slurm daemon core dumps, where can I find the core file?
Slurmデーモンコアダンプの場合、コアファイルはどこにありますか？

If slurmctld is started with the -D option, then the core file will be written to the current working directory.
slurmctldが-Dオプションを指定して開始された場合、コアファイルは現在の作業ディレクトリに書き込まれます。
 If SlurmctldLogFile is an absolute path, the core file will be written to this directory.
SlurmctldLogFileが絶対パスの場合、コアファイルはこのディレクトリに書き込まれます。
 Otherwise the core file will be written to the StateSaveLocation, or "/var/tmp/" as a last resort.
それ以外の場合、コアファイルはStateSaveLocationまたは「/ var / tmp /」に最後の手段として書き込まれます。

SlurmUser must have write permission on the directories.
SlurmUserには、ディレクトリに対する書き込み権限が必要です。
 If none of the above directories have write permission for SlurmUser, no core file will be produced.
上記のディレクトリのいずれにもSlurmUserに対する書き込み権限がない場合、コアファイルは生成されません。
 For testing purposes the command "scontrol abort" can be used to abort the slurmctld daemon and generate a core file.
テストの目的で、コマンド「scontrol abort」を使用して、slurmctldデーモンを中止し、コアファイルを生成できます。

If slurmd is started with the -D option, then the core file will also be written to the current working directory.
slurmdが-Dオプションを指定して開始された場合、コアファイルも現在の作業ディレクトリに書き込まれます。
 If SlurmdLogFile is an absolute path, the core file will be written to the this directory.
SlurmdLogFileが絶対パスの場合、コアファイルはthisディレクトリに書き込まれます。
 Otherwise the core file will be written to the SlurmdSpoolDir, or "/var/tmp/" as a last resort.
それ以外の場合、コアファイルはSlurmdSpoolDir、または "/ var / tmp /"に最後の手段として書き込まれます。

If none of the above directories can be written, no core file will be produced.
上記のディレクトリのいずれも書き込むことができない場合、コアファイルは生成されません。

For slurmstepd, the core file will depend upon when the failure occurs.
slurmstepdの場合、コアファイルはいつ障害が発生するかによって異なります。
 If it is running in a privileged phase, it will be in the same location as that described above for the slurmd daemon.
特権フェーズで実行されている場合、上記のslurmdデーモンと同じ場所にあります。
 If it is running in an unprivileged phase, it will be in the spawned job's working directory.
非特権フェーズで実行されている場合、生成されたジョブの作業ディレクトリになります。

Nevertheless, in some operating systems this can vary:
それにもかかわらず、一部のオペレーティングシステムでは、これは異なる場合があります。

  • I.e. in RHEL the event may be captured by abrt daemon and generated in the defined abrt configured dump location (i.e. /var/spool/abrt).
    つまり、RHELでは、イベントはabrtデーモンによってキャプチャされ、定義されたabrt構成のダンプの場所（つまり、/ var / spool / abrt）で生成されます。
  • In Cray XC ATP (Abnormal Termination Processing) daemon acts the same way, if it is enabled.
    Cray XCでは、ATP（異常終了処理）デーモンは、有効になっている場合、同じように動作します。

Normally, distributions need some more tweaking in order to allow the core files to be generated correctly.
通常、ディストリビューションでは、コアファイルを正しく生成するために、さらに調整が必要です。

slurmstepd uses the setuid() (set user ID) function to escalate privileges.
slurmstepdは、setuid（）（ユーザーIDの設定）関数を使用して特権を昇格させます。
 It is possible that in certain systems and for security policies, this causes the core files not to be generated.
特定のシステムおよびセキュリティポリシーでは、コアファイルが生成されない可能性があります。
To allow the generation in such systems you usually must enable the suid_dumpable kernel parameter:
このようなシステムで生成できるようにするには、通常、suid_dumpableカーネルパラメータを有効にする必要があります。

Set:
/proc/sys/fs/suid_dumpable to 2
or
sysctl fs.suid_dumpable=2

or set it permanently in sysctl.conf
または、sysctl.confに永続的に設定します

fs.suid_dumpable = 2

The value of 2, "suidsafe", makes any binary which normally not be dumped is dumped readable by root only.
2の値「suidsafe」は、通常はダンプされないバイナリを、rootだけが読み取り可能にダンプできるようにします。

This allows the end user to remove such a dump but not access it directly.
これにより、エンドユーザーはそのようなダンプを削除できますが、直接アクセスすることはできません。
 For security reasons core dumps in this mode will not overwrite one another or other files.
セキュリティ上の理由から、このモードのコアダンプは、他のファイルや他のファイルを上書きしません。

This mode is appropriate when administrators are attempting to debug problems in a normal environment.
このモードは、管理者が通常の環境で問題をデバッグしようとしている場合に適しています。

Then you must also set the core pattern to an absolute pathname:
次に、コアパターンを絶対パス名に設定する必要があります。

sysctl kernel.core_pattern=/tmp/core.%e.%p

We recommend reading your distribution's documentation about the configuration of these parameters.
これらのパラメータの設定については、ディストリビューションのドキュメントを読むことをお勧めします。

It is also usually needed to configure the system core limits, since it can be set to 0.
また、0に設定できるため、システムのコア制限を構成するためにも必要です。

$ grep core /etc/security/limits.conf
#        - core - limits the core file size (KB)
*               hard    core            unlimited
*               soft    core            unlimited

In some systems it is not enough to set a hard limit, you must set also a soft limit.
一部のシステムでは、ハード制限を設定するだけでは不十分で、ソフト制限も設定する必要があります。

Also, for generating the limits in userspace, the PropagateResourceLimits=CORE parameter in slurm.conf could be needed.
また、ユーザー空間で制限を生成するには、slurm.confのPropagateResourceLimits = COREパラメータが必要になる場合があります。

Be also sure to give SlurmUser the appropriate permissions to write in the core location directories.
また、コアロケーションディレクトリに書き込むための適切な権限をSlurmUserに付与してください。

NOTE: On a diskless node depending on the core_pattern or if /var/spool/abrt is pointing to an in-memory filespace like tmpfs, if the job caused an OOM, then the generation of the core may fill up your machine's memory and hang it.
注：core_patternに依存するディスクレスノード上、または/ var / spool / abrtがtmpfsなどのメモリ内ファイルスペースを指している場合、ジョブがOOMを引き起こした場合、コアの生成がマシンのメモリをいっぱいにしてハングする可能性があります。それ。
 It is encouraged then to make coredumps go to a persistent storage.
コアダンプを永続的なストレージに移動させることをお勧めします。
 Be careful of multiple nodes writting a core dump to a shared filesystem since it may significantly impact it.
共有ファイルシステムにコアダンプを書き込む複数のノードには、大きな影響を与える可能性があるので注意してください。

Other exceptions:

On Centos 6, also set "ProcessUnpackaged = yes" in the file /etc/abrt/abrt-action-save-package-data.conf.
Centos 6では、/ etc / abrt / abrt-action-save-package-data.confファイルで「ProcessUnpackaged = yes」も設定します。

On RHEL6, also set "DAEMON_COREFILE_LIMIT=unlimited" in the file rc.d/init.d/functions.
RHEL6では、rc.d / init.d / functionsファイルで「DAEMON_COREFILE_LIMIT = unlimited」も設定します。

On a SELinux enabled system, or on a distribution with similar security system, get sure it is allowing to dump cores:
SELinux対応システム、または同様のセキュリティシステムを備えたディストリビューションで、コアをダンプできることを確認します。

$ getsebool allow_daemons_dump_core

coredumpctl can also give valuable information:
coredumpctlも貴重な情報を提供します：

$ coredumpctl info

How can TotalView be configured to operate with Slurm?
TotalViewをSlurmで動作するように構成するにはどうすればよいですか？

The following lines should also be added to the global .tvdrc file for TotalView to operate with Slurm:
TotalViewがSlurmで動作するように、次の行もグローバル.tvdrcファイルに追加する必要があります。
 

# Enable debug server bulk launch: Checked
dset -set_as_default TV::bulk_launch_enabled true

# Command:
# Beginning with TV 7X.1, TV supports Slurm and %J.
# Specify --mem-per-cpu=0 in case Slurm configured with default memory
# value and we want TotalView to share the job's memory limit without
# consuming any of the job's memory so as to block other job steps.
dset -set_as_default TV::bulk_launch_string {srun --mem-per-cpu=0 -N%N -n%N -w`awk -F. 'BEGIN {ORS=","} {if (NR==%N) ORS=""; print $1}' %t1` -l --input=none %B/tvdsvr%K -callback_host %H -callback_ports %L -set_pws %P -verbosity %V -working_directory %D %F}

# Temp File 1 Prototype:
# Host Lines:
# Slurm NodeNames need to be unadorned hostnames. In case %R returns
# fully qualified hostnames, list the hostnames in %t1 here, and use
# awk in the launch string above to strip away domain name suffixes.
dset -set_as_default TV::bulk_launch_tmpfile1_host_lines {%R}

How can a patch file be generated from a Slurm commit in GitHub?
GitHubのSlurmコミットからパッチファイルを生成するにはどうすればよいですか？

Find and open the commit in GitHub then append ".patch" to the URL and save the resulting file. For an example, see:
GitHubでコミットを見つけて開き、URLに「.patch」を追加して、結果のファイルを保存します。例については、以下を参照してください。
 https://github.com/SchedMD/slurm/commit/91e543d433bed11e0df13ce0499be641774c99a3.patch

Why are the resource limits set in the database not being enforced?
データベースに設定されているリソース制限が適用されないのはなぜですか？

In order to enforce resource limits, set the value of AccountingStorageEnforce in each cluster's slurm.conf configuration file appropriately.
リソース制限を実施するには、各クラスターのslurm.conf構成ファイルでAccountingStorageEnforceの値を適切に設定します。
 If AccountingStorageEnforce does not contains an option of "limits", then resource limits will not be enforced on that cluster.
AccountingStorageEnforceに「制限」のオプションが含まれていない場合、リソース制限はそのクラスターに適用されません。
 See Resource Limits for more information.
詳細については、リソース制限を参照してください。

After manually setting a job priority value, how can its priority value be returned to being managed by the priority/multifactor plugin?
ジョブの優先度の値を手動で設定した後、優先度の値を優先度/多要素プラグインによる管理に戻すにはどうすればよいですか？

Hold and then release the job as shown below.
以下に示すように、ジョブをホールドしてからリリースします。

$ scontrol hold <jobid>
$ scontrol release <jobid>

Does anyone have an example node health check script for Slurm?
誰かがSlurmのノードヘルスチェックスクリプトの例を持っていますか？

Probably the most comprehensive and lightweight health check tool out there is Node Health Check.
おそらく、最も包括的で軽量なヘルスチェックツールはノードヘルスチェックです。
 It has integration with Slurm as well as Torque resource managers.
SlurmおよびTorqueリソースマネージャと統合されています。

What process should I follow to add nodes to Slurm?
ノードをSlurmに追加するには、どのプロセスに従う必要がありますか？

The slurmctld daemon has a multitude of bitmaps to track state of nodes and cores in the system.
slurmctldデーモンには、システム内のノードとコアの状態を追跡するための多数のビットマップがあります。
 Adding nodes to a running system would require the slurmctld daemon to rebuild all of those bitmaps, which the developers feel would be safer to do by restarting the daemon.
実行中のシステムにノードを追加するには、slurmctldデーモンがそれらのビットマップをすべて再構築する必要があります。開発者は、デーモンを再起動することで安全に行うことができます。
 Communications from the slurmd daemons on the compute nodes to the slurmctld daemon include a configuration file checksum, so you probably also want to maintain a common slurm.conf file on all nodes.
計算ノード上のslurmdデーモンからslurmctldデーモンへの通信には構成ファイルのチェックサムが含まれているため、すべてのノードで共通のslurm.confファイルも維持する必要があります。
 The following procedure is recommended:
次の手順をお勧めします。

  1. Stop the slurmctld daemon (e.g. "systemctl stop slurmctld" on the head node)
    slurmctldデーモンを停止します（たとえば、ヘッドノードの「systemctl stop slurmctld」）
  2. Update the slurm.conf file on all nodes in the cluster
    クラスター内のすべてのノードでslurm.confファイルを更新します
  3. Restart the slurmd daemons on all nodes (e.g. "systemctl restart slurmd" on all nodes)
    すべてのノードでslurmdデーモンを再起動します（たとえば、すべてのノードで「systemctl restart slurmd」）
  4. Restart the slurmctld daemon (e.g. "systemctl start slurmctld" on the head node)
    slurmctldデーモンを再起動します（たとえば、ヘッドノードで「systemctl start slurmctld」）

NOTE: Jobs submitted with srun, and that are waiting for an allocation, prior to new nodes being added to the slurm.conf can fail if the job is allocated one of the new nodes.
注記：新しいノードがslurm.confに追加される前に、srunで送信され、割り当てを待機しているジョブは、ジョブが新しい​​ノードの1つに割り当てられている場合、失敗する可能性があります。

Can Slurm be configured to manage licenses?
ライセンスを管理するようにSlurmを構成できますか？

Slurm is not currently integrated with FlexLM, but it does provide for the allocation of global resources called licenses.
Slurmは現在FlexLMと統合されていませんが、ライセンスと呼ばれるグローバルリソースの割り当てを提供します。
 Use the Licenses configuration parameter in your slurm.conf file (e.g. "Licenses=foo:10,bar:20").
slurm.confファイルでLicenses構成パラメーターを使用します（例： "Licenses = foo：10、bar：20"）。
 Jobs can request licenses and be granted exclusive use of those resources (e.g. "sbatch --licenses=foo:2,bar:1 ...").
ジョブはライセンスを要求し、それらのリソースの排他的使用を許可することができます（例： "sbatch --licenses = foo：2、bar：1 ..."）。
 It is not currently possible to change the total number of licenses on a system without restarting the slurmctld daemon, but it is possible to dynamically reserve licenses and remove them from being available to jobs on the system (e.g. "scontrol update reservation=licenses_held licenses=foo:5,bar:2").
現在、slurmctldデーモンを再起動せずにシステム上のライセンスの総数を変更することはできませんが、ライセンスを動的に予約して、システム上のジョブで使用できないようにすることができます（例： "scontrol update reservation = licenses_held licenses = foo：5、bar：2 "）。

Can the salloc command be configured to launch a shell on a node in the job's allocation?
ジョブの割り当てのノードでシェルを起動するようにsallocコマンドを構成できますか？

Yes, just use the SallocDefaultCommand configuration parameter in your slurm.conf file as shown below.
はい、以下に示すように、slurm.confファイルでSallocDefaultCommand構成パラメーターを使用するだけです。

SallocDefaultCommand="srun -n1 -N1 --mem-per-cpu=0 --pty --preserve-env --cpu-bind=no --mpi=none $SHELL"

For Cray systems, add --gres=craynetwork:0 to the options.
Crayシステムの場合、オプションに--gres = craynetwork：0を追加します。
 

SallocDefaultCommand="srun -n1 -N1 --mem-per-cpu=0 --gres=craynetwork:0 --pty --preserve-env --mpi=none $SHELL"

What should I be aware of when upgrading Slurm?
Slurmをアップグレードするときに注意すべきことは何ですか？

See the Quick Start Administrator Guide Upgrade section for details.
詳細については、クイックスタート管理者ガイドのアップグレードセクションを参照してください。

How easy is it to switch from PBS or Torque to Slurm?
PBSまたはTorqueからSlurmに切り替えるのはどれほど簡単ですか？

A lot of users don't even notice the difference.
多くのユーザーは違いに気づくことすらありません。
 Slurm has wrappers available for the mpiexec, pbsnodes, qdel, qhold, qrls, qstat, and qsub commands (see contribs/torque in the distribution and the "slurm-torque" RPM).
Slurmには、mpiexec、pbsnodes、qdel、qhold、qrls、qstat、およびqsubコマンド用のラッパーがあります（ディストリビューションのcontribs / torqueおよび「slurm-torque」RPMを参照）。
 There is also a wrapper for the showq command at https://github.com/pedmon/slurm_showq.
https://github.com/pedmon/slurm_showqには、showqコマンドのラッパーもあります。

Slurm recognizes and translates the "#PBS" options in batch scripts.
Slurmは、バッチスクリプトの「#PBS」オプションを認識して翻訳します。
 Most, but not all options are supported.
すべてではありませんが、ほとんどのオプションがサポートされています。

Slurm also includes a SPANK plugin that will set all of the PBS environment variables based upon the Slurm environment (e.g. PBS_JOBID, PBS_JOBNAME, PBS_WORKDIR, etc.).
Slurmには、Slurm環境に基づいてすべてのPBS環境変数を設定するSPANKプラグインも含まれています（PBS_JOBID、PBS_JOBNAME、PBS_WORKDIRなど）。
 One environment not set by PBS_ENVIRONMENT, which if set would result in the failure of some MPI implementations.
PBS_ENVIRONMENTによって設定されていない1つの環境。設定すると、一部のMPI実装でエラーが発生します。
 The plugin will be installed in
<install_directory>/lib/slurm/spank_pbs.so
プラグインはにインストールされます/lib/slurm/spank_pbs.so

See the SPANK man page for configuration details.
設定の詳細については、SPANKのマニュアルページを参照してください。

How can I get SSSD to work with Slurm?
SSSDをSlurmと連携させるにはどうすればよいですか？

SSSD or System Security Services Deamon does not allow enumeration of group members by default.
SSSDまたはSystem Security Services Deamonは、デフォルトではグループメンバーの列挙を許可しません。
 Note that enabling enumeration in large environments might not be feasible.
大規模な環境で列挙を有効にするのは現実的でない場合があることに注意してください。
 However, Slurm does not need enumeration except for some specific quirky configurations (multiple groups with the same GID), so it's probably safe to leave enumeration disabled.
ただし、Slurmは特定の風変わりな設定（同じGIDを持つ複数のグループ）を除いて列挙を必要としないため、列挙を無効のままにしても安全です。
 SSSD is also case sensitive by default for some configurations, which could possibly raise other issues.
SSSDは、一部の設定ではデフォルトで大文字と小文字を区別するため、他の問題を引き起こす可能性があります。
 Add the following lines to /etc/sssd/sssd.conf on your head node to address these issues:
これらの問題に対処するには、ヘッドノードの/etc/sssd/sssd.confに次の行を追加します。

enumerate = True
case_sensitive = False

How critical is configuring high availability for my database?
データベースの高可用性の構成はどの程度重要ですか？

  • Consider if you really need a mysql failover. A short outage of slurmdbd is not a problem, because slurmctld will store all data in memory and send it to slurmdbd when it's back operating. The slurmctld daemon will also cache all user limits and fair share information.
    mysqlフェイルオーバーが本当に必要かどうかを検討してください。slurmctldはすべてのデータをメモリに保存し、再び動作しているときにslurmdbdに送信するため、slurmdbdの短い停止は問題になりません。slurmctldデーモンは、すべてのユーザー制限とフェアシェア情報もキャッシュします。
  • You cannot use ndb, since slurmdbd/mysql uses keys on BLOB values (and maybe something more from the incompatibility list).
    slurmdbd / mysqlはBLOB値のキーを使用するため（そして非互換性リストからさらに何かを使用するため）、ndbを使用することはできません。
  • You can set up "classical" Linux HA, with heartbeat/corosync to migrate IP between master/backup mysql servers and:
    ハートビート/コロシンクを使用して「クラシック」Linux HAをセットアップし、マスター/バックアップmysqlサーバー間でIPを移行します。
    • Configure one way replication of mysql, and change master/backup roles on failure
      mysqlの一方向レプリケーションを構成し、障害時にマスター/バックアップの役割を変更する
    • Use shared storage for master/slave mysql servers database, and start backup on master mysql failure.
      マスター/スレーブmysqlサーバーデータベースの共有ストレージを使用し、マスターmysqlの障害時にバックアップを開始します。

How can I use double quotes in MySQL queries?
MySQLクエリで二重引用符を使用するにはどうすればよいですか？

Execute: 

SET session sql_mode='ANSI_QUOTES';

This will allow double quotes in queries like this:
これにより、次のようなクエリで二重引用符を使用できます。

show columns from "tux_assoc_table" where Field='is_def';

Why is a compute node down with the reason set to "Node unexpectedly rebooted"?
理由が「ノードが予期せず再起動しました」に設定されているコンピューティングノードがダウンしているのはなぜですか？

This is indicative of the slurmctld daemon running on the cluster's head node as well as the slurmd daemon on the compute node when the compute node reboots.
これは、計算ノードの再起動時に、クラスターのヘッドノードで実行されているslurmctldデーモンと、計算ノードのslurmdデーモンを示しています。
 If you want to prevent this condition from setting the node into a DOWN state then configure ReturnToService to 2. See the slurm.conf man page for details.
この状態によってノードがDOWN状態に設定されないようにするには、ReturnToServiceを2に構成します。詳細については、slurm.confのマニュアルページを参照してください。
 Otherwise use scontrol or sview to manually return the node to service.
それ以外の場合は、scontrolまたはsviewを使用して、手動でノードをサービスに戻します。

How can a job which has exited with a specific exit code be requeued?
特定の終了コードで終了したジョブを再キューイングするにはどうすればよいですか？

Slurm supports requeue in hold with a SPECIAL_EXIT state using the command:
Slurmは、次のコマンドを使用して、SPECIAL_EXIT状態で保留中のリキューをサポートします。

scontrol requeuehold State=SpecialExit job_id

This is useful when users want to requeue and flag a job which has exited with a specific error case. See man scontrol(1) for more details.
これは、ユーザーが特定のエラーケースで終了したジョブを再度キューに入れてフラグを付けたい場合に便利です。詳細については、man scontrol（1）を参照してください。

$ scontrol requeuehold State=SpecialExit 10
$ squeue
   JOBID PARTITION  NAME     USER  ST       TIME  NODES NODELIST(REASON)
    10      mira    zoppo    david SE       0:00      1 (JobHeldUser)

The job can be later released and run again.
ジョブは後で解放して、再度実行できます。

The requeueing of jobs which exit with a specific exit code can be automated using an EpilogSlurmctld, see man(5) slurm.conf.
特定の終了コードで終了するジョブのリキューは、EpilogSlurmctldを使用して自動化できます。man（5）slurm.confを参照してください。
 This is an example of a script which exit code depends on the existence of a file.
これは、終了コードがファイルの存在に依存するスクリプトの例です。
 

$ cat exitme
#!/bin/sh
#
echo "hi! `date`"
if [ ! -e "/tmp/myfile" ]; then
  echo "going out with 8"
  exit 8
fi
rm /tmp/myfile
echo "going out with 0"
exit 0

This is an example of an EpilogSlurmctld that checks the job exit value looking at the SLURM_JOB_EXIT2 environment variable and requeues a job if it exited with value 8.
これは、SLURM_JOB_EXIT2環境変数を調べてジョブの終了値を確認し、値8で終了した場合にジョブを再キューイングするEpilogSlurmctldの例です。
 The SLURM_JOB_EXIT2 has the format "exit:sig", the first number is the exit code, typically as set by the exit() function.
SLURM_JOB_EXIT2の形式は「exit：sig」で、最初の番号は通常、exit（）関数で設定される終了コードです。
 The second number of the signal that caused the process to terminate if it was terminated by a signal.
プロセスがシグナルによって終了された場合にプロセスを終了させたシグナルの2番目の番号。
 

$ cat slurmctldepilog
#!/bin/sh

export PATH=/bin:/home/slurm/linux/bin
LOG=/home/slurm/linux/log/logslurmepilog

echo "Start `date`" >> $LOG 2>&1
echo "Job $SLURM_JOB_ID exitcode $SLURM_JOB_EXIT_CODE2" >> $LOG 2>&1
exitcode=`echo $SLURM_JOB_EXIT_CODE2|awk '{split($0, a, ":"); print a[1]}'` >> $LOG 2>&1
if [ "$exitcode" == "8" ]; then
   echo "Found REQUEUE_EXIT_CODE: $REQUEUE_EXIT_CODE" >> $LOG 2>&1
   scontrol requeuehold state=SpecialExit $SLURM_JOB_ID >> $LOG 2>&1
   echo $? >> $LOG 2>&1
else
   echo "Job $SLURM_JOB_ID exit all right" >> $LOG 2>&1
fi
echo "Done `date`" >> $LOG 2>&1

exit 0

Using the exitme script as an example, we have it exit with a value of 8 on the first run, then when it gets requeued in hold with SpecialExit state we touch the file /tmp/myfile, then release the job which will finish in a COMPLETE state.
例としてexitmeスクリプトを使用すると、最初の実行で値8で終了します。次に、SpecialExit状態で保持されてキューに再キューイングされると、ファイル/ tmp / myfileに触れ、ジョブを解放します。 COMPLETE状態。

Can a user's account be changed in the database?
データベースでユーザーのアカウントを変更できますか？

A user's account can not be changed directly.
ユーザーのアカウントを直接変更することはできません。
 A new association needs to be created for the user with the new account.
新しい関連付けを持つユーザーに対して、新しいアカウントを作成する必要があります。
 Then the association with the old account can be deleted.
その後、古いアカウントとの関連付けを削除できます。

# Assume user "adam" is initially in account "physics"
sacctmgr create user name=adam cluster=tux account=physics
sacctmgr delete user name=adam cluster=tux account=chemistry

What might account for MPI performance being below the expected level?
MPIのパフォーマンスが期待されるレベルを下回っている理由は何ですか？

Starting the slurmd daemons with limited locked memory can account for this.
ロックされたメモリが制限された状態でslurmdデーモンを起動すると、これを説明できます。
 Adding the line "ulimit -l unlimited" to the /etc/sysconfig/slurm file can fix this.
/ etc / sysconfig / slurmファイルに「ulimit -l unlimited」という行を追加すると、これを修正できます。

How could some jobs submitted immediately before the slurmctld daemon crashed be lost?
slurmctldデーモンがクラッシュする直前に送信された一部のジョブがどのように失われる可能性がありますか？

Any time the slurmctld daemon or hardware fails before state information reaches disk can result in lost state.
状態情報がディスクに到達する前にslurmctldデーモンまたはハードウェアに障害が発生すると、いつでも状態が失われる可能性があります。
 Slurmctld writes state frequently (every five seconds by default), but with large numbers of jobs, the formatting and writing of records can take seconds and recent changes might not be written to disk.
Slurmctldは状態を頻繁に（デフォルトでは5秒ごと）書き込みますが、ジョブの数が多いと、レコードのフォーマットと書き込みに数秒かかることがあり、最近の変更がディスクに書き込まれない場合があります。
 Another example is if the state information is written to file, but that information is cached in memory rather than written to disk when the node fails.
もう1つの例は、状態情報がファイルに書き込まれるが、ノードに障害が発生したときにその情報がディスクに書き込まれるのではなくメモリにキャッシュされる場合です。
 The interval between state saves being written to disk can be configured at build time by defining SAVE_MAX_WAIT to a different value than five.
ディスクに書き込まれる状態保存の間隔は、SAVE_MAX_WAITを5以外の値に定義することにより、ビルド時に構成できます。

How do I safely remove partitions?
パーティションを安全に削除するにはどうすればよいですか？

Partitions should be removed using the "scontrol delete PartitionName=<partition>" command.
パーティションは、「scontrol delete PartitionName ="コマンド。
 This is because scontrol will prevent any partitions from being removed that are in use.
これは、scontrolが使用中のパーティションが削除されないようにするためです。
 Partitions need to be removed from the slurm.conf after being removed using scontrol or they will return after a restart.
パーティションは、scontrolを使用して削除した後、slurm.confから削除する必要があります。そうしないと、再起動後にパーティションが元に戻ります。
 An existing job's partition(s) can be updated with the "scontrol update JobId=<jobid> Partition=<partition(s)>" command.
既存のジョブのパーティションは、「scontrol update JobId = パーティション="コマンド。
 Removing a partition from the slurm.conf and restarting will cancel any existing jobs that reference the removed partitions.
slurm.confからパーティションを削除して再起動すると、削除されたパーティションを参照する既存のジョブがキャンセルされます。

Why is Slurm unable to set the CPU frequency for jobs?
SlurmがジョブのCPU周波数を設定できないのはなぜですか？

First check that Slurm is configured to bind jobs to specific CPUs by making sure that TaskPlugin is configured to either affinity or cgroup.
最初に、Slurmが特定のCPUにジョブをバインドするように構成されていることを確認し、TaskPluginが親和性またはcgroupのいずれかに構成されていることを確認します。
 Next check that that your processor is configured to permit frequency control by examining the values in the file /sys/devices/system/cpu/cpu0/cpufreq where "cpu0" represents a CPU ID 0.
次に、ファイル/ sys / devices / system / cpu / cpu0 / cpufreqの値を調べて、プロセッサーが周波数制御を許可するように構成されていることを確認します。「cpu0」はCPU ID 0を表します。
 Of particular interest is the file scaling_available_governors, which identifies the CPU governors available.
特に興味深いのは、使用可能なCPUガバナーを識別するファイルscaling_available_governorsです。
 If "userspace" is not an available CPU governor, this may well be due to the intel_pstate driver being installed.
「userspace」が使用可能なCPUガバナーでない場合は、インストールされているintel_pstateドライバーが原因である可能性があります。
 Information about disabling the intel_pstate driver is available from
intel_pstateドライバーの無効化に関する情報は、

https://bugzilla.kernel.org/show_bug.cgi?id=57141 and
http://unix.stackexchange.com/questions/121410/setting-cpu-governor-to-on-demand-or-conservative.

When adding a new cluster, how can the Slurm cluster configuration be copied from an existing cluster to the new cluster?
新しいクラスターを追加するときに、Slurmクラスター構成を既存のクラスターから新しいクラスターにコピーするにはどうすればよいですか？

Accounts need to be configured for the cluster.
クラスター用にアカウントを構成する必要があります。
 An easy way to copy information from an existing cluster is to use the sacctmgr command to dump that cluster's information, modify it using some editor, the load the new information using the sacctmgr command.
既存のクラスターから情報をコピーする簡単な方法は、sacctmgrコマンドを使用してそのクラスターの情報をダンプし、エディターを使用して変更し、sacctmgrコマンドを使用して新しい情報をロードすることです。
 See the sacctmgr man page for details, including an example.
例を含む詳細については、sacctmgrのマニュアルページを参照してください。

How can I update Slurm on a Cray DVS file system without rebooting the nodes?
ノードを再起動せずにCray DVSファイルシステムでSlurmを更新するにはどうすればよいですか？

The problem with DVS caching is related to the fact that the dereferenced value of /opt/slurm/default symlink is cached in the DVS attribute cache, and that cache is not dropped when the rest of the VM caches are.
DVSキャッシングの問題は、/ opt / slurm / defaultシンボリックリンクの間接参照された値がDVS属性キャッシュにキャッシュされ、残りのVMキャッシュがキャッシュされてもそのキャッシュはドロップされないという事実に関連しています。

The Cray Native Slurm installation manual indicates that Slurm should have a "default" symlink run through /etc/alternatives.
Cray Native Slurmインストールマニュアルは、Slurmが/ etc / alternativesを介して実行される「デフォルト」のシンボリックリンクを持つ必要があることを示しています。
 As an alternative to that:
その代わりとして：

  1. Institute a policy that all changes to files which could be open persistently (i.e., .so files) are always modified by creating a new access path. I.e., installations go to a new directory.
    永続的に開くことができるファイル（つまり、.soファイル）へのすべての変更は、新しいアクセスパスを作成することによって常に変更されるというポリシーを設定します。つまり、インストールは新しいディレクトリに移動します。
  2. Dump the /etc/alternatives stuff, just use a regular symlink, e.g., default points to 15.8.0-1.
    / etc / alternativesのものをダンプし、通常のシンボリックリンクを使用します。たとえば、デフォルトは15.8.0-1を指します。
  3. Add a new mountpoint on all the compute nodes for /dsl/opt/slurm where the attrcache_timeout attribute is reduced from 14440s to 60s (or 15s -- whatever):
    / dsl / opt / slurmのすべての計算ノードに新しいマウントポイントを追加します。ここで、attrcache_timeout属性は14440秒から60秒（または15秒-何でも）に削減されます。

    mount -t dvs /opt/slurm /dsl/opt/slurm -o
    path=/dsl/opt/slurm,nodename=c0-0c0s0n0,loadbalance,cache,ro,attrcache_timeout=15
    In the example above, c0-0c0s0n0 is the single DVS server for the system.
    上記の例では、c0-0c0s0n0がシステムの単一のDVSサーバーです。

Using this strategy avoids the caching problems, making upgrades simple.
この戦略を使用すると、キャッシュの問題が回避され、アップグレードが簡単になります。
 One just has to wait for about 20 seconds after changing the default symlinks before starting the slurmds again.
デフォルトのシンボリックリンクを変更してから約20秒間待ってから、slurmdを再び開始する必要があります。

(Information courtesy of Douglas Jacobsen, NERSC, Lawrence Berkeley National Laboratory)
（情報提供：Douglas Jacobsen、NERSC、ローレンスバークレー国立研究所）

How can I rebuild the database hierarchy?
データベース階層を再構築するにはどうすればよいですか？

If you see errors of this sort:
この種のエラーが発生した場合：

error: Can't find parent id 3358 for assoc 1504, this should never happen.

in the slurmctld log file, this is indicative that the database hierarchy information has been corrupted, typically due to a hardware failure or administrator error in directly modifying the database.
slurmctldログファイルでは、これは通常、データベースを直接変更する際のハードウェア障害または管理者のエラーが原因で、データベース階層情報が破損していることを示しています。
 In order to rebuild the database information, start the slurmdbd daemon with the "-R" option followed by an optional comma separated list of cluster names to operate on.
データベース情報を再構築するには、「-R」オプションを付けてslurmdbdデーモンを開始し、その後に、操作するクラスター名のオプションのコンマ区切りリストを続けます。

How can a routing queue be configured?
ルーティングキューはどのように構成できますか？

A job submit plugin is designed to have access to a job request from a user, plus information about all of the available system partitions/queue.
ジョブ送信プラグインは、ユーザーからのジョブ要求に加えて、利用可能なすべてのシステムパーティション/キューに関する情報にアクセスできるように設計されています。
 An administrator can write a C plugin or LUA script to set an incoming job's partition based upon its size, time limit, etc.
管理者は、CプラグインまたはLUAスクリプトを作成して、サイズ、制限時間などに基づいて受信ジョブのパーティションを設定できます。
 See the Job Submit Plugin API guide for more information.
詳細については、ジョブ送信プラグインAPIガイドを参照してください。
 Also see the available job submit plugins distributed with Slurm for examples (look in the "src/plugins/job_submit" directory).
例については、Slurmで配布されている使用可能なジョブ送信プラグインも参照してください（「src / plugins / job_submit」ディレクトリを確認してください）。

How can I suspend, resume, hold or release all of the jobs belonging to a specific user, partition, etc?
特定のユーザー、パーティションなどに属するすべてのジョブを一時停止、再開、保留、または解放するにはどうすればよいですか？

There isn't any filtering by user, partition, etc.
ユーザー、パーティションなどによるフィルタリングはありません。
 available in the scontrol command; however the squeue command can be used to perform the filtering and build a script which you can then execute. For example:
scontrolコマンドで使用できます。ただし、squeueコマンドを使用して、フィルタリングを実行し、実行可能なスクリプトを作成できます。例えば：
 

$ squeue -u adam -h -o "scontrol hold %i" >hold_script

I had to change a user's UID and now they cannot submit jobs. How do I get the new UID to take effect?
ユーザーのUIDを変更する必要があり、ジョブを送信できなくなりました。新しいUIDを有効にするにはどうすればよいですか？

When changing UIDs, you will also need to restart the slurmctld for the changes to take effect.
UIDを変更する場合は、変更を有効にするためにslurmctldを再起動する必要もあります。
 Normally, when adding a new user to the system, the UID is filled in automatically and immediately.
通常、システムに新しいユーザーを追加すると、UIDは自動的かつ即座に入力されます。
 If the user isn't known on the system yet, there is a thread that runs every hour that fills in those UIDs when they become known, but it doesn't recognize UID changes of preexisting users.
ユーザーがシステム上でまだ知られていない場合は、1時間ごとに実行されるスレッドがあり、それらのUIDが知らされたときにそれらを入力しますが、既存のユーザーのUIDの変更は認識しません。
 But you can simply restart the slurmctld for those changes to be recognized.
ただし、これらの変更を認識させるには、slurmctldを再起動するだけです。

Slurmdbd is failing to start with a 'Duplicate entry' error in the database. How do I fix that?
Slurmdbdは、データベースの「重複エントリ」エラーで開始に失敗します。どうすれば修正できますか？

This problem has been rarely observed with MySQL, but not MariaDB.
この問題はMySQLではほとんど発生しませんが、MariaDBでは発生しません。
 The root cause of the failure seems to be reaching the upper limit on the auto increment field.
失敗の根本的な原因は、自動インクリメントフィールドの上限に達しているようです。
 Upgrading to MariaDB is recommended.
MariaDBへのアップグレードをお勧めします。
 If that is not possible then: backup the database, remove the duplicate record(s), and restart the slurmdbd daemon as shown below.
それが不可能な場合は、データベースをバックアップし、重複するレコードを削除して、次に示すようにslurmdbdデーモンを再起動します。

$ slurmdbd -Dvv
...
slurmdbd: debug:  Table "cray_job_table" has changed.  Updating...
slurmdbd: error: mysql_query failed: 1062 Duplicate entry '2711-1478734628' for key 'id_job'
...

$ mysqldump --single-transaction -u<user> -p<user> slurm_acct_db >/tmp/slurm_db_backup.sql

$ mysql
mysql> use slurm_acct_db;
mysql> delete from cray_job_table where id_job='2711-1478734628';
mysql> quit;
Bye

If necessary, you can edit the database dump and recreate the database as shown below.
必要に応じて、データベースダンプを編集して、以下に示すようにデータベースを再作成できます。

$ mysql
mysql> drop database slurm_acct_db;
mysql> create database slurm_acct_db;
mysql> quit;
Bye

$ mysql -u<user> -p<user> </tmp/slurm_db_backup.sql

Why are applications on my Cray system failing with SIGBUS (bus error)?
Crayシステム上のアプリケーションがSIGBUS（バスエラー）で失敗するのはなぜですか？

By default, Slurm flushes Lustre file system and kernel caches upon completion of each job step.
デフォルトでは、Slurmは各ジョブステップの完了時にLusterファイルシステムとカーネルキャッシュをフラッシュします。
 If multiple applications are run simultaneously on compute nodes (either multiple applications from a single Slurm job or multiple jobs) the result can be significant performance degradation and even bus errors.
複数のアプリケーションが計算ノードで同時に実行される場合（単一のSlurmジョブからの複数のアプリケーションまたは複数のジョブ）、結果としてパフォーマンスが大幅に低下し、バスエラーが発生する可能性があります。
 Failures occur more frequently when more applications are executed at the same time on individual compute nodes.
個々の計算ノードで同時により多くのアプリケーションが実行されると、障害がより頻繁に発生します。
 Failures are also more common when Lustre file systems are used.
光沢は、Lustreファイルシステムが使用されている場合にも一般的です。

Two approaches exist to address this issue.
この問題に対処するには、2つの方法があります。
 One is to disable the flushing of caches, which can be accomplished by adding "LaunchParameters=lustre_no_flush" to your Slurm configuration file "slurm.conf".
1つは、キャッシュのフラッシュを無効にすることです。これは、Slurm構成ファイル「slurm.conf」に「LaunchParameters = lustre_no_flush」を追加することで実行できます。
 A second approach is to modify the Cray file system as described below in order to prevent Slurm-specific files needing to be re-resolved over DFS.
2番目のアプローチは、Slurm固有のファイルをDFS経由で再解決する必要がないように、以下で説明するようにCrayファイルシステムを変更することです。
 This second approach does not address files used by applications, only those used directly by Slurm.
この2番目のアプローチは、アプリケーションが使用するファイルではなく、Slurmが直接使用するファイルのみを扱います。

On Cray CLE6.0, by default, nodes get the operating system, including the Slurm installation and all of its plugins, via a DVS mount of "/".
Cray CLE6.0では、デフォルトで、ノードは "/"のDVSマウントを介して、Slurmインストールとそのすべてのプラグインを含むオペレーティングシステムを取得します。
 Really "/" is an overlay filesystem where the lower portion is a loop-mounted squashfs layer and the upper layer is tmpfs.
本当に「/」はオーバーレイファイルシステムで、下部はループマウントされたsquashfsレイヤー、上部はtmpfsです。
 When buffer caches are flushed during a dlopen (used by Slurm to load its plugins), a timeout may result from waiting to re-resolve a Slurm plugin over DVS.
dlopen（プラグインをロードするためにSlurmによって使用される）中にバッファーキャッシュがフラッシュされると、DVS経由でSlurmプラグインを再解決するのを待っているとタイムアウトが発生する場合があります。

The NERSC solution is to localize all files related to Slurm or involved in slurmstepd launch into that tmpfs layer at boot time.
NERSCソリューションは、Slurmに関連するすべてのファイル、または起動時にそのtmpfsレイヤーへのslurmstepd起動に関連するすべてのファイルをローカライズすることです。
 This is possible by creating a new netroot preload file:
これは、新しいnetrootプリロードファイルを作成することで可能です。

# cat compute-preload.nersc
/usr/lib64/libslurm*so*
/usr/lib64/slurm/*.so
/usr/sbin/slurmd
/usr/sbin/slurmstepd
/usr/bin/sbatch
/usr/bin/srun
/usr/bin/sbcast
/usr/bin/numactl
/usr/lib64/libnuma*so*
/lib64/ast/libast.so*
/lib64/ast/libcmd.so*
/lib64/ast/libdll.so*
/lib64/ast/libshell.so*
/lib64/libacl.so*
/lib64/libattr.so*
/lib64/libc.so*
/lib64/libcap.so*
/lib64/libdl.so*
/lib64/libgcc_s.so*
...

NERSC generates its preload file by including everything installed by Slurm RPMs plus files identified as being used by Slurm's slurmd daemon on the compute node by running the "strace -f" command while the slurmd daemon is launching a job step.
NERSCは、Slurm RPMによってインストールされたすべてのものと、slurmdデーモンがジョブステップを起動している間に「strace -f」コマンドを実行することにより、計算ノード上のSlurmのslurmdデーモンによって使用されていると識別されたファイルを含めることにより、プリロードファイルを生成します。

Once the netroot preload file is generated, it needs to then be included in the cray_netroot_preload_worksheet CLE configuration. For example:
netrootプリロードファイルが生成されたら、それをcray_netroot_preload_worksheet CLE構成に含める必要があります。例えば：

cray_netroot_preload.settings.load.data.label.compute: null
cray_netroot_preload.settings.load.data.compute.targets: []
cray_netroot_preload.settings.load.data.compute.content_lists:
- dist/compute-preload.cray
- dist/compute-preload.nersc
cray_netroot_preload.settings.load.data.compute.size_limit: 0

This is a generally useful technique for preventing remote lookups of commonly accessed files within jobs.
これは、ジョブ内で一般的にアクセスされるファイルのリモートルックアップを防ぐための一般的に有用な手法です。

Last modified 4 March 2020