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時間年中無休のオンサイト担当者までの幅広いサポートオプションを提供しています。
 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に変更し（例：「scontrolupdate NodeName = name State = DOWN Reason = hung_completing」）、再起動する必要があります。次に、ノードの状態をIDLEにリセットします（例：「scontrolupdate 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.
これらのパラメーターの詳細については、「manslurm.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 ...").
エラーメッセージは、ユーザーがリソース制限を伝達する必要があることを明示的に指定した場合、またはsrunコマンドがslurmdデーモンからのアクションの詳細なロギングで実行されている場合にのみ出力されます（例：「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.
主なものは、Slurmが使用するスケジューラーです。
 Executing the command
コマンドの実行

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 showjobを使用してジョブの優先順位を確認できます。
 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 job ＜jobid＞を発行し、フィールドState and Reasonを調べて、原因を調査します。

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.
srunの有効なオプションではない最初のトークンは実行するコマンドと見なされ、それ以降はすべてコマンドのオプションとして扱われます。
 For example:
例えば：

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」はhostnameコマンドのオプションとして扱われます。
 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?
1つのスクリプト内から複数のジョブを実行するにはどうすればよいですか？

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.
ファイルcontribs / make-3.81.slurm.patchには、Slurmディストリビューションの一部として利用可能なGNUmakeバージョン3.81用のパッチがあります。
 For GNU make version 4.0 you can use the patch in the file contribs/make-4.0.slurm.patch.
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.
最後に、X11機能を利用して、グラフィカル端末を実行できます。
 (e.g. srun xterm).
（例：srun xterm）。

What does "srun: Force Terminated job" indicate?
「srun：強制終了ジョブ」は何を示していますか？

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：ForceTerinatedjob」というメッセージが出力されます。
 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 JobFailed」？

The srun command monitors when tasks exit.
srunコマンドは、タスクがいつ終了するかを監視します。
 By default, 30 seconds after the first task exists, the job is killed.
デフォルトでは、最初のタスクが存在してから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.
この動作は、srunの--wait = ＜time＞オプションを使用して変更し、タイムアウト期間を変更するか、タイムアウトを完全に無効にすることができます。
 See srun's man page for details.
詳細については、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.
ユーザーのリソース制限が伝播されない場合、slurmdデーモンに有効な制限が生成されたジョブに使用されます。
 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).
たとえば、ユーザーrootのロックされたメモリ制限ulimitを計算ノードで無制限に設定し（「manlimits.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つは、' arbitrary 'です。
 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つのタスクを実行したい場合、ノードはSLURM_JOB_NODELISTから割り当てられます。ここで、tux [0-1]のsrun行は次のようになります。

