1SPANK(8)                        Slurm Component                       SPANK(8)
2
3
4

NAME

6       SPANK - Slurm Plug-in Architecture for Node and job (K)control
7
8

DESCRIPTION

10       This manual briefly describes the capabilities of the Slurm Plug-in Ar‐
11       chitecture for Node and job Kontrol (SPANK) as well as the  SPANK  con‐
12       figuration file: (By default: plugstack.conf.)
13
14       SPANK  provides  a  very generic interface for stackable plug-ins which
15       may be used to dynamically modify the job launch code in  Slurm.  SPANK
16       plugins  may  be  built  without access to Slurm source code. They need
17       only be compiled against Slurm's spank.h  header  file,  added  to  the
18       SPANK  config  file  plugstack.conf, and they will be loaded at runtime
19       during the next job launch. Thus, the SPANK infrastructure provides ad‐
20       ministrators and other developers a low cost, low effort ability to dy‐
21       namically modify the runtime behavior of Slurm job launch.
22
23       NOTE: All SPANK plugins should be recompiled when upgrading Slurm to  a
24       new major release. The SPANK API is not guaranteed to be ABI compatible
25       between major releases. Any SPANK plugin linking to any  of  the  Slurm
26       libraries should be carefully checked as the Slurm APIs and headers can
27       change between major releases.
28

SPANK PLUGINS

