1GE_CONF(5) Grid Engine File Formats GE_CONF(5)
2
6 ge_conf - Grid Engine configuration files
7
9 ge_conf defines the global and local Grid Engine configurations and can
10 be shown/modified by qconf(1) using the -sconf/-mconf options. Only
11 root or the cluster administrator may modify ge_conf.
12 At its initial start-up, ge_qmaster(8) checks to see if a valid Grid
14 Engine configuration is available at a well known location in the Grid
15 Engine internal directory hierarchy. If so, it loads that configura‐
16 tion information and proceeds. If not, ge_qmaster(8) writes a generic
17 configuration containing default values to that same location. The
18 Grid Engine execution daemons ge_execd(8) upon start-up retrieve their
19 configuration from ge_qmaster(8).
20 The actual configuration for both ge_qmaster(8) and ge_execd(8) is a
22 superposition of a global configuration and a local configuration per‐
23 tinent for the host on which a master or execution daemon resides. If
24 a local configuration is available, its entries overwrite the corre‐
25 sponding entries of the global configuration. Note: The local configu‐
26 ration does not have to contain all valid configuration entries, but
27 only those which need to be modified against the global entries.
28 Note: Grid Engine allows backslashes (\) be used to escape newline
30 (\newline) characters. The backslash and the newline are replaced with
31 a space (" ") character before any interpretation.
32
34 The paragraphs that follow provide brief descriptions of the individual
35 parameters that compose the global and local configurations for a Grid
36 Engine cluster:
37 execd_spool_dir
39 The execution daemon spool directory path. Again, a feasible spool
40 directory requires read/write access permission for root. The entry in
41 the global configuration for this parameter can be overwritten by exe‐
42 cution host local configurations, i.e. each ge_execd(8) may have a pri‐
43 vate spool directory with a different path, in which case it needs to
44 provide read/write permission for the root account of the corresponding
45 execution host only.
46 Under execd_spool_dir a directory named corresponding to the unquali‐
48 fied hostname of the execution host is opened and contains all informa‐
49 tion spooled to disk. Thus, it is possible for the execd_spool_dirs of
50 all execution hosts to physically reference the same directory path
51 (the root access restrictions mentioned above need to be met, however).
52 Changing the global execd_spool_dir parameter set at installation time
54 is not supported in a running system. If the change should still be
55 done it is required to restart all affected execution daemons. Please
56 make sure running jobs have finished before doing so, otherwise running
57 jobs will be lost.
58 The default location for the execution daemon spool directory is
61 $GE_ROOT/$GE_CELL/spool.
62 The global configuration entry for this value may be overwritten by the
64 execution host local configuration.
65 mailer
67 mailer is the absolute pathname to the electronic mail delivery agent
68 on your system. It must accept the following syntax:
69 mailer -s <subject-of-mail-message> <recipient>
71 Each ge_execd(8) may use a private mail agent. Changing mailer will
73 take immediate effect.
74 The default for mailer depends on the operating system of the host on
76 which the Grid Engine master installation was run. Common values are
77 /bin/mail or /usr/bin/Mail.
78 The global configuration entry for this value may be overwritten by the
80 execution host local configuration.
81 xterm
83 xterm is the absolute pathname to the X Window System terminal emula‐
84 tor, xterm(1).
85 Each ge_execd(8) may use a private mail agent. Changing xterm will take
87 immediate effect.
88 The default for xterm is /usr/bin/xterm.
90 The global configuration entry for this value may be overwritten by the
92 execution host local configuration.
93 load_sensor
95 A comma separated list of executable shell script paths or programs to
96 be started by ge_execd(8) and to be used in order to retrieve site con‐
97 figurable load information (e.g. free space on a certain disk parti‐
98 tion).
99 Each ge_execd(8) may use a set of private load_sensor programs or
101 scripts. Changing load_sensor will take effect after two load report
102 intervals (see load_report_time). A load sensor will be restarted auto‐
103 matically if the file modification time of the load sensor executable
104 changes.
105 The global configuration entry for this value may be overwritten by the
107 execution host local configuration.
108 In addition to the load sensors configured via load_sensor, ge_exec(8)
110 searches for an executable file named qloadsensor in the execution
111 host's Grid Engine binary directory path. If such a file is found, it
112 is treated like the configurable load sensors defined in load_sensor.
113 This facility is intended for pre-installing a default load sensor.
114 prolog
116 The executable path of a shell script that is started before execution
117 of Grid Engine jobs with the same environment setting as that for the
118 Grid Engine jobs to be started afterwards. An optional prefix "user@"
119 specifies the user under which this procedure is to be started. The
120 procedures standard output and the error output stream are written to
121 the same file used also for the standard output and error output of
122 each job. This procedure is intended as a means for the Grid Engine
123 administrator to automate the execution of general site specific tasks
124 like the preparation of temporary file systems with the need for the
125 same context information as the job. Each ge_execd(8) may use a pri‐
126 vate prolog script. Correspondingly, the execution host local configu‐
127 rations is can be overwritten by the queue configuration (see
128 queue_conf(5) ). Changing prolog will take immediate effect.
129 The default for prolog is the special value NONE, which prevents from
131 execution of a prolog script.
132 The following special variables expanded at runtime can be used
134 (besides any other strings which have to be interpreted by the proce‐
135 dure) to constitute a command line:
136 $host The name of the host on which the prolog or epilog procedures
138 are started.
139 $job_owner
141 The user name of the job owner.
142 $job_id
144 Grid Engine's unique job identification number.
145 $job_name
147 The name of the job.
148 $processors
150 The processors string as contained in the queue configuration
151 (see queue_conf(5)) of the master queue (the queue in which the
152 prolog and epilog procedures are started).
153 $queue The cluster queue name of the master queue instance, i.e. the
155 cluster queue in which the prolog and epilog procedures are
156 started.
157 $stdin_path
159 The pathname of the stdin file. This is always /dev/null for
160 prolog, pe_start, pe_stop and epilog. It is the pathname of the
161 stdin file for the job in the job script. When delegated file
162 staging is enabled, this path is set to $fs_stdin_tmp_path. When
163 delegated file staging is not enabled, it is the stdin pathname
164 given via DRMAA or qsub.
165 $stdout_path
167 $stderr_path
169 The pathname of the stdout/stderr file. This always points to
170 the output/error file. When delegated file staging is enabled,
171 this path is set to $fs_stdout_tmp_path/$fs_stderr_tmp_path.
172 When delegated file staging is not enabled, it is the std‐
173 out/stderr pathname given via DRMAA or qsub.
174 $merge_stderr
176 If merging of stderr and stdout is requested, this flag is "1",
177 otherwise it is "0". If this flag is 1, stdout and stderr are
178 merged in one file, the stdout file. Merging of stderr and std‐
179 out can be requested via the DRMAA job template attribute
180 'drmaa_join_files' (see drmaa_attributes(3) ) or the qsub param‐
181 eter '-j y' (see qsub(1) ).
182 $fs_stdin_host
184 When delegated file staging is requested for the stdin file,
185 this is the name of the host where the stdin file has to be
186 copied from before the job is started.
187 $fs_stdout_host
189 $fs_stderr_host
191 When delegated file staging is requested for the stdout/stderr
192 file, this is the name of the host where the stdout/stderr file
193 has to be copied to after the job has run.
194 $fs_stdin_path
196 When delegated file staging is requested for the stdin file,
197 this is the pathname of the stdin file on the host
198 $fs_stdin_host.
199 $fs_stdout_path
201 $fs_stderr_path
203 When delegated file staging is requested for the stdout/stderr
204 file, this is the pathname of the stdout/stderr file on the host
205 $fs_stdout_host/$fs_stderr_host.
206 $fs_stdin_tmp_path
208 When delegated file staging is requested for the stdin file,
209 this is the destination pathname of the stdin file on the execu‐
210 tion host. The prolog script must copy the stdin file from
211 $fs_stdin_host:$fs_stdin_path to localhost:$fs_stdin_tmp_path to
212 establish delegated file staging of the stdin file.
213 $fs_stdout_tmp_path
215 $fs_stderr_tmp_path
217 When delegated file staging is requested for the stdout/stderr
218 file, this is the source pathname of the stdout/stderr file on
219 the execution host. The epilog script must copy the stdout file
220 from localhost:$fs_stdout_tmp_path to $fs_stdout_host:$fs_std‐
221 out_path (the stderr file from localhost:$fs_stderr_tmp_path to
222 $fs_stderr_host:$fs_stderr_path) to establish delegated file
223 staging of the stdout/stderr file.
224 $fs_stdin_file_staging
226 $fs_stdout_file_staging
228 $fs_stderr_file_staging
230 When delegated file staging is requested for the stdin/std‐
231 out/stderr file, the flag is set to "1", otherwise it is set to
232 "0" (see in delegated_file_staging how to enable delegated file
233 staging).
234 These three flags correspond to the DRMAA job template attribute
236 'drmaa_transfer_files' (see drmaa_attributes(3) ).
237 The global configuration entry for this value may be overwritten by the
239 execution host local configuration.
240 Exit codes for the prolog attribute can be interpreted based on the
242 following exit values:
243 0: Success
244 99: Reschedule job
245 100: Put job in error state
246 Anything else: Put queue in error state
247 epilog
249 The executable path of a shell script that is started after execution
250 of Grid Engine jobs with the same environment setting as that for the
251 Grid Engine jobs that has just completed. An optional prefix "user@"
252 specifies the user under which this procedure is to be started. The
253 procedures standard output and the error output stream are written to
254 the same file used also for the standard output and error output of
255 each job. This procedure is intended as a means for the Grid Engine
256 administrator to automate the execution of general site specific tasks
257 like the cleaning up of temporary file systems with the need for the
258 same context information as the job. Each ge_execd(8) may use a pri‐
259 vate epilog script. Correspondingly, the execution host local configu‐
260 rations is can be overwritten by the queue configuration (see
261 queue_conf(5) ). Changing epilog will take immediate effect.
262 The default for epilog is the special value NONE, which prevents from
264 execution of a epilog script. The same special variables as for pro‐
265 log can be used to constitute a command line.
266 The global configuration entry for this value may be overwritten by the
268 execution host local configuration.
269 Exit codes for the epilog attribute can be interpreted based on the
271 following exit values:
272 0: Success
273 99: Reschedule job
274 100: Put job in error state
275 Anything else: Put queue in error state
276 shell_start_mode
278 Note: Deprecated, may be removed in future release.
279 This parameter defines the mechanisms which are used to actually invoke
280 the job scripts on the execution hosts. The following values are recog‐
281 nized:
282 unix_behavior
284 If a user starts a job shell script under UNIX interactively by
285 invoking it just with the script name the operating system's
286 executable loader uses the information provided in a comment
287 such as `#!/bin/csh' in the first line of the script to detect
288 which command interpreter to start to interpret the script. This
289 mechanism is used by Grid Engine when starting jobs if
290 unix_behavior is defined as shell_start_mode.
291 posix_compliant
293 POSIX does not consider first script line comments such a
294 `#!/bin/csh' as significant. The POSIX standard for batch queu‐
295 ing systems (P1003.2d) therefore requires a compliant queuing
296 system to ignore such lines but to use user specified or config‐
297 ured default command interpreters instead. Thus, if
298 shell_start_mode is set to posix_compliant Grid Engine will
299 either use the command interpreter indicated by the -S option of
300 the qsub(1) command or the shell parameter of the queue to be
301 used (see queue_conf(5) for details).
302 script_from_stdin
304 Setting the shell_start_mode parameter either to posix_compliant
305 or unix_behavior requires you to set the umask in use for
306 ge_execd(8) such that every user has read access to the
307 active_jobs directory in the spool directory of the correspond‐
308 ing execution daemon. In case you have prolog and epilog scripts
309 configured, they also need to be readable by any user who may
310 execute jobs.
311 If this violates your site's security policies you may want to
312 set shell_start_mode to script_from_stdin. This will force Grid
313 Engine to open the job script as well as the epilog and prolog
314 scripts for reading into STDIN as root (if ge_execd(8) was
315 started as root) before changing to the job owner's user
316 account. The script is then fed into the STDIN stream of the
317 command interpreter indicated by the -S option of the qsub(1)
318 command or the shell parameter of the queue to be used (see
319 queue_conf(5) for details).
320 Thus setting shell_start_mode to script_from_stdin also implies
321 posix_compliant behavior. Note, however, that feeding scripts
322 into the STDIN stream of a command interpreter may cause trouble
323 if commands like rsh(1) are invoked inside a job script as they
324 also process the STDIN stream of the command interpreter. These
325 problems can usually be resolved by redirecting the STDIN chan‐
326 nel of those commands to come from /dev/null (e.g. rsh host date
327 < /dev/null). Note also, that any command-line options associ‐
328 ated with the job are passed to the executing shell. The shell
329 will only forward them to the job if they are not recognized as
330 valid shell options.
331 Changes to shell_start_mode will take immediate effect. The default
333 for shell_start_mode is posix_compliant.
334 This value is a global configuration parameter only. It cannot be over‐
336 written by the execution host local configuration.
337 login_shells
339 UNIX command interpreters like the Bourne-Shell (see sh(1)) or the C-
340 Shell (see csh(1)) can be used by Grid Engine to start job scripts. The
341 command interpreters can either be started as login-shells (i.e. all
342 system and user default resource files like .login or .profile will be
343 executed when the command interpreter is started and the environment
344 for the job will be set up as if the user has just logged in) or just
345 for command execution (i.e. only shell specific resource files like
346 .cshrc will be executed and a minimal default environment is set up by
347 Grid Engine - see qsub(1)). The parameter login_shells contains a
348 comma separated list of the executable names of the command inter‐
349 preters to be started as login-shells. Shells in this list are only
350 started as login shells if the parameter shell_start_mode (see above)
351 is set to posix_compliant.
352 Changes to login_shells will take immediate effect. The default for
354 login_shells is sh,csh,tcsh,ksh.
355 This value is a global configuration parameter only. It cannot be over‐
357 written by the execution host local configuration.
358 min_uid
360 min_uid places a lower bound on user IDs that may use the cluster.
361 Users whose user ID (as returned by getpwnam(3)) is less than min_uid
362 will not be allowed to run jobs on the cluster.
363 Changes to min_uid will take immediate effect. The default for min_uid
365 is 0.
366 This value is a global configuration parameter only. It cannot be over‐
368 written by the execution host local configuration.
369 min_gid
371 This parameter sets the lower bound on group IDs that may use the clus‐
372 ter. Users whose default group ID (as returned by getpwnam(3)) is less
373 than min_gid will not be allowed to run jobs on the cluster.
374 Changes to min_gid will take immediate effect. The default for min_gid
376 is 0.
377 This value is a global configuration parameter only. It cannot be over‐
379 written by the execution host local configuration.
380 user_lists
382 The user_lists parameter contains a comma separated list of user access
383 lists as described in access_list(5). Each user contained in at least
384 one of the enlisted access lists has access to the cluster. If the
385 user_lists parameter is set to NONE (the default) any user has access
386 not explicitly excluded via the xuser_lists parameter described below.
387 If a user is contained both in an access list enlisted in xuser_lists
388 and user_lists the user is denied access to the cluster.
389 Changes to user_lists will take immediate effect
391 This value is a global configuration parameter only. It cannot be over‐
393 written by the execution host local configuration.
394 xuser_lists
396 The xuser_lists parameter contains a comma separated list of user
397 access lists as described in access_list(5). Each user contained in at
398 least one of the enlisted access lists is denied access to the cluster.
399 If the xuser_lists parameter is set to NONE (the default) any user has
400 access. If a user is contained both in an access list enlisted in
401 xuser_lists and user_lists (see above) the user is denied access to the
402 cluster.
403 Changes to xuser_lists will take immediate effect
405 This value is a global configuration parameter only. It cannot be over‐
407 written by the execution host local configuration.
408 administrator_mail
410 administrator_mail specifies a comma separated list of the electronic
411 mail address(es) of the cluster administrator(s) to whom internally-
412 generated problem reports are sent. The mail address format depends on
413 your electronic mail system and how it is configured; consult your sys‐
414 tem's configuration guide for more information.
415 Changing administrator_mail takes immediate effect. The default for
417 administrator_mail is an empty mail list.
418 This value is a global configuration parameter only. It cannot be over‐
420 written by the execution host local configuration.
421 projects
423 The projects list contains all projects which are granted access to
424 Grid Engine. User belonging to none of these projects cannot use Grid
425 Engine. If users belong to projects in the projects list and the xpro‐
426 jects list (see below), they also cannot use the system.
427 Changing projects takes immediate effect. The default for projects is
429 none.
430 This value is a global configuration parameter only. It cannot be over‐
432 written by the execution host local configuration.
433 xprojects
435 The xprojects list contains all projects that are denied access to Grid
436 Engine. User belonging to one of these projects cannot use Grid Engine.
437 If users belong to projects in the projects list (see above) and the
438 xprojects list, they also cannot use the system.
439 Changing xprojects takes immediate effect. The default for xprojects
441 is none.
442 This value is a global configuration parameter only. It cannot be over‐
444 written by the execution host local configuration.
445 load_report_time
447 System load is reported periodically by the execution daemons to
448 ge_qmaster(8). The parameter load_report_time defines the time inter‐
449 val between load reports.
450 Each ge_execd(8) may use a different load report time. Changing
452 load_report_time will take immediate effect.
453 Note: Be careful when modifying load_report_time. Reporting load too
455 frequently might block ge_qmaster(8) especially if the number of execu‐
456 tion hosts is large. Moreover, since the system load typically
457 increases and decreases smoothly, frequent load reports hardly offer
458 any benefit.
459 The default for load_report_time is 40 seconds.
461 The global configuration entry for this value may be overwritten by the
463 execution host local configuration.
464 reschedule_unknown
466 Determines whether jobs on hosts in unknown state are rescheduled and
467 thus sent to other hosts. Hosts are registered as unknown if ge_mas‐
468 ter(8) cannot establish contact to the ge_execd(8) on those hosts (see
469 max_unheard ). Likely reasons are a breakdown of the host or a break‐
470 down of the network connection in between, but also ge_execd(8) may not
471 be executing on such hosts.
472 In any case, Grid Engine can reschedule jobs running on such hosts to
474 another system. reschedule_unknown controls the time which Grid Engine
475 will wait before jobs are rescheduled after a host became unknown. The
476 time format specification is hh:mm:ss. If the special value 00:00:00 is
477 set, then jobs will not be rescheduled from this host.
478 Rescheduling is only initiated for jobs which have activated the rerun
480 flag (see the -r y option of qsub(1) and the rerun option of
481 queue_conf(5)). Parallel jobs are only rescheduled if the host on
482 which their master task executes is in unknown state. The behavior of
483 reschedule_unknown for parallel jobs and for jobs without the rerun
484 flag be set can be adjusted using the qmaster_params settings
485 ENABLE_RESCHEDULE_KILL and ENABLE_RESCHEDULE_SLAVE.
486 Checkpointing jobs will only be rescheduled when the when option of the
488 corresponding checkpointing environment contains an appropriate flag.
489 (see checkpoint(5)). Interactive jobs (see qsh(1), qrsh(1), qtcsh(1))
490 are not rescheduled.
491 The default for reschedule_unknown is 00:00:00
493 The global configuration entry for this value may be over written by
495 the execution host local configuration.
496 max_unheard
498 If ge_qmaster(8) could not contact or was not contacted by the execu‐
499 tion daemon of a host for max_unheard seconds, all queues residing on
500 that particular host are set to status unknown. ge_qmaster(8), at
501 least, should be contacted by the execution daemons in order to get the
502 load reports. Thus, max_unheard should by greater than the
503 load_report_time (see above).
504 Changing max_unheard takes immediate effect. The default for
506 max_unheard is 5 minutes.
507 This value is a global configuration parameter only. It cannot be over‐
509 written by the execution host local configuration.
510 loglevel
512 This parameter specifies the level of detail that Grid Engine compo‐
513 nents such as ge_qmaster(8) or ge_execd(8) use to produce informative,
514 warning or error messages which are logged to the messages files in the
515 master and execution daemon spool directories (see the description of
516 the execd_spool_dir parameter above). The following message levels are
517 available:
518 log_err
520 All error events being recognized are logged.
521 log_warning
523 All error events being recognized and all detected signs of
524 potentially erroneous behavior are logged.
525 log_info
527 All error events being recognized, all detected signs of poten‐
528 tially erroneous behavior and a variety of informative messages
529 are logged.
530 Changing loglevel will take immediate effect.
532 The default for loglevel is log_warning.
534 This value is a global configuration parameter only. It cannot be over‐
536 written by the execution host local configuration.
537 max_aj_instances
539 This parameter defines the maximum amount of array task to be scheduled
540 to run simultaneously per array job. An instance of an array task will
541 be created within the master daemon when it gets a start order from the
542 scheduler. The instance will be destroyed when the array task finishes.
543 Thus the parameter provides control mainly over the memory consumption
544 of array jobs in the master and scheduler daemon. It is most useful for
545 very large clusters and very large array jobs. The default for this
546 parameter is 2000. The value 0 will deactivate this limit and will
547 allow the scheduler to start as many array job tasks as suitable
548 resources are available in the cluster.
549 Changing max_aj_instances will take immediate effect.
551 This value is a global configuration parameter only. It cannot be over‐
553 written by the execution host local configuration.
554 max_aj_tasks
556 This parameter defines the maximum number of array job tasks within an
557 array job. ge_qmaster(8) will reject all array job submissions which
558 request more than max_aj_tasks array job tasks. The default for this
559 parameter is 75000. The value 0 will deactivate this limit.
560 Changing max_aj_tasks will take immediate effect.
562 This value is a global configuration parameter only. It cannot be over‐
564 written by the execution host local configuration.
565 max_u_jobs
567 The number of active (not finished) jobs which each Grid Engine user
568 can have in the system simultaneously is controlled by this parameter.
569 A value greater than 0 defines the limit. The default value 0 means
570 "unlimited". If the max_u_jobs limit is exceeded by a job submission
571 then the submission command exits with exit status 25 and an appropri‐
572 ate error message.
573 Changing max_u_jobs will take immediate effect.
575 This value is a global configuration parameter only. It cannot be over‐
577 written by the execution host local configuration.
578 max_jobs
580 The number of active (not finished) jobs simultaneously allowed in Grid
581 Engine is controlled by this parameter. A value greater than 0 defines
582 the limit. The default value 0 means "unlimited". If the max_jobs
583 limit is exceeded by a job submission then the submission command exits
584 with exit status 25 and an appropriate error message.
585 Changing max_jobs will take immediate effect.
587 This value is a global configuration parameter only. It cannot be over‐
589 written by the execution host local configuration.
590 max_advance_reservations
592 The number of active (not finished) Advance Reservations simultaneously
593 allowed in Grid Engine is controlled by this parameter. A value greater
594 than 0 defines the limit. The default value 0 means "unlimited". If the
595 max_advance_reservations limit is exceeded by an Advance Reservation
596 request then the submission command exits with exit status 25 and an
597 appropriate error message.
598 Changing max_advance_reservations will take immediate effect.
600 This value is a global configuration parameter only. It cannot be over‐
602 written by the execution host local configuration.
603 enforce_project
605 If set to true, users are required to request a project whenever sub‐
606 mitting a job. See the -P option to [22mqsub(1) for details.
607 Changing enforce_project will take immediate effect. The default for
609 enforce_project is false.
610 This value is a global configuration parameter only. It cannot be over‐
612 written by the execution host local configuration.
613 enforce_user
615 If set to true, a [22muser(5) must exist to allow for job submission. Jobs
616 are rejected if no corresponding user exists.
617 If set to auto, a [22muser(5) object for the submitting user will automati‐
619 cally be created during job submission, if one does not already exist.
620 The auto_user_oticket, auto_user_fshare, auto_user_default_project, and
621 auto_user_delete_time configuration parameters will be used as default
622 attributes of the new user(5) object.
623 Changing enforce_user will take immediate effect. The default for
625 enforce_user is auto.
626 This value is a global configuration parameter only. It cannot be over‐
628 written by the execution host local configuration.
629 auto_user_oticket
631 The number of override tickets to assign to automatically created
632 user(5) objects. User objects are created automatically if the
633 enforce_user attribute is set to auto.
634 Changing auto_user_oticket will affect any newly created user objects,
636 but will not change user objects created in the past.
637 This value is a global configuration parameter only. It cannot be over‐
639 written by the execution host local configuration.
640 auto_user_fshare
642 The number of functional shares to assign to automatically created
643 user(5) objects. User objects are created automatically if the
644 enforce_user attribute is set to auto.
645 Changing auto_user_fshare will affect any newly created user objects,
647 but will not change user objects created in the past.
648 This value is a global configuration parameter only. It cannot be over‐
650 written by the execution host local configuration.
651 auto_user_default_project
653 The default project to assign to automatically created user(5) objects.
654 User objects are created automatically if the enforce_user attribute is
655 set to auto.
656 Changing auto_user_default_project will affect any newly created user
658 objects, but will not change user objects created in the past.
659 This value is a global configuration parameter only. It cannot be over‐
661 written by the execution host local configuration.
662 auto_user_delete_time
664 The number of seconds of inactivity after which automatically created
665 user(5) objects will be deleted. User objects are created automatically
666 if the enforce_user attribute is set to auto. If the user has no active
667 or pending jobs for the specified amount of time, the object will auto‐
668 matically be deleted. A value of 0 can be used to indicate that the
669 automatically created user object is permanent and should not be auto‐
670 matically deleted.
671 Changing auto_user_delete_time will affect the deletion time for all
673 users with active jobs.
674 This value is a global configuration parameter only. It cannot be over‐
676 written by the execution host local configuration.
677 set_token_cmd
679 Note: Deprecated, may be removed in future release.
680 This parameter is only present if your Grid Engine system is licensed
681 to support AFS.
682 Set_token_cmd points to a command which sets and extends AFS tokens for
684 Grid Engine jobs. In the standard Grid Engine AFS distribution, it is
685 supplied as a script which expects two command line parameters. It
686 reads the token from STDIN, extends the token's expiration time and
687 sets the token:
688 <set_token_cmd> <user> <token_extend_after_seconds>
690 As a shell script this command will call the programs:
692 - SetToken
694 - forge
695 which are provided by your distributor as source code. The script looks
697 as follows:
698 --------------------------------
700 #!/bin/sh
701 # set_token_cmd
702 forge -u $1 -t $2 | SetToken
703 --------------------------------
704 Since it is necessary for forge to read the secret AFS server key, a
706 site might wish to replace the set_token_cmd script by a command, which
707 connects to a custom daemon at the AFS server. The token must be forged
708 at the AFS server and returned to the local machine, where SetToken is
709 executed.
710 Changing set_token_cmd will take immediate effect. The default for
712 set_token_cmd is none.
713 The global configuration entry for this value may be overwritten by the
715 execution host local configuration.
716 pag_cmd
718 Note: Deprecated, may be removed in future release.
719 This parameter is only present if your Grid Engine system is licensed
720 to support AFS.
721 The path to your pagsh is specified via this parameter. The ge_shep‐
723 herd(8) process and the job run in a pagsh. Please ask your AFS admin‐
724 istrator for details.
725 Changing pag_cmd will take immediate effect. The default for pag_cmd
727 is none.
728 The global configuration entry for this value may be overwritten by the
730 execution host local configuration.
731 token_extend_time
733 Note: Deprecated, may be removed in future release.
734 This parameter is only present if your Grid Engine system is licensed
735 to support AFS.
736 The token_extend_time is the time period for which AFS tokens are peri‐
738 odically extended. Grid Engine will call the token extension 30 minutes
739 before the tokens expire until jobs have finished and the corresponding
740 tokens are no longer required.
741 Changing token_extend_time will take immediate effect. The default for
743 token_extend_time is 24:0:0, i.e. 24 hours.
744 The global configuration entry for this value may be overwritten by the
746 execution host local configuration.
747 shepherd_cmd
749 Alternative path to the shepherd_cmd binary. Typically used to call the
750 shepherd binary by a wrapper script or command.
751 Changing shepherd_cmd will take immediate effect. The default for shep‐
753 herd_cmd is none.
754 The global configuration entry for this value may be overwritten by the
756 execution host local configuration.
757 gid_range
759 The gid_range is a comma separated list of range expressions of the
760 form n-m (n as well as m are integer numbers greater than 99), where m
761 is an abbreviation for m-m. These numbers are used in ge_execd(8) to
762 identify processes belonging to the same job.
763 Each ge_execd(8) may use a separate set up group ids for this purpose.
765 All number in the group id range have to be unused supplementary group
766 ids on the system, where the ge_execd(8) is started.
767 Changing gid_range will take immediate effect. There is no default for
769 gid_range. The administrator will have to assign a value for gid_range
770 during installation of Grid Engine.
771 The global configuration entry for this value may be overwritten by the
773 execution host local configuration.
774 qmaster_params
776 A list of additional parameters can be passed to the Grid Engine qmas‐
777 ter. The following values are recognized:
778 ENABLE_ENFORCE_MASTER_LIMIT
780 If this parameter is set then the s_rt, h_rt limit of a running
781 job are tested and executed by the ge_qmaster(8) when the
782 ge_execd(8) where the job is in unknown state.
783 After s_rt or h_rt limit of a job is expired then the master
785 daemon will wait additional time defined by DURATION_OFFSET (see
786 sched_conf(5)). If the execution daemon still cannot be con‐
787 tacted when this additional time is elapsed, then the master
788 daemon will force the deletion of the job (see -f of qdel(1)).
789 For jobs which will be deleted that way an accounting record
791 will be created. As usage the record will contain the last
792 reported online usage, when the execution daemon could contact
793 qmaster. The failed state in the record will be set to 37 to
794 indicate that the job was terminated by a limit enforcement of
795 master daemon.
796 After the restart of ge_qmaster(8) the limit enforcement will at
798 first be triggered after the double of the biggest
799 load_report_interval interval defined in sge_conf(5) has been
800 elapsed. This will give the execution daemons enough time to
801 reregister at master daemon.
802 ENABLE_FORCED_QDEL_IF_UNKNOWN
804 If this parameter is set then a deletion request for a job is
805 automatically interpreted as a forced deletion request (see -f
806 of qdel(1)) if the host, where the job is running is in unknown
807 state.
808 ENABLE_FORCED_QDEL
810 If this parameter is set, non-administrative users can force
811 deletion of their own jobs via the -f option of qdel(1). With‐
812 out this parameter, forced deletion of jobs is only allowed by
813 the Grid Engine manager or operator.
814 Note: Forced deletion for jobs is executed differently depending
816 on whether users are Grid Engine administrators or not. In case
817 of administrative users, the jobs are removed from the internal
818 database of Grid Engine immediately. For regular users, the
819 equivalent of a normal qdel(1) is executed first, and deletion
820 is forced only if the normal cancellation was unsuccessful.
821 FORBID_RESCHEDULE
823 If this parameter is set, re-queuing of jobs cannot be initiated
824 by the job script which is under control of the user. Without
825 this parameter jobs returning the value 99 are rescheduled. This
826 can be used to cause the job to be restarted at a different
827 machine, for instance if there are not enough resources on the
828 current one.
829 FORBID_APPERROR
831 If this parameter is set, the application cannot set itself to
832 error state. Without this parameter jobs returning the value
833 100 are set to error state (and therefore can be manually
834 rescheduled by clearing the error state). This can be used to
835 set the job to error state when a starting condition of the
836 application is not fulfilled before the application itself has
837 been started, or when a clean up procedure (e.g. in the epilog)
838 decides that it is necessary to run the job again, by returning
839 100 in the prolog, pe_start, job script, pe_stop or epilog
840 script.
841 DISABLE_AUTO_RESCHEDULING
843 Note: Deprecated, may be removed in future release.
844 If set to "true" or "1", the reschedule_unknown parameter is not
845 taken into account.
846 ENABLE_RESCHEDULE_KILL
848 If set to "true" or "1", the reschedule_unknown parameter
849 affects also jobs which have the rerun flag not activated (see
850 the -r y option of qsub(1) and the rerun option of
851 queue_conf(5)), but they are just finished as they can't be
852 rescheduled.
853 ENABLE_RESCHEDULE_SLAVE
855 If set to "true" or "1" Grid Engine triggers job rescheduling
856 also when the host where the slave tasks of a parallel job exe‐
857 cutes is in unknown state, if the reschedule_unknown parameter
858 is activated.
859 MAX_DYN_EC
861 Sets the max number of dynamic event clients (as used by qsub
862 -sync y and by Grid Engine DRMAA API library sessions). The
863 default is set to 99. The number of dynamic event clients
864 should not be bigger than half of the number of file descriptors
865 the system has. The number of file descriptors are shared among
866 the connections to all exec hosts, all event clients, and file
867 handles that the qmaster needs.
868 MONITOR_TIME
870 Specifies the time interval when the monitoring information
871 should be printed. The monitoring is disabled by default and can
872 be enabled by specifying an interval. The monitoring is per
873 thread and is written to the messages file or displayed by the
874 "qping -f" command line tool. Example: MONITOR_TIME=0:0:10 gen‐
875 erates and prints the monitoring information approximately every
876 10 seconds. The specified time is a guideline only and not a
877 fixed interval. The interval that is actually used is printed.
878 In this example, the interval could be anything between 9 sec‐
879 onds and 20 seconds.
880 LOG_MONITOR_MESSAGE
882 Monitoring information is logged into the messages files by
883 default. This information can be accessed via by qping(1). If
884 monitoring is always enabled, the messages files can become
885 quite large. This switch disables logging into the messages
886 files, making qping -f the only source of monitoring data.
887 PROF_SIGNAL
889 Profiling provides the user with the possibility to get system
890 measurements. This can be useful for debugging or optimization
891 of the system. The profiling output will be done within the mes‐
892 sages file.
893 Enables the profiling for qmaster signal thread. (e.g.
895 PROF_SIGNAL=true)
896 PROF_WORKER
898 Enables the profiling for qmaster worker threads. (e.g.
899 PROF_WORKER=true)
900 PROF_LISTENER
902 Enables the profiling for qmaster listener threads. (e.g.
903 PROF_LISTENER=true)
904 PROF_DELIVER
906 Enables the profiling for qmaster event deliver thread. (e.g.
907 PROF_DELIVER=true)
908 PROF_TEVENT
910 Enables the profiling for qmaster timed event thread. (e.g.
911 PROF_TEVENT=true)
912 Please note, that the cpu utime and stime values contained in the pro‐
914 filing output are not per thread cpu times. These cpu usage statistics
915 are per process statistics. So the printed profiling values for cpu
916 mean "cpu time consumed by sge_qmaster (all threads) while the reported
917 profiling level was active".
918 STREE_SPOOL_INTERVAL
920 Sets the time interval for spooling the sharetree usage. The
921 default is set to 00:04:00. The setting accepts colon-separated
922 string or seconds. There is no setting to turn the sharetree
923 spooling off. (e.g. STREE_SPOOL_INTERVAL=00:02:00)
924 MAX_JOB_DELETION_TIME
926 Sets the value of how long the qmaster will spend deleting jobs.
927 After this time, the qmaster will continue with other tasks and
928 schedule the deletion of remaining jobs at a later time. The
929 default value is 3 seconds, and will be used if no value is
930 entered. The range of valid values is > 0 and <= 5. (e.g.
931 MAX_JOB_DELETION_TIME=1)
932 gdi_timeout
934 Sets how long the communication will wait for gdi send/receive
935 operations. The default value is set to 60 seconds. After this
936 time, the communication library will retry, if "gdi_retries" is
937 configured, receiving the gdi request. In case of not configured
938 "gdi_retries" the communication will return with a "gdi receive
939 failure" (e.g. gdi_timeout=120 will set the timeout time to 120
940 sec) Configuring no gdi_timeout value, the value defaults to 60
941 sec.
942 gdi_retries
944 Sets how often the gdi receive call will be repeated until the
945 gdi receive error appears. The default is set to 0. In this case
946 the call will be done 1 time with no retry. Setting the value
947 to -1 the call will be done permanently. In combination with
948 gdi_timeout parameter it is possible to configure a system with
949 eg. slow NFS, to make sure that all jobs will be submitted.
950 (e.g. gdi_retries=4)
951 cl_ping
953 Turns on/off a communication library ping. This parameter will
954 create additional debug output. This output shows information
955 about the error messages which are returned by communication and
956 it will give information about the application status of the
957 qmaster. eg, if it's unclear what's the reason for gdi timeouts,
958 this may show you some useful messages. The default value is
959 false (off) (e.g cl_ping=false)
960 SCHEDULER_TIMEOUT
962 Setting this parameter allows the scheduler GDI event acknowl‐
963 edge timeout to be manually configured to a specific value. Cur‐
964 rently the default value is 10 minutes with the default sched‐
965 uler configuration and limited between 600 and 1200 seconds.
966 Value is limited only in case of default value. The default
967 value depends on the current scheduler configuration. The SCHED‐
968 ULER_TIMEOUT value is specified in seconds.
969 jsv_timeout
971 This parameter measures the response time of the server JSV. In
972 the event that the response time of the JSV is longer than the
973 timeout value specified, this will cause the JSV to be re-
974 started. The default value for the timeout is 10 seconds and if
975 modified, must be greater than 0. If the timeout has been reach,
976 the JSV will only try to re-start once, if the timeout is
977 reached again an error will occur.
978 jsv_threshold
980 The threshold of a JSV is measured as the time it takes to per‐
981 form a server job verification. If this value is greater than
982 the user defined value, it will cause logging to appear in the
983 qmaster messages file at the INFO level. By setting this value
984 to 0, all jobs will be logged in the qmaster messages file. This
985 value is specified in milliseconds and has a default value of
986 5000.
987 Changing qmaster_params will take immediate effect, except gdi_timeout,
989 gdi_retries, cl_ping, these will take effect only for new connections.
990 The default for qmaster_params is none.
991 This value is a global configuration parameter only. It cannot be over‐
993 written by the execution host local configuration.
994 execd_params
996 This is used for passing additional parameters to the Grid Engine exe‐
997 cution daemon. The following values are recognized:
998 ACCT_RESERVED_USAGE
1000 If this parameter is set to true, the usage of reserved
1001 resources is used for the accounting entries cpu, mem and io
1002 instead of the measured usage.
1003 ENABLE_WINDOMACC
1005 If this parameter is set to true, Windows Domain accounts (Win‐
1006 DomAcc) are used on Windows hosts. These accounts require the
1007 use of sgepasswd(1) (see also sgepasswd(5)). If this parameter
1008 is set to false or is not set, local Windows accounts are used.
1009 On non-Windows hosts, this parameter is ignored.
1010 KEEP_ACTIVE
1012 This value should only be set for debugging purposes. If set to
1013 true, the execution daemon will not remove the spool directory
1014 maintained by ge_shepherd(8) for a job.
1015 PTF_MIN_PRIORITY, PTF_MAX_PRIORITY
1017 The maximum/minimum priority which Grid Engine will assign to a
1018 job. Typically this is a negative/positive value in the range
1019 of -20 (maximum) to 19 (minimum) for systems which allow setting
1020 of priorities with the nice(2) system call. Other systems may
1021 provide different ranges.
1022 The default priority range (varies from system to system) is
1023 installed either by removing the parameters or by setting a
1024 value of -999.
1025 See the "messages" file of the execution daemon for the prede‐
1026 fined default value on your hosts. The values are logged during
1027 the startup of the execution daemon.
1028 PROF_EXECD
1030 Enables the profiling for the execution daemon. (e.g.
1031 PROF_EXECD=true)
1032 NOTIFY_KILL
1034 The parameter allows you to change the notification signal for
1035 the signal SIGKILL (see -notify option of qsub(1)). The parame‐
1036 ter either accepts signal names (use the -l option of kill(1))
1037 or the special value none. If set to none, no notification sig‐
1038 nal will be sent. If it is set to TERM, for instance, or another
1039 signal name then this signal will be sent as notification sig‐
1040 nal.
1041 NOTIFY_SUSP
1043 With this parameter it is possible to modify the notification
1044 signal for the signal SIGSTOP (see -notify parameter of
1045 qsub(1)). The parameter either accepts signal names (use the -l
1046 option of kill(1)) or the special value none. If set to none, no
1047 notification signal will be sent. If it is set to TSTP, for
1048 instance, or another signal name then this signal will be sent
1049 as notification signal.
1050 SHARETREE_RESERVED_USAGE
1052 Note: Deprecated, may be removed in future release.
1053 If this parameter is set to true, the usage of reserved
1054 resources is taken for the Grid Engine share tree consumption
1055 instead of measured usage.
1056 Note: When running tightly integrated jobs with SHARE‐
1057 TREE_RESERVED_USAGE set, and with having accounting_summary
1058 enabled in the parallel environment, reserved usage will only be
1059 reported by the master task of the parallel job. No per paral‐
1060 lel task usage records will be sent from execd to qmaster, which
1061 can significantly reduce load on qmaster when running large
1062 tightly integrated parallel jobs.
1063 USE_QSUB_GID
1065 If this parameter is set to true, the primary group id active
1066 when a job was submitted will be set to become the primary group
1067 id for job execution. If the parameter is not set, the primary
1068 group id as defined for the job owner in the execution host
1069 passwd(5) file is used.
1070 The feature is only available for jobs submitted via qsub(1),
1071 qrsh(1), qmake(1) and qtcsh(1). Also, it only works for qrsh(1)
1072 jobs (and thus also for qtcsh(1) and qmake(1)) if rsh and rshd
1073 components are used which are provided with Grid Engine (i.e.,
1074 the rsh_daemon and rsh_command parameters may not be changed
1075 from the default).
1076 S_DESCRIPTORS, H_DESCRIPTORS, S_MAXPROC, H_MAXPROC,
1078 S_MEMORYLOCKED, H_MEMORYLOCKED, S_LOCKS, H_LOCKS
1080 Specifies soft and hard resource limits as implemented by the
1081 setrlimit(2) system call. See this manual page on your system
1082 for more information. These parameters complete the list of lim‐
1083 its set by the RESOURCE LIMITS parameter of the queue configura‐
1084 tion as described in queue_conf(5). Unlike the resource limits
1085 in the queue configuration, these resource limits are set for
1086 every job on this execution host. If a value is not specified,
1087 the resource limit is inherited from the execution daemon
1088 process. Because this would lead to unpredicted results, if only
1089 one limit of a resource is set (soft or hard), the corresponding
1090 other limit is set to the same value.
1091 S_DESCRIPTORS and H_DESCRIPTORS specify a value one greater than
1092 the maximum file descriptor number that can be opened by any
1093 process of a job.
1094 S_MAXPROC and H_MAXPROC specify the maximum number of processes
1095 that can be created by the job user on this execution host
1096 S_MEMORYLOCKED and H_MEMORYLOCKED specify the maximum number of
1097 bytes of virtual memory that may be locked into RAM.
1098 S_LOCKS and H_LOCKS specify the maximum number of file locks any
1099 process of a job may establish.
1100 All of these values can be specified using the multiplier let‐
1101 ters k, K, m, M, g and G, see sge_types(1) for details.
1102 INHERIT_ENV
1104 This parameter indicates whether the shepherd should allow the
1105 environment inherited by the execution daemon from the shell
1106 that started it to be inherited by the job it's starting. When
1107 true, any environment variable that is set in the shell which
1108 starts the execution daemon at the time the execution daemon is
1109 started will be set in the environment of any jobs run by that
1110 execution daemon, unless the environment variable is explicitly
1111 overridden, such as PATH or LOGNAME. If set to false, each job
1112 starts with only the environment variables that are explicitly
1113 passed on by the execution daemon, such as PATH and LOGNAME.
1114 The default value is true.
1115 SET_LIB_PATH
1117 This parameter tells the execution daemon whether to add the
1118 Grid Engine shared library directory to the library path of exe‐
1119 cuted jobs. If set to true, and INHERIT_ENV is also set to
1120 true, the Grid Engine shared library directory will be prepended
1121 to the library path which is inherited from the shell which
1122 started the execution daemon. If INHERIT_ENV is set to false,
1123 the library path will contain only the Grid Engine shared
1124 library directory. If set to false, and INHERIT_ENV is set to
1125 true, the library path exported to the job will be the one
1126 inherited from the shell which started the execution daemon. If
1127 INHERIT_ENV is also set to false, the library path will be
1128 empty. After the execution daemon has set the library path, it
1129 may be further altered by the shell in which the job is exe‐
1130 cuted, or by the job script itself. The default value for
1131 SET_LIB_PATH is false.
1132 ENABLE_ADDGRP_KILL
1134 If this parameter is set then Grid Engine uses the supplementary
1135 group ids (see gid_range) to identify all processes which are to
1136 be terminated when a job is deleted, or when ge_shepherd(8)
1137 cleans up after job termination.
1138 PDC_INTERVAL
1140 This parameter defines the interval how often the PDC (Portable
1141 Data Collector) is executed by the execution daemon. The PDC is
1142 responsible for enforcing the resource limits s_cpu, h_cpu,
1143 s_vmem and h_vmem (see queue_conf(5)) and job usage collection.
1144 The parameter can be set to a time_specifier (see sge_types(5))
1145 , to PER_LOAD_REPORT or to NEVER.
1146 ENABLE_BINDING
1148 If this parameter is set then Grid Engine enables the core bind‐
1149 ing module within the execution daemon to apply binding parame‐
1150 ters that are specified during submission time of a job. This
1151 parameter is not set per default and therefore all binding
1152 related information will be ignored. Find more information for
1153 job to core binding in the section -binding of qsub(1).
1154 If this parameter is set to PER_LOAD_REPORT the PDC is triggered in the
1156 same interval as load_report_time (see above). If this parameter is set
1157 to NEVER the PDC run is never triggered. The default is 1 second.
1158 Note: A PDC run is quite compute extensive may degrade the performance
1159 of the running jobs. But if the PDC runs less often or never the online
1160 usage can be incomplete or totally missing (for example online usage of
1161 very short running jobs might be missing) and the resource limit
1162 enforcement is less accurate or would not happen if PDC is turned of
1163 completely.
1164 Changing execd_params will take effect after it was propagated to the
1166 execution daemons. The propagation is done in one load report interval.
1167 The default for execd_params is none.
1168 The global configuration entry for this value may be overwritten by the
1170 execution host local configuration.
1171 reporting_params
1173 Used to define the behavior of reporting modules in the Grid Engine
1174 qmaster. Changes to the reporting_params takes immediate effect. The
1175 following values are recognized:
1176 accounting
1178 If this parameter is set to true, the accounting file is writ‐
1179 ten. The accounting file is prerequisite for using the qacct
1180 command.
1181 reporting
1183 If this parameter is set to true, the reporting file is written.
1184 The reporting file contains data that can be used for monitoring
1185 and analysis, like job accounting, job log, host load and con‐
1186 sumables, queue status and consumables and sharetree configura‐
1187 tion and usage. Attention: Depending on the size and load of
1188 the cluster, the reporting file can become quite large. Only
1189 activate the reporting file if you have a process running that
1190 will consume the reporting file! See reporting(5) for further
1191 information about format and contents of the reporting file.
1192 flush_time
1194 Contents of the reporting file are buffered in the Grid Engine
1195 qmaster and flushed at a fixed interval. This interval can be
1196 configured with the flush_time parameter. It is specified as a
1197 time value in the format HH:MM:SS. Sensible values range from a
1198 few seconds to one minute. Setting it too low may slow down the
1199 qmaster. Setting it too high will make the qmaster consume large
1200 amounts of memory for buffering data.
1201 accounting_flush_time
1203 Contents of the accounting file are buffered in the Grid Engine
1204 qmaster and flushed at a fixed interval. This interval can be
1205 configured with the accounting_flush_time parameter. It is
1206 specified as a time value in the format HH:MM:SS. Sensible val‐
1207 ues range from a few seconds to one minute. Setting it too low
1208 may slow down the qmaster. Setting it too high will make the
1209 qmaster consume large amounts of memory for buffering data.
1210 Setting it to 00:00:00 will disable accounting data buffering;
1211 as soon as data is generated, it will be written to the account‐
1212 ing file. If this parameter is not set, the accounting data
1213 flush interval will default to the value of the flush_time
1214 parameter.
1215 joblog If this parameter is set to true, the reporting file will con‐
1217 tain job logging information. See reporting(5) for more informa‐
1218 tion about job logging.
1219 sharelog
1221 The Grid Engine qmaster can dump information about sharetree
1222 configuration and use to the reporting file. The parameter
1223 sharelog sets an interval in which sharetree information will be
1224 dumped. It is set in the format HH:MM:SS. A value of 00:00:00
1225 configures qmaster not to dump sharetree information. Intervals
1226 of several minutes up to hours are sensible values for this
1227 parameter. See reporting(5) for further information about
1228 sharelog.
1229 log_consumables
1231 This parameter controls writing of consumable resources to the
1232 reporting file. When set to (log_consumables=true) information
1233 about all consumable resources (their current usage and their
1234 capacity) will be written to the reporting file, whenever a con‐
1235 sumable resource changes either in definition, or in capacity,
1236 or when the usage of a consumable resource changes. When
1237 log_consumables is set to false (default), only those variables
1238 will be written to the reporting file, that are configured in
1239 the report_variables in the exec host configuration, see
1240 host_conf(5) for further information about report_variables.
1241 finished_jobs
1243 Note: Deprecated, may be removed in future release.
1244 Grid Engine stores a certain number of just finished jobs to provide
1245 post mortem status information. The finished_jobs parameter defines the
1246 number of finished jobs stored. If this maximum number is reached, the
1247 eldest finished job will be discarded for every new job added to the
1248 finished job list.
1249 Changing finished_jobs will take immediate effect. The default for
1251 finished_jobs is 100.
1252 This value is a global configuration parameter only. It cannot be over‐
1254 written by the execution host local configuration.
1255 qlogin_daemon
1257 This parameter specifies the mechanism that is to be started on the
1258 server side of a qlogin(1) request. Usually this is the builtin mecha‐
1259 nism. It's also possible to configure an external executable by speci‐
1260 fying the full qualified pathname, e.g. of the system's telnet daemon.
1261 Changing qlogin_daemon will take immediate effect. The default value
1263 for qlogin_daemon is builtin.
1264 The global configuration entry for this value may be overwritten by the
1266 execution host local configuration.
1267 Examples for the two allowed kinds of attributes are:
1269 qlogin_daemon builtin
1270 or
1271 qlogin_daemon /usr/sbin/in.telnetd
1272 qlogin_command
1274 This is the command to be executed on the client side of a qlogin(1)
1275 request. Usually this is the builtin qlogin mechanism. It's also pos‐
1276 sible to configure an external mechanism, usually the absolute pathname
1277 of the system's telnet client program. It is automatically started with
1278 the target host and port number as parameters.
1279 Changing qlogin_command will take immediate effect. The default value
1281 for qlogin_command is builtin.
1282 The global configuration entry for this value may be overwritten by the
1284 execution host local configuration.
1285 Examples for the two allowed kinds of attributes are:
1287 qlogin_command builtin
1288 or
1289 qlogin_command /usr/bin/telnetd
1290 rlogin_daemon
1292 This parameter specifies the mechanism that is to be started on the
1293 server side of a qrsh(1) request without a command argument to be exe‐
1294 cuted remotely. Usually this is the builtin mechanism. It's also pos‐
1295 sible to configure an external executable by specifying the absolute
1296 pathname, e.g. of the system's rlogin daemon.
1297 Changing rlogin_daemon will take immediate effect. The default for
1299 rlogin_daemon is builtin.
1300 The global configuration entry for this value may be overwritten by the
1302 execution host local configuration.
1303 The allowed values are similar to the ones of the examples of qlo‐
1305 gin_daemon.
1306 rlogin_command
1308 This is the mechanism to be executed on the client side of a qrsh(1)
1309 request without a command argument to be executed remotely. Usually
1310 this is the builtin mechanism. If no value is given, a specialized Grid
1311 Engine component is used. The command is automatically started with
1312 the target host and port number as parameters. The Grid Engine rlogin
1313 client has been extended to accept and use the port number argument.
1314 You can only use clients, such as ssh, which also understand this syn‐
1315 tax.
1316 Changing rlogin_command will take immediate effect. The default value
1318 for rlogin_command is builtin.
1319 The global configuration entry for this value may be overwritten by the
1321 execution host local configuration.
1322 In addition to the examples of qlogin_command , this value is allowed:
1324 rsh_daemon none
1325 rsh_daemon
1327 This parameter specifies the mechanism that is to be started on the
1328 server side of a qrsh(1) request with a command argument to be executed
1329 remotely. Usually this is the builtin mechanism. If no value is given,
1330 a specialized Grid Engine component is used.
1331 Changing rsh_daemon will take immediate effect. The default value for
1333 rsh_daemon is builtin.
1334 The global configuration entry for this value may be overwritten by the
1336 execution host local configuration.
1337 In addition to the examples of qlogin_daemon , this value is allowed:
1339 rsh_daemon none
1340 rsh_command
1342 This is the mechanism to be executed on the client side of a qrsh(1)
1343 request with a command argument to be executed remotely. Usually this
1344 is the builtin mechanism. If no value is given, a specialized Grid
1345 Engine component is used. The command is automatically started with the
1346 target host and port number as parameters like required for telnet(1)
1347 plus the command with its arguments to be executed remotely. The Grid
1348 Engine rsh client has been extended to accept and use the port number
1349 argument. You can only use clients, such as ssh, which also understand
1350 this syntax.
1351 Changing rsh_command will take immediate effect. The default value for
1353 rsh_command is builtin.
1354 The global configuration entry for this value may be overwritten by the
1356 execution host local configuration.
1357 In addition to the examples of qlogin_command , this value is allowed:
1359 rsh_command none
1360 delegated_file_staging
1362 This flag must be set to "true" when the prolog and epilog are ready
1363 for delegated file staging, so that the DRMAA attribute 'drmaa_trans‐
1364 fer_files' is supported. To establish delegated file staging, use the
1365 variables beginning with "$fs_..." in prolog and epilog to move the
1366 input, output and error files from one host to the other. When this
1367 flag is set to "false", no file staging is available for the DRMAA
1368 interface. File staging is currently implemented only via the DRMAA
1369 interface. When an error occurs while moving the input, output and
1370 error files, return error code 100 so that the error handling mechanism
1371 can handle the error correctly. (See also FORBID_APPERROR).
1372 reprioritize
1374 Note: Deprecated, may be removed in future release.
1375 This flag enables or disables the reprioritization of jobs based on
1376 their ticket amount. The reprioritize_interval in sched_conf(5) takes
1377 effect only if reprioritize is set to true. To turn off job reprioriti‐
1378 zation, the reprioritize flag must be set to false and the repriori‐
1379 tize_interval to 0 which is the default.
1380 This value is a global configuration parameter only. It cannot be over‐
1382 ridden by the execution host local configuration.
1383 jsv_url
1385 This setting defines a server JSV instance which will be started and
1386 triggered by the sge_qmaster(8) process. This JSV instance will be used
1387 to verify job specifications of jobs before they are accepted and
1388 stored in the internal master database. The global configuration entry
1389 for this value cannot be overwritten by execution host local configura‐
1390 tions.
1391 Find more details concerning JSV in jsv(1) and sge_request(1).
1393 The syntax of the jsv_url is specified in sge_types(1).
1395 jsv_allowed_mod
1397 If there is a server JSV script defined with jsv_url parameter, then
1398 all qalter(1) or qmon(1) modification requests for jobs are rejected by
1399 qmaster. With the jsv_allowed_mod parameter an administrator has the
1400 possibility to allow a set of switches which can then be used with
1401 clients to modify certain job attributes. The value for this parameter
1402 has to be a comma separated list of JSV job parameter names as they are
1403 documented in qsub(1) or the value none to indicate that no modifica‐
1404 tion should be allowed. Please note that even if none is specified the
1405 switches -w and -t are allowed for qalter.
1406 libjvm_path
1408 libjvm_path is usually set during qmaster installation and points to
1409 the absolute path of libjvm.so. (or the corresponding library depend‐
1410 ing on your architecture - e.g. /usr/java/jre/lib/i386/server/lib‐
1411 jvm.so) The referenced libjvm version must be at least 1.5. It is
1412 needed by the jvm qmaster thread only. If the java vm needs additional
1413 starting parameters they can be set in additional_jvm_args. If the jvm
1414 thread is started at all can be defined in the bootstrap(5) file. If
1415 libjvm_path is empty or an incorrect path the jvm thread fails to
1416 start.
1417 The global configuration entry for this value may be overwritten by the
1419 execution host local configuration.
1420 additional_jvm_args
1422 additional_jvm_args is usually set during qmaster installation.
1423 Details about possible values additional_jvm_args can be found in the
1424 help output of the accompanying java command. This setting is normally
1425 not needed.
1426 The global configuration entry for this value may be overwritten by the
1428 execution host local configuration.
1429
1431 ge_intro(1), csh(1), qconf(1), qsub(1), jsv(1), rsh(1), sh(1), getpw‐
1432 nam(3), drmaa_attributes(3), queue_conf(5), sched_conf(5),
1433 sge_types(1), ge_execd(8), ge_qmaster(8), ge_shepherd(8), cron(8), Grid
1434 Engine Installation and Administration Guide.
1435
1437 See ge_intro(1) for a full statement of rights and permissions.
1438GE 6.2u5 $Date: 2009/11/13 14:26:06 $ GE_CONF(5)