srun -n5 -m arbitrary -w tux[0,0,0,0,1] hostname
srun -n5-m任意-wtux [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任意-wtux [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.
これは、任意の.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：＜jobid＞を指定します。
 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 = ＜jobid＞ NumNodes = 0

The jobid above is that of the job to relinquish its resources.
上記のジョブIDは、リソースを放棄するジョブのジョブ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 = ＜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.
たとえば、バージョン5.1以前のDAKOTAには、POSIX正規表現関数ではなく使用される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（および「scontrolshowjobid」）がジョブの推定開始時間を表示しないことがあるのはなぜですか？

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.
Slurmは、完了または失敗した状態でのジョブの再キューイングをサポートします。
 Use the command:
次のコマンドを使用します。

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".
コマンド「scontrolshownode」を使用し、「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?
スキュー出力を色分けできますか？

The squeue command output is not color coded, but other tools can be used to add color.
squeueコマンドの出力は色分けされていませんが、他のツールを使用して色を追加できます。
 One such tool is ColorWrapper (https://github.com/rrthomas/cw).
そのようなツールの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.
バージョン17.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.
詳細については、「manslurm.conf」および「manscontrol」を参照してください。

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.
ノード上のslurmdデーモンがslurm.confで定義されている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.
これらの構成パラメーターの詳細については、manslurm.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:
次のコマンドは、Redhat6の例です。

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.
説明に従ってリソース予約を作成します。
 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 requiredpam_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_pam1」を使用するか、configureプログラムの実行時にコマンドラインオプション「--withoutpam」を入力することで無効にできます。
 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.
pam_slurm_adoptまたはpam_slurmのいずれかを使用する場合、UsePAMを設定する必要はありません。
 The two uses of PAM are independent.
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をチェックインすると、「＜一部のIPアドレス＞からの無効なジョブ資格情報：ジョブ資格情報の有効期限が切れています」というメッセージが表示される可能性があります。
 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でのみ使用される任意の名前）をNodeNameとして、NodeHostnameの物理ノードの実際のアドレスとともに定義します。
     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-Nhostname」）。
  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で、目的のノード名（Slurmでのみ使用される任意の名前）をNodeNameとして定義し、NodeHostNameとNodeAddrの1つの物理ノードの実際の名前とアドレスを指定します。
     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.
もう1つの可能性は、slurmctldデーモンが実行されるノードがメモリを使い果たしてページングしていることです。
 Try running the program top to check for this possibility.
プログラムトップを実行して、この可能性を確認してください。

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.
これらのオプションの詳細については、「manslurm.conf」および「mansrun」を参照してください。

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.
Slurmログファイルには、期限切れの資格情報への参照が含まれている必要があります。
 For example:
例えば：
 

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/slurmstartclean」を使用）、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ディレクトリからPerlAPIとともにSlurmのTorque / PBSコマンドラッパーをビルドしてインストールし、それらのPBSコマンドを使用するようにGlobusを構成します。
 Note there are RPMs available for both of these packages, named torque and perlapi respectively.
これらのパッケージの両方で、それぞれtorqueおよびperlapiという名前のRPMが利用可能であることに注意してください。

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?
pam_slurm.so、auth_none.so、またはその他のコンポーネントがSlurm RPMに含まれていないのはなぜですか？

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を追加するか、〜/ rpmmacrosファイルに％_with_auth_noneを追加します。
 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.
    1つのデータベース内のすべてのSlurmクラスターから企業全体のアカウンティングを維持します。
     The slurmdbd is multi-threaded and designed to handle all the accounting for the entire enterprise.
    slurmdbdはマルチスレッドであり、企業全体のすべてのアカウンティングを処理するように設計されています。
  4. With the database plugins you can query with sacct accounting stats from any node Slurm is installed on.
    データベースプラグインを使用すると、Slurmがインストールされている任意のノードからsacctアカウンティング統計を使用してクエリを実行できます。
     With the slurmdbd you can also query any cluster using the slurmdbd from any other cluster's nodes.
    slurmdbdを使用すると、他のクラスターのノードからslurmdbdを使用して任意のクラスターにクエリを実行することもできます。
     Other tools like sreport are also available.
    sreportのような他のツールも利用できます。

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

When configuring, run the configure script with --enable-developer option.
構成するときは、-enable-developerオプションを指定してconfigureスクリプトを実行します。
 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.
SlurmでダウンしているノードでHealthCheckProgramが確実に実行されるようにするには、CRONまたはノード起動スクリプトを使用する方が適している場合があります。

What is the meaning of the error "Batch JobId=# missing from batch node <node> (not found BatchStartTime after startup)"?
「バッチJobId =＃がバッチノード＜ノード＞にありません（起動後に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.
これは、ユーザーのリソース制限に達したときにSUSELinuxを実行している一部の大規模なクラスターで報告されています。
 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のマニュアルページにある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デーモンを開始することにより、slurmdおよび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.
呼び出し元ノードのホストが正しいIPアドレスではなく127.0.1.1と表示されます。
 Why is that?
何故ですか？

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.
パーティションの状態をDOWNに設定することで、Slurmがパーティションごとにジョブをスケジュールするのを停止できます。
 Set its state UP to resume scheduling.
状態をUPに設定して、スケジューリングを再開します。
 For example:
例えば：
 

$ 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.
いいえ。ただし、squeueを使用して、フィルタリングとフォーマットのオプションを利用してスクリプトを作成できます。
 For example:
例えば：
 

$ 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:
はい、AshleyPittmanの厚意により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が絶対パスの場合、コアファイルはこのディレクトリに書き込まれます。
 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 / pool / abrt）で生成される場合があります。
  • In Cray XC ATP (Abnormal Termination Processing) daemon acts the same way, if it is enabled.
    Cray XC ATP（Abnormal Termination Processing）では、デーモンが有効になっている場合、デーモンは同じように動作します。

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」は、通常はダンプされないバイナリをルートのみで読み取り可能にします。

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 / pool / 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.
GitHubでコミットを見つけて開き、URLに「.patch」を追加して、結果のファイルを保存します。
 For an example, see:
例については、以下を参照してください。
 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デーモンを停止します（例：ヘッドノードの「systemctlstopslurmctld」）
  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デーモンを再起動します（例：すべてのノードで「systemctlrestartslurmd」）
  4. Restart the slurmctld daemon (e.g. "systemctl start slurmctld" on the head node)
    slurmctldデーモンを再起動します（例：ヘッドノードの「systemctlstartslurmctld」）

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デーモンを再起動せずにシステムのライセンスの総数を変更することはできませんが、ライセンスを動的に予約して、システム上のジョブで使用できないようにすることはできます（例：「scontrolupdatereservation = licenses_heldlicenses = 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環境変数（PBS_JOBID、PBS_JOBNAME、PBS_WORKDIRなど）を設定するSPANKプラグインも含まれています。
 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
プラグインは＜install_directory＞ /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またはSystemSecurity 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.
    mysqlフェイルオーバーが本当に必要かどうかを検討してください。
     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.
    slurmctldはすべてのデータをメモリに保存し、動作が再開したときにそれをslurmdbdに送信するため、slurmdbdの短時間の停止は問題ではありません。
     The slurmctld daemon will also cache all user limits and fair share information.
    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:
    ハートビート/ corosyncを使用して「クラシック」LinuxHAをセットアップし、マスター/バックアップ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.
この状態でノードがDOWN状態になるのを防ぎたい場合は、ReturnToServiceを2に構成します。
 See the slurm.conf man page for details.
詳細については、slurm.confのmanページを参照してください。
 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.
「ulimit-lunlimited」という行を/ etc / sysconfig / slurmファイルに追加すると、これを修正できます。

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 deletePartitionName = ＜partition＞」コマンドを使用して削除する必要があります。
 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 = ＜jobid＞ Partition = ＜partition（s）＞」コマンドで更新できます。
 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.
まず、TaskPluginがアフィニティまたはcgroupのいずれかに設定されていることを確認して、Slurmがジョブを特定のCPUにバインドするように設定されていることを確認します。
 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 ID0を表します。
 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ドライバーの無効化に関する情報は、次のURLから入手できます。

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のmanページを参照してください。

How can I update Slurm on a Cray DVS file system without rebooting the nodes?
ノードを再起動せずにCrayDVSファイルシステムで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秒待ってから、slurmdsを再開する必要があります。

(Information courtesy of Douglas Jacobsen, NERSC, Lawrence Berkeley National Laboratory)
（情報提供：ダグラス・ジェイコブセン、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.
scontrolコマンドで使用できます。ただし、squeueコマンドを使用してフィルタリングを実行し、スクリプトを作成して実行することができます。
 For example:
例えば：
 

$ 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.
Slurmdbdは、データベースの「重複エントリ」エラーで開始できません。
 How do I fix that?
どうすれば修正できますか？

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は各ジョブステップの完了時にLustreファイルシステムとカーネルキャッシュをフラッシュします。
 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.
Lusterファイルシステムを使用すると、障害もより一般的になります。

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に関連する、またはslurmstepdの起動に関係するすべてのファイルを起動時にそのtmpfsレイヤーにローカライズすることです。
 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.
netrootプリロードファイルが生成されたら、それをcray_netroot_preload_worksheetCLE構成に含める必要があります。
 For example:
例えば：

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