30       SPANK plugins are loaded in up to five separate contexts during a Slurm
31       job. Briefly, the five contexts are:
32
33
34       local   In  local context, the plugin is loaded by srun. (i.e. the "lo‐
35               cal" part of a parallel job).
36
37       remote  In remote context, the plugin is loaded  by  slurmstepd.  (i.e.
38               the "remote" part of a parallel job).
39
40       allocator
41               In  allocator  context,  the plugin is loaded in one of the job
42               allocation utilities salloc, sbatch or scrontab.
43
44       slurmd  In slurmd context, the plugin is loaded in  the  slurmd  daemon
45               itself.  Note: Plugins loaded in slurmd context persist for the
46               entire time slurmd is running, so if configuration  is  changed
47               or  plugins  are  updated,  slurmd  must  be  restarted for the
48               changes to take effect.
49
50       job_script
51               In the job_script context, plugins are loaded in the context of
52               the   job  prolog  or  epilog.  Note:  Plugins  are  loaded  in
53               job_script context on each run on the job prolog or epilog,  in
54               a  separate  address space from plugins in slurmd context. This
55               means there is no state shared between this context  and  other
56               contexts, or even between one call to slurm_spank_job_prolog or
57               slurm_spank_job_epilog and subsequent calls.
58
59       In  local  context,  only  the  init,  exit,  init_post_opt,  and   lo‐
60       cal_user_init  functions  are  called.  In  allocator context, only the
61       init, exit, and init_post_opt  functions  are  called.   Similarly,  in
62       slurmd context, only the init and slurmd_exit callbacks are active, and
63       in the job_script context, only the job_prolog and job_epilog callbacks
64       are used.  Plugins may query the context in which they are running with
65       the   spank_context   and    spank_remote    functions    defined    in
66       <slurm/spank.h>.
67
68       SPANK  plugins  may be called from multiple points during the Slurm job
69       launch. A plugin may define the following functions:
70
71
72       slurm_spank_init
73         Called just after plugins are loaded. In remote context, this is just
74         after  job  step  is  initialized. This function is called before any
75         plugin option processing.
76
77       slurm_spank_job_prolog
78         Called at the same time as the job prolog. If this function returns a
79         non-zero  value  and the SPANK plugin that contains it is required in
80         the plugstack.conf, the node that this is run on will be drained.
81
82       slurm_spank_init_post_opt
83         Called at the same point as slurm_spank_init, but after all user  op‐
84         tions to the plugin have been processed. The reason that the init and
85         init_post_opt callbacks are separated is so that plugins can  process
86         system-wide options specified in plugstack.conf in the init callback,
87         then  process  user  options,  and  finally  take  some   action   in
88         slurm_spank_init_post_opt  if  necessary.  In the case of a heteroge‐
89         neous job, slurm_spank_init is invoked once per job component.
90
91       slurm_spank_local_user_init
92         Called in local (srun) context only after all options have been  pro‐
93         cessed.   This is called after the job ID and step IDs are available.
94         This happens in srun after the allocation is made, but  before  tasks
95         are launched.
96
97       slurm_spank_user_init
98         Called  after  privileges  are  temporarily  dropped. (remote context
99         only)
100
101       slurm_spank_task_init_privileged
102         Called for each task just after fork, but before all elevated  privi‐
103         leges are dropped. (remote context only)
104
105       slurm_spank_task_init
106         Called  for  each  task just before execve (2). If you are restricing
107         memory with cgroups, memory allocated  here  will  be  in  the  job's
108         cgroup. (remote context only)
109
110       slurm_spank_task_post_fork
111         Called  for each task from parent process after fork (2) is complete.
112         Due to the fact that slurmd does not exec any tasks until  all  tasks
113         have  completed  fork  (2), this call is guaranteed to run before the
114         user task is executed. (remote context only)
115
116       slurm_spank_task_exit
117         Called for each task as its exit status is collected by Slurm.   (re‐
118         mote context only)
119
120       slurm_spank_exit
121         Called once just before slurmstepd exits in remote context.  In local
122         context, called before srun exits.
123
124       slurm_spank_job_epilog
125         Called at the same time as the job epilog. If this function returns a
126         non-zero  value  and the SPANK plugin that contains it is required in
127         the plugstack.conf, the node that this is run on will be drained.
128
129       slurm_spank_slurmd_exit
130         Called in slurmd when the daemon is shut down.
131
132       All of these functions have the same prototype, for example:
133          int slurm_spank_init (spank_t spank, int ac, char *argv[])
134
135
136       Where spank is the SPANK handle which must be passed back to Slurm when
137       the  plugin  calls functions like spank_get_item and spank_getenv. Con‐
138       figured arguments (See CONFIGURATION below) are passed in the  argument
139       vector argv with argument count ac.
140
141       SPANK  plugins can query the current list of supported slurm_spank sym‐
142       bols to determine if the current version supports a given plugin  hook.
143       This  may  be useful because the list of plugin symbols may grow in the
144       future. The query is done using  the  spank_symbol_supported  function,
145       which has the following prototype:
146           int spank_symbol_supported (const char *sym);
147
148
149       The return value is 1 if the symbol is supported, 0 if not.
150
151       SPANK  plugins  do  not  have direct access to internally defined Slurm
152       data structures. Instead, information about the currently executing job
153       is obtained via the spank_get_item function call.
154         spank_err_t spank_get_item (spank_t spank, spank_item_t item, ...);
155
156       The spank_get_item call must be passed the current SPANK handle as well
157       as the item requested, which is defined by the passed  spank_item_t.  A
158       variable  number  of  pointer  arguments  are also passed, depending on
159       which item was requested by the plugin. A list of the valid values  for
160       item is kept in the spank.h header file. Some examples are:
161
162
163       S_JOB_UID
164         User id for running job. (uid_t *) is third arg of spank_get_item
165
166       S_JOB_STEPID
167         Job   step  id  for  running  job.  (uint32_t  *)  is  third  arg  of
168         spank_get_item.
169
170       S_TASK_EXIT_STATUS
171         Exit status for exited task. Only valid  from  slurm_spank_task_exit.
172         (int *) is third arg of spank_get_item.
173
174       S_JOB_ARGV
175         Complete  job  command  line. Third and fourth args to spank_get_item
176         are (int *, char ***).
177
178       See spank.h for more details.
179
180       SPANK functions in the local and allocator environment should  use  the
181       getenv, setenv, and unsetenv functions to view and modify the job's en‐
182       vironment.  SPANK functions in the remote environment  should  use  the
183       spank_getenv,  spank_setenv,  and  spank_unsetenv functions to view and
184       modify the job's environment. spank_getenv searches the job's  environ‐
185       ment for the environment variable var and copies the current value into
186       a buffer buf of length len.  spank_setenv allows a SPANK plugin to  set
187       or  overwrite  a  variable in the job's environment, and spank_unsetenv
188       unsets an environment variable in the job's environment. The prototypes
189       are:
190        spank_err_t spank_getenv (spank_t spank, const char *var,
191                            char *buf, int len);
192        spank_err_t spank_setenv (spank_t spank, const char *var,
193                            const char *val, int overwrite);
194        spank_err_t spank_unsetenv (spank_t spank, const char *var);
195
196
197       These  are  only necessary in remote context since modifications of the
198       standard process environment using setenv (3), getenv (3), and unsetenv
199       (3) may be used in local context.
200
201       Functions are also available from within the SPANK plugins to establish
202       environment variables to be exported to the Slurm PrologSlurmctld, Pro‐
203       log, Epilog and EpilogSlurmctld programs (the so-called job control en‐
204       vironment).  The name of environment  variables  established  by  these
205       calls  will  be  prepended with the string SPANK_ in order to avoid any
206       security implications of arbitrary environment variable control. (After
207       all, the job control scripts do run as root or the Slurm user.).
208
209       These functions are available from local context only.
210         spank_err_t spank_job_control_getenv(spank_t spank, const char *var,
211                              char *buf, int len);
212         spank_err_t spank_job_control_setenv(spank_t spank, const char *var,
213                              const char *val, int overwrite);
214         spank_err_t spank_job_control_unsetenv(spank_t spank, const char *var);
215
216
217       See spank.h for more information.
218
219       Many  of  the described SPANK functions available to plugins return er‐
220       rors via the spank_err_t error type. On success, the return value  will
221       be  set  to  ESPANK_SUCCESS, while on failure, the return value will be
222       set to one of many error values defined in slurm/spank.h. The SPANK in‐
223       terface provides a simple function
224         const char * spank_strerror(spank_err_t err);
225       which may be used to translate a spank_err_t value into its string rep‐
226       resentation.
227
228
229       The slurm_spank_log function can be used to print messages back to  the
230       user  at  an error level.  This is to keep users from having to rely on
231       the slurm_error function, which can be confusing  because  it  prepends
232       "error:" to every message.
233
234

SPANK OPTIONS

236       SPANK  plugins also have an interface through which they may define and
237       implement extra job options. These options are made  available  to  the
238       user  through Slurm commands such as srun(1), salloc(1), and sbatch(1).
239       If the option is specified by the user, its value is forwarded and reg‐
240       istered  with  the  plugin in slurmd when the job is run.  In this way,
241       SPANK plugins may dynamically provide new options and functionality  to
242       Slurm.
243
244       Each  option registered by a plugin to Slurm takes the form of a struct
245       spank_option which is declared in <slurm/spank.h> as
246          struct spank_option {
247             char *         name;
248             char *         arginfo;
249             char *         usage;
250             int            has_arg;
251             int            val;
252             spank_opt_cb_f cb;
253          };
254
255       Where
256
257
258       name   is the name of the option. Its length is  limited  to  SPANK_OP‐
259              TION_MAXLEN defined in <slurm/spank.h>.
260
261       arginfo
262              is  a  description  of the argument to the option, if the option
263              does take an argument.
264
265       usage  is a short description of the option suitable for --help output.
266
267       has_arg
268              0 if option takes no argument, 1 if option  takes  an  argument,
269              and 2 if the option takes an optional argument. (See getopt_long
270              (3)).
271
272       val    A plugin-local value to return to the option callback function.
273
274       cb     A callback function that is invoked when the  plugin  option  is
275              registered   with   Slurm.   spank_opt_cb_f   is   typedef'd  in
276              <slurm/spank.h> as
277
278                typedef int (*spank_opt_cb_f) (int val, const char *optarg,
279                                         int remote);
280              Where val is the value of the  val  field  in  the  spank_option
281              struct,  optarg  is the supplied argument if applicable, and re‐
282              mote is 0 if the function is being called from the "local"  host
283              (e.g.  host  where  srun or sbatch/salloc are invoked) or 1 from
284              the "remote" host (host where slurmd/slurmstepd  run)  but  only
285              executed by slurmstepd (remote context) if the option was regis‐
286              tered for such context.
287
288       Plugin options may be registered with Slurm using the spank_option_reg‐
289       ister  function.  This  function  is  only  valid  when called from the
290       plugin's slurm_spank_init handler, and registers one option at a  time.
291       The prototype is
292          spank_err_t spank_option_register (spank_t sp,
293                    struct spank_option *opt);
294       This  function will return ESPANK_SUCCESS on successful registration of
295       an option, or ESPANK_BAD_ARG for errors including invalid spank_t  han‐
296       dle, or when the function is not called from the slurm_spank_init func‐
297       tion. All options need to be registered from all contexts in which they
298       will  be  used. For instance, if an option is only used in local (srun)
299       and remote (slurmd) contexts, then spank_option_register should only be
300       called from within those contexts. For example:
301          if (spank_context() != S_CTX_ALLOCATOR)
302             spank_option_register (sp, opt);
303       If,  however, the option is used in all contexts, the spank_option_reg‐
304       ister needs to be called everywhere.
305
306       In addition to spank_option_register, plugins may also  export  options
307       to  Slurm  by  defining  a table of struct spank_option with the symbol
308       name spank_options. This method, however, is not supported for use with
309       sbatch  and  salloc  (allocator  context),  thus  the  use of spank_op‐
310       tion_register is preferred. When using the spank_options table, the fi‐
311       nal element in the array must be filled with zeros. A SPANK_OPTIONS_TA‐
312       BLE_END macro is provided in <slurm/spank.h> for this purpose.
313
314       When an option is provided by the user on the  local  side,  either  by
315       command  line  options  or by environment variables, Slurm will immedi‐
316       ately invoke the option's callback with remote=0. This is meant for the
317       plugin  to  do  local sanity checking of the option before the value is
318       sent to the remote side during job launch. If  the  argument  the  user
319       specified  is  invalid,  the  plugin  should issue an error and issue a
320       non-zero return code from the callback. The plugin should  be  able  to
321       handle cases where the spank option is set multiple times through envi‐
322       ronment variables and command line options. Environment  variables  are
323       processed before command line options.
324
325       On the remote side, options and their arguments are registered just af‐
326       ter SPANK plugins are loaded  and  before  the  spank_init  handler  is
327       called.  This allows plugins to modify behavior of all plugin function‐
328       ality based on the value of user-provided options.
329
330       As an alternative to use of an option  callback  and  global  variable,
331       plugins  can  use  the spank_option_getopt option to check for supplied
332       options after option processing. This function has the prototype:
333          spank_err_t spank_option_getopt(spank_t sp,
334              struct spank_option *opt, char **optargp);
335       This function returns ESPANK_SUCCESS  if  the  option  defined  in  the
336       struct  spank_option  opt  has  been  used  by  the user. If optargp is
337       non-NULL then it is set to any option argument passed  (if  the  option
338       takes  an  argument). The use of this method is required to process op‐
339       tions    in    job_script    context    (slurm_spank_job_prolog     and
340       slurm_spank_job_epilog).  This  function is valid in the following con‐
341       texts:       slurm_spank_job_prolog,       slurm_spank_local_user_init,
342       slurm_spank_user_init,                slurm_spank_task_init_privileged,
343       slurm_spank_task_init, slurm_spank_task_exit, and  slurm_spank_job_epi‐
344       log.
345
346

CONFIGURATION

348       The default SPANK plug-in stack configuration file is plugstack.conf in
349       the same directory as slurm.conf(5), though this may be changed via the
350       Slurm  config  parameter  PlugStackConfig.  Normally the plugstack.conf
351       file should be identical on all nodes of the cluster.  The config  file
352       lists SPANK plugins, one per line, along with whether the plugin is re‐
353       quired or optional, and any global arguments that are to be  passed  to
354       the  plugin  for runtime configuration.  Comments are preceded with '#'
355       and extend to the end of the line.  If the configuration file is  miss‐
356       ing or empty, it will simply be ignored.
357
358       NOTE:  The SPANK plugins need to be installed on the machines that exe‐
359       cute slurmd (compute nodes) as well as on the machines that execute job
360       allocation utilities such as salloc, sbatch, etc (login nodes).
361
362       The format of each non-comment line in the configuration file is:
363         required/optional   plugin   arguments
364        For example:
365         optional /usr/lib/slurm/test.so
366       Tells  slurmd  to  load  the plugin test.so passing no arguments.  If a
367       SPANK plugin is required, then failure of any of the plugin's functions
368       will  cause  slurmd, or the job allocator command to terminate the job,
369       while optional plugins only cause a warning.
370
371       If a fully-qualified path is not specified for a plugin, then the  cur‐
372       rently configured PluginDir in slurm.conf(5) is searched.
373
374       SPANK  plugins  are stackable, meaning that more than one plugin may be
375       placed into the config file. The plugins will simply be called  in  or‐
376       der, one after the other, and appropriate action taken on failure given
377       that state of the plugin's optional flag.
378
379       Additional config files or directories of config files may be  included
380       in  plugstack.conf  with  the include keyword. The include keyword must
381       appear on its own line, and takes a glob as its parameter, so  multiple
382       files may be included from one include line. For example, the following
383       syntax will load all config files  in  the  /etc/slurm/plugstack.conf.d
384       directory, in local collation order:
385         include /etc/slurm/plugstack.conf.d/*
386       which  might  be  considered  a  more flexible method for building up a
387       spank plugin stack.
388
389       The SPANK config file is re-read on each job  launch,  so  editing  the
390       config  file will not affect running jobs. However care should be taken
391       so that a partially edited config file is not read by a launching job.
392
393

Errors

395       When SPANK plugin results in a non-zero result, the  following  changes
396       will result:
397
398
399       ┌──────┬────────────────────────────────┬─────────┬────────┬───────────┬────────┐
400       │Command│Function                         │Context   │Exitcode │Drains Node │Fails job│
401       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
402       │srun   │slurm_spank_init                 │local     │1        │no          │  yes   │
403       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
404       │srun   │slurm_spank_init_post_opt        │local     │1        │no          │  yes   │
405       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
406       │srun   │slurm_spank_local_user_init      │local     │1        │no          │  no    │
407       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
408       │srun   │slurm_spank_user_init            │remote    │0        │no          │  no    │
409       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
410       │srun   │slurm_spank_task_init_privileged │remote    │1        │no          │  yes   │
411       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
412       │srun   │slurm_spank_task_post_fork       │remote    │0        │no          │  no    │
413       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
414       │srun   │slurm_spank_task_init            │remote    │1        │no          │  yes   │
415       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
416       │srun   │slurm_spank_task_exit            │remote    │0        │no          │  no    │
417       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
418       │srun   │slurm_spank_exit                 │local     │0        │no          │  yes   │
419       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
420       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
421       │salloc │slurm_spank_init                 │allocator │1        │no          │  yes   │
422       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
423       │salloc │slurm_spank_init_post_opt        │allocator │1        │no          │  yes   │
424       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
425       │salloc │slurm_spank_init                 │local     │1        │no          │  yes   │
426       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
427       │salloc │slurm_spank_init_post_opt        │local     │1        │no          │  yes   │
428       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
429       │salloc │slurm_spank_local_user_init      │local     │1        │no          │  yes   │
430       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
431       │salloc │slurm_spank_user_init            │remote    │0        │no          │  no    │
432       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
433       │salloc │slurm_spank_task_init_privileged │remote    │1        │no          │  yes   │
434       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
435       │salloc │slurm_spank_task_post_fork       │remote    │0        │no          │  no    │
436       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
437       │salloc │slurm_spank_task_init            │remote    │1        │no          │  yes   │
438       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
439       │salloc │slurm_spank_task_exit            │remote    │0        │no          │  no    │
440       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
441       │salloc │slurm_spank_exit                 │local     │0        │no          │  yes   │
442       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
443       │salloc │slurm_spank_exit                 │allocator │0        │no          │  yes   │
444       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
445       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
446       │sbatch │slurm_spank_init                 │allocator │1        │no          │  yes   │
447       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
448       │sbatch │slurm_spank_init_post_opt        │allocator │1        │no          │  yes   │
449       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
450       │sbatch │slurm_spank_init                 │local     │1        │no          │  yes   │
451       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
452       │sbatch │slurm_spank_init_post_opt        │local     │1        │no          │  yes   │
453       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
454       │sbatch │slurm_spank_local_user_init      │local     │1        │no          │  yes   │
455       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
456       │sbatch │slurm_spank_user_init            │remote    │0        │yes         │  no    │
457       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
458       │sbatch │slurm_spank_task_init_privileged │remote    │1        │no          │  yes   │
459       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
460       │sbatch │slurm_spank_task_post_fork       │remote    │0        │yes         │  no    │
461       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
462       │sbatch │slurm_spank_task_init            │remote    │1        │no          │  yes   │
463       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
464       │sbatch │slurm_spank_task_exit            │remote    │0        │no          │  no    │
465       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
466       │sbatch │slurm_spank_exit                 │local     │0        │no          │  no    │
467       ├──────┼────────────────────────────────┼─────────┼────────┼───────────┼────────┤
468       │sbatch │slurm_spank_exit                 │allocator │0        │no          │  no    │
469       └──────┴────────────────────────────────┴─────────┴────────┴───────────┴────────┘
470       NOTE: The behavior for ProctrackType=proctrack/pgid may result in time‐
471       outs for slurm_spank_task_post_fork with remote context on failure.
472
473

COPYING

475       Portions copyright (C) 2010-2022 SchedMD LLC.  Copyright (C)  2006  The
476       Regents  of  the University of California.  Produced at Lawrence Liver‐
477       more  National  Laboratory  (cf,  DISCLAIMER).   CODE-OCEC-09-009.  All
478       rights reserved.
479
480       This  file  is  part  of Slurm, a resource management program.  For de‐
481       tails, see <https://slurm.schedmd.com/>.
482
483       Slurm is free software; you can redistribute it and/or modify it  under
484       the  terms  of  the GNU General Public License as published by the Free
485       Software Foundation; either version 2 of the License, or (at  your  op‐
486       tion) any later version.
487
488       Slurm  is  distributed  in the hope that it will be useful, but WITHOUT
489       ANY WARRANTY; without even the implied warranty of  MERCHANTABILITY  or
490       FITNESS  FOR  A PARTICULAR PURPOSE.  See the GNU General Public License
491       for more details.
492

FILES

494       /etc/slurm/slurm.conf - Slurm configuration file.
495       /etc/slurm/plugstack.conf - SPANK configuration file.
496       /usr/include/slurm/spank.h - SPANK header file.
497

SEE ALSO

499       srun(1), slurm.conf(5)
500
501
502
503July 2022                       Slurm Component                       SPANK(8)
Impressum