NAME
sge_conf - Sun Grid Engine configuration files
DESCRIPTION
sge_conf defines the global and local Sun Grid Engine confi-
gurations and can be shown/modified by qconf(1) using the
-sconf/-mconf options. Only root or the cluster administra-
tor may modify sge_conf.
At its initial start-up, sge_qmaster(8) checks to see if a
valid Sun Grid Engine configuration is available at a well
known location in the Sun Grid Engine internal directory
hierarchy. If so, it loads that configuration information
and proceeds. If not, sge_qmaster(8) writes a generic con-
figuration containing default values to that same location.
The Sun Grid Engine execution daemons sge_execd(8) upon
start-up retrieve their configuration from sge_qmaster(8).
The actual configuration for both sge_qmaster(8) and
sge_execd(8) is a superposition of a global configuration
and a local configuration pertinent for the host on which a
master or execution daemon resides. If a local configura-
tion is available, its entries overwrite the corresponding
entries of the global configuration. Note: The local confi-
guration does not have to contain all valid configuration
entries, but only those which need to be modified against
the global entries.
Note: Sun Grid Engine allows backslashes (\) be used to
escape newline (\newline) characters. The backslash and the
newline are replaced with a space (" ") character before any
interpretation.
FORMAT
The paragraphs that follow provide brief descriptions of the
individual parameters that compose the global and local con-
figurations for a Sun Grid Engine cluster:
execd_spool_dir
The execution daemon spool directory path. Again, a feasible
spool directory requires read/write access permission for
root. The entry in the global configuration for this parame-
ter can be overwritten by execution host local configura-
tions, i.e. each sge_execd(8) may have a private spool
directory with a different path, in which case it needs to
provide read/write permission for the root account of the
corresponding execution host only.
Under execd_spool_dir a directory named corresponding to the
unqualified hostname of the execution host is opened and
contains all information spooled to disk. Thus, it is possi-
ble for the execd_spool_dirs of all execution hosts to
physically reference the same directory path (the root
access restrictions mentioned above need to be met, how-
ever).
Changing the global execd_spool_dir parameter set at instal-
lation time is not supported in a running system. If the
change should still be done it is required to restart all
affected execution daemons. Please make sure running jobs
have finished before doing so, otherwise running jobs will
be lost.
The default location for the execution daemon spool direc-
tory is $SGE_ROOT/$SGE_CELL/spool.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
mailer
mailer is the absolute pathname to the electronic mail
delivery agent on your system. It must accept the following
syntax:
mailer -s <subject-of-mail-message> <recipient>
Each sge_execd(8) may use a private mail agent. Changing
mailer will take immediate effect.
The default for mailer depends on the operating system of
the host on which the Sun Grid Engine master installation
was run. Common values are /bin/mail or /usr/bin/Mail.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
xterm
xterm is the absolute pathname to the X Window System termi-
nal emulator, xterm(1).
Each sge_execd(8) may use a private mail agent. Changing
xterm will take immediate effect.
The default for xterm is /usr/bin/X11/xterm.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
load_sensor
A comma separated list of executable shell script paths or
programs to be started by sge_execd(8) and to be used in
order to retrieve site configurable load information (e.g.
free space on a certain disk partition).
Each sge_execd(8) may use a set of private load_sensor pro-
grams or scripts. Changing load_sensor will take effect
after two load report intervals (see load_report_time). A
load sensor will be restarted automatically if the file
modification time of the load sensor executable changes.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
In addition to the load sensors configured via load_sensor,
sge_exec(8) searches for an executable file named qloadsen-
sor in the execution host's Sun Grid Engine binary directory
path. If such a file is found, it is treated like the con-
figurable load sensors defined in load_sensor. This facility
is intended for pre-installing a default load sensor.
prolog
The executable path of a shell script that is started before
execution of Sun Grid Engine jobs with the same environment
setting as that for the Sun Grid Engine jobs to be started
afterwards. An optional prefix "user@" specifies the user
under which this procedure is to be started. The procedures
standard output and the error output stream are written to
the same file used also for the standard output and error
output of each job. This procedure is intended as a means
for the Sun Grid Engine administrator to automate the execu-
tion of general site specific tasks like the preparation of
temporary file systems with the need for the same context
information as the job. Each sge_execd(8) may use a private
prolog script. Correspondingly, the execution host local
configurations is can be overwritten by the queue configura-
tion (see queue_conf(5) ). Changing prolog will take immedi-
ate effect.
The default for prolog is the special value NONE, which
prevents from execution of a prolog script.
The following special variables expanded at runtime can be
used (besides any other strings which have to be interpreted
by the procedure) to constitute a command line:
$host
The name of the host on which the prolog or epilog pro-
cedures are started.
$job_owner
The user name of the job owner.
$job_id
Sun Grid Engine's unique job identification number.
$job_name
The name of the job.
$processors
The processors string as contained in the queue confi-
guration (see queue_conf(5)) of the master queue (the
queue in which the prolog and epilog procedures are
started).
$queue
The cluster queue name of the master queue instance,
i.e. the cluster queue in which the prolog and epilog
procedures are started.
$stdin_path
The pathname of the stdin file. This is always
/dev/null for prolog, pe_start, pe_stop and epilog. It
is the pathname of the stdin file for the job in the
job script. When delegated file staging is enabled,
this path is set to $fs_stdin_tmp_path. When delegated
file staging is not enabled, it is the stdin pathname
given via DRMAA or qsub.
$stdout_path
$stderr_path
The pathname of the stdout/stderr file. This always
points to the output/error file. When delegated file
staging is enabled, this path is set to
$fs_stdout_tmp_path/$fs_stderr_tmp_path. When delegated
file staging is not enabled, it is the stdout/stderr
pathname given via DRMAA or qsub.
$merge_stderr
If merging of stderr and stdout is requested, this flag
is "1", otherwise it is "0". If this flag is 1, stdout
and stderr are merged in one file, the stdout file.
Merging of stderr and stdout can be requested via the
DRMAA job template attribute 'drmaa_join_files' (see
drmaa_attributes(3) ) or the qsub parameter '-j y' (see
qsub(1) ).
$fs_stdin_host
When delegated file staging is requested for the stdin
file, this is the name of the host where the stdin file
has to be copied from before the job is started.
$fs_stdout_host
$fs_stderr_host
When delegated file staging is requested for the
stdout/stderr file, this is the name of the host where
the stdout/stderr file has to be copied to after the
job has run.
$fs_stdin_path
When delegated file staging is requested for the stdin
file, this is the pathname of the stdin file on the
host $fs_stdin_host.
$fs_stdout_path
$fs_stderr_path
When delegated file staging is requested for the
stdout/stderr file, this is the pathname of the
stdout/stderr file on the host
$fs_stdout_host/$fs_stderr_host.
$fs_stdin_tmp_path
When delegated file staging is requested for the stdin
file, this is the destination pathname of the stdin
file on the execution host. The prolog script must copy
the stdin file from $fs_stdin_host:$fs_stdin_path to
localhost:$fs_stdin_tmp_path to establish delegated
file staging of the stdin file.
$fs_stdout_tmp_path
$fs_stderr_tmp_path
When delegated file staging is requested for the
stdout/stderr file, this is the source pathname of the
stdout/stderr file on the execution host. The epilog
script must copy the stdout file from
localhost:$fs_stdout_tmp_path to
$fs_stdout_host:$fs_stdout_path (the stderr file from
localhost:$fs_stderr_tmp_path to
$fs_stderr_host:$fs_stderr_path) to establish delegated
file staging of the stdout/stderr file.
$fs_stdin_file_staging
$fs_stdout_file_staging
$fs_stderr_file_staging
When delegated file staging is requested for the
stdin/stdout/stderr file, the flag is set to "1", oth-
erwise it is set to "0" (see in delegated_file_staging
how to enable delegated file staging).
These three flags correspond to the DRMAA job template
attribute 'drmaa_transfer_files' (see
drmaa_attributes(3) ).
The global configuration entry for this value may be
overwritten by the execution host local configuration.
Exit codes for the prolog attribute can be interpreted based
on the following exit values:
0: Success
99: Reschedule job
100: Put job in error state
Anything else: Put queue in error state
epilog
The executable path of a shell script that is started after
execution of Sun Grid Engine jobs with the same environment
setting as that for the Sun Grid Engine jobs that has just
completed. An optional prefix "user@" specifies the user
under which this procedure is to be started. The procedures
standard output and the error output stream are written to
the same file used also for the standard output and error
output of each job. This procedure is intended as a means
for the Sun Grid Engine administrator to automate the execu-
tion of general site specific tasks like the cleaning up of
temporary file systems with the need for the same context
information as the job. Each sge_execd(8) may use a private
epilog script. Correspondingly, the execution host local
configurations is can be overwritten by the queue configura-
tion (see queue_conf(5) ). Changing epilog will take
immediate effect.
The default for epilog is the special value NONE, which
prevents from execution of a epilog script. The same spe-
cial variables as for prolog can be used to constitute a
command line.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
Exit codes for the epilog attribute can be interpreted based
on the following exit values:
0: Success
99: Reschedule job
100: Put job in error state
Anything else: Put queue in error state
shell_start_mode
Note: Deprecated, may be removed in future release.
This parameter defines the mechanisms which are used to
actually invoke the job scripts on the execution hosts. The
following values are recognized:
unix_behavior
If a user starts a job shell script under UNIX interac-
tively by invoking it just with the script name the
operating system's executable loader uses the informa-
tion provided in a comment such as `#!/bin/csh' in the
first line of the script to detect which command
interpreter to start to interpret the script. This
mechanism is used by Sun Grid Engine when starting jobs
if unix_behavior is defined as shell_start_mode.
posix_compliant
POSIX does not consider first script line comments such
a `#!/bin/csh' as significant. The POSIX standard for
batch queuing systems (P1003.2d) therefore requires a
compliant queuing system to ignore such lines but to
use user specified or configured default command inter-
preters instead. Thus, if shell_start_mode is set to
posix_compliant Sun Grid Engine will either use the
command interpreter indicated by the -S option of the
qsub(1) command or the shell parameter of the queue to
be used (see queue_conf(5) for details).
script_from_stdin
Setting the shell_start_mode parameter either to
posix_compliant or unix_behavior requires you to set
the umask in use for sge_execd(8) such that every user
has read access to the active_jobs directory in the
spool directory of the corresponding execution daemon.
In case you have prolog and epilog scripts configured,
they also need to be readable by any user who may exe-
cute jobs.
If this violates your site's security policies you may
want to set shell_start_mode to script_from_stdin. This
will force Sun Grid Engine to open the job script as
well as the epilog and prolog scripts for reading into
STDIN as root (if sge_execd(8) was started as root)
before changing to the job owner's user account. The
script is then fed into the STDIN stream of the command
interpreter indicated by the -S option of the qsub(1)
command or the shell parameter of the queue to be used
(see queue_conf(5) for details).
Thus setting shell_start_mode to script_from_stdin also
implies posix_compliant behavior. Note, however, that
feeding scripts into the STDIN stream of a command
interpreter may cause trouble if commands like rsh(1)
are invoked inside a job script as they also process
the STDIN stream of the command interpreter. These
problems can usually be resolved by redirecting the
STDIN channel of those commands to come from /dev/null
(e.g. rsh host date < /dev/null). Note also, that any
command-line options associated with the job are passed
to the executing shell. The shell will only forward
them to the job if they are not recognized as valid
shell options.
Changes to shell_start_mode will take immediate effect. The
default for shell_start_mode is posix_compliant.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
login_shells
UNIX command interpreters like the Bourne-Shell (see sh(1))
or the C-Shell (see csh(1)) can be used by Sun Grid Engine
to start job scripts. The command interpreters can either be
started as login-shells (i.e. all system and user default
resource files like .login or .profile will be executed when
the command interpreter is started and the environment for
the job will be set up as if the user has just logged in) or
just for command execution (i.e. only shell specific
resource files like .cshrc will be executed and a minimal
default environment is set up by Sun Grid Engine - see
qsub(1)). The parameter login_shells contains a comma
separated list of the executable names of the command inter-
preters to be started as login-shells. Shells in this list
are only started as login shells if the parameter
shell_start_mode (see above) is set to posix_compliant.
Changes to login_shells will take immediate effect. The
default for login_shells is sh,bash,csh,tcsh,ksh.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
min_uid
min_uid places a lower bound on user IDs that may use the
cluster. Users whose user ID (as returned by getpwnam(3)) is
less than min_uid will not be allowed to run jobs on the
cluster.
Changes to min_uid will take immediate effect. The default
for min_uid is 0.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
min_gid
This parameter sets the lower bound on group IDs that may
use the cluster. Users whose default group ID (as returned
by getpwnam(3)) is less than min_gid will not be allowed to
run jobs on the cluster.
Changes to min_gid will take immediate effect. The default
for min_gid is 0.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local
configuration.
user_lists
The user_lists parameter contains a comma separated list of
user access lists as described in access_list(5). Each user
contained in at least one of the enlisted access lists has
access to the cluster. If the user_lists parameter is set to
NONE (the default) any user has access not explicitly
excluded via the xuser_lists parameter described below. If
a user is contained both in an access list enlisted in
xuser_lists and user_lists the user is denied access to the
cluster.
Changes to user_lists will take immediate effect
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
xuser_lists
The xuser_lists parameter contains a comma separated list of
user access lists as described in access_list(5). Each user
contained in at least one of the enlisted access lists is
denied access to the cluster. If the xuser_lists parameter
is set to NONE (the default) any user has access. If a user
is contained both in an access list enlisted in xuser_lists
and user_lists (see above) the user is denied access to the
cluster.
Changes to xuser_lists will take immediate effect
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
administrator_mail
administrator_mail specifies a comma separated list of the
electronic mail address(es) of the cluster administrator(s)
to whom internally-generated problem reports are sent. The
mail address format depends on your electronic mail system
and how it is configured; consult your system's configura-
tion guide for more information.
Changing administrator_mail takes immediate effect. The
default for administrator_mail is an empty mail list.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
projects
The projects list contains all projects which are granted
access to Sun Grid Engine. User belonging to none of these
projects cannot use Sun Grid Engine. If users belong to pro-
jects in the projects list and the xprojects list (see
below), they also cannot use the system.
Changing projects takes immediate effect. The default for
projects is none.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
xprojects
The xprojects list contains all projects that are denied
access to Sun Grid Engine. User belonging to one of these
projects cannot use Sun Grid Engine. If users belong to pro-
jects in the projects list (see above) and the xprojects
list, they also cannot use the system.
Changing xprojects takes immediate effect. The default for
xprojects is none.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
load_report_time
System load is reported periodically by the execution dae-
mons to sge_qmaster(8). The parameter load_report_time
defines the time interval between load reports.
Each sge_execd(8) may use a different load report time.
Changing load_report_time will take immediate effect.
Note: Be careful when modifying load_report_time. Reporting
load too frequently might block sge_qmaster(8) especially if
the number of execution hosts is large. Moreover, since the
system load typically increases and decreases smoothly, fre-
quent load reports hardly offer any benefit.
The default for load_report_time is 40 seconds.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
reschedule_unknown
Determines whether jobs on hosts in unknown state are
rescheduled and thus sent to other hosts. Hosts are
registered as unknown if sge_master(8) cannot establish con-
tact to the sge_execd(8) on those hosts (see max_unheard ).
Likely reasons are a breakdown of the host or a breakdown of
the network connection in between, but also sge_execd(8) may
not be executing on such hosts.
In any case, Sun Grid Engine can reschedule jobs running on
such hosts to another system. reschedule_unknown controls
the time which Sun Grid Engine will wait before jobs are
rescheduled after a host became unknown. The time format
specification is hh:mm:ss. If the special value 00:00:00 is
set, then jobs will not be rescheduled from this host.
Rescheduling is only initiated for jobs which have activated
the rerun flag (see the -r y option of qsub(1) and the rerun
option of queue_conf(5)). Parallel jobs are only
rescheduled if the host on which their master task executes
is in unknown state. The behavior of reschedule_unknown for
parallel jobs and for jobs without the rerun flag be set can
be adjusted using the qmaster_params settings
ENABLE_RESCHEDULE_KILL and ENABLE_RESCHEDULE_SLAVE.
Checkpointing jobs will only be rescheduled when the when
option of the corresponding checkpointing environment con-
tains an appropriate flag. (see checkpoint(5)). Interactive
jobs (see qsh(1), qrsh(1), qtcsh(1)) are not rescheduled.
The default for reschedule_unknown is 00:00:00
The global configuration entry for this value may be over
written by the execution host local configuration.
max_unheard
If sge_qmaster(8) could not contact or was not contacted by
the execution daemon of a host for max_unheard seconds, all
queues residing on that particular host are set to status
unknown. sge_qmaster(8), at least, should be contacted by
the execution daemons in order to get the load reports.
Thus, max_unheard should by greater than the
load_report_time (see above).
Changing max_unheard takes immediate effect. The default
for max_unheard is 5 minutes.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
loglevel
This parameter specifies the level of detail that Sun Grid
Engine components such as sge_qmaster(8) or sge_execd(8) use
to produce informative, warning or error messages which are
logged to the messages files in the master and execution
daemon spool directories (see the description of the
execd_spool_dir parameter above). The following message
levels are available:
log_err
All error events being recognized are logged.
log_warning
All error events being recognized and all detected
signs of potentially erroneous behavior are logged.
log_info
All error events being recognized, all detected signs
of potentially erroneous behavior and a variety of
informative messages are logged.
Changing loglevel will take immediate effect.
The default for loglevel is log_warning.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
max_aj_instances
This parameter defines the maximum amount of array task to
be scheduled to run simultaneously per array job. An
instance of an array task will be created within the master
daemon when it gets a start order from the scheduler. The
instance will be destroyed when the array task finishes.
Thus the parameter provides control mainly over the memory
consumption of array jobs in the master and scheduler dae-
mon. It is most useful for very large clusters and very
large array jobs. The default for this parameter is 2000.
The value 0 will deactivate this limit and will allow the
scheduler to start as many array job tasks as suitable
resources are available in the cluster.
Changing max_aj_instances will take immediate effect.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
max_aj_tasks
This parameter defines the maximum number of array job tasks
within an array job. sge_qmaster(8) will reject all array
job submissions which request more than max_aj_tasks array
job tasks. The default for this parameter is 75000. The
value 0 will deactivate this limit.
Changing max_aj_tasks will take immediate effect.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
max_u_jobs
The number of active (not finished) jobs which each Sun Grid
Engine user can have in the system simultaneously is con-
trolled by this parameter. A value greater than 0 defines
the limit. The default value 0 means "unlimited". If the
max_u_jobs limit is exceeded by a job submission then the
submission command exits with exit status 25 and an
appropriate error message.
Changing max_u_jobs will take immediate effect.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
max_jobs
The number of active (not finished) jobs simultaneously
allowed in Sun Grid Engine is controlled by this parameter.
A value greater than 0 defines the limit. The default value
0 means "unlimited". If the max_jobs limit is exceeded by a
job submission then the submission command exits with exit
status 25 and an appropriate error message.
Changing max_jobs will take immediate effect.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
max_advance_reservations
The number of active (not finished) Advance Reservations
simultaneously allowed in Sun Grid Engine is controlled by
this parameter. A value greater than 0 defines the limit.
The default value 0 means "unlimited". If the
max_advance_reservations limit is exceeded by an Advance
Reservation request then the submission command exits with
exit status 25 and an appropriate error message.
Changing max_advance_reservations will take immediate
effect.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
enforce_project
If set to true, users are required to request a project
whenever submitting a job. See the -P option to qsub(1) for
details.
Changing enforce_project will take immediate effect. The
default for enforce_project is false.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
enforce_user
If set to true, a user(5) must exist to allow for job sub-
mission. Jobs are rejected if no corresponding user exists.
If set to auto, a user(5) object for the submitting user
will automatically be created during job submission, if one
does not already exist. The auto_user_oticket,
auto_user_fshare, auto_user_default_project, and
auto_user_delete_time configuration parameters will be used
as default attributes of the new user(5) object.
Changing enforce_user will take immediate effect. The
default for enforce_user is auto.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
auto_user_oticket
The number of override tickets to assign to automatically
created user(5) objects. User objects are created automati-
cally if the enforce_user attribute is set to auto.
Changing auto_user_oticket will affect any newly created
user objects, but will not change user objects created in
the past.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
auto_user_fshare
The number of functional shares to assign to automatically
created user(5) objects. User objects are created automati-
cally if the enforce_user attribute is set to auto.
Changing auto_user_fshare will affect any newly created user
objects, but will not change user objects created in the
past.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
auto_user_default_project
The default project to assign to automatically created
user(5) objects. User objects are created automatically if
the enforce_user attribute is set to auto.
Changing auto_user_default_project will affect any newly
created user objects, but will not change user objects
created in the past.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
auto_user_delete_time
The number of seconds of inactivity after which automati-
cally created user(5) objects will be deleted. User objects
are created automatically if the enforce_user attribute is
set to auto. If the user has no active or pending jobs for
the specified amount of time, the object will automatically
be deleted. A value of 0 can be used to indicate that the
automatically created user object is permanent and should
not be automatically deleted.
Changing auto_user_delete_time will affect the deletion time
for all users with active jobs.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
set_token_cmd
Note: Deprecated, may be removed in future release.
This parameter is only present if your Sun Grid Engine sys-
tem is licensed to support AFS.
Set_token_cmd points to a command which sets and extends AFS
tokens for Sun Grid Engine jobs. In the standard Sun Grid
Engine AFS distribution, it is supplied as a script which
expects two command line parameters. It reads the token from
STDIN, extends the token's expiration time and sets the
token:
<set_token_cmd> <user> <token_extend_after_seconds>
As a shell script this command will call the programs:
- SetToken
- forge
which are provided by your distributor as source code. The
script looks as follows:
--------------------------------
#!/bin/sh
# set_token_cmd
forge -u $1 -t $2 | SetToken
--------------------------------
Since it is necessary for forge to read the secret AFS
server key, a site might wish to replace the set_token_cmd
script by a command, which connects to a custom daemon at
the AFS server. The token must be forged at the AFS server
and returned to the local machine, where SetToken is exe-
cuted.
Changing set_token_cmd will take immediate effect. The
default for set_token_cmd is none.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
pag_cmd
Note: Deprecated, may be removed in future release.
This parameter is only present if your Sun Grid Engine sys-
tem is licensed to support AFS.
The path to your pagsh is specified via this parameter. The
sge_shepherd(8) process and the job run in a pagsh. Please
ask your AFS administrator for details.
Changing pag_cmd will take immediate effect. The default
for pag_cmd is none.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
token_extend_time
Note: Deprecated, may be removed in future release.
This parameter is only present if your Sun Grid Engine sys-
tem is licensed to support AFS.
The token_extend_time is the time period for which AFS
tokens are periodically extended. Sun Grid Engine will call
the token extension 30 minutes before the tokens expire
until jobs have finished and the corresponding tokens are no
longer required.
Changing token_extend_time will take immediate effect. The
default for token_extend_time is 24:0:0, i.e. 24 hours.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
shepherd_cmd
Alternative path to the shepherd_cmd binary. Typically used
to call the shepherd binary by a wrapper script or command.
Changing shepherd_cmd will take immediate effect. The
default for shepherd_cmd is none.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
gid_range
The gid_range is a comma separated list of range expressions
of the form n-m (n as well as m are integer numbers greater
than 99), where m is an abbreviation for m-m. These numbers
are used in sge_execd(8) to identify processes belonging to
the same job.
Each sge_execd(8) may use a separate set up group ids for
this purpose. All number in the group id range have to be
unused supplementary group ids on the system, where the
sge_execd(8) is started.
Changing gid_range will take immediate effect. There is no
default for gid_range. The administrator will have to assign
a value for gid_range during installation of Sun Grid
Engine.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
qmaster_params
A list of additional parameters can be passed to the Sun
Grid Engine qmaster. The following values are recognized:
ENABLE_ENFORCE_MASTER_LIMIT
If this parameter is set then the s_rt, h_rt limit of a
running job are tested and executed by the
sge_qmaster(8) when the sge_execd(8) where the job is
in unknown state.
After s_rt or h_rt limit of a job is expired then the
master daemon will wait additional time defined by
DURATION_OFFSET (see sched_conf(5)). If the execution
daemon still cannot be contacted when this additional
time is elapsed, then the master daemon will force the
deletion of the job (see -f of qdel(1)).
For jobs which will be deleted that way an accounting
record will be created. As usage the record will con-
tain the last reported online usage, when the execution
daemon could contact qmaster. The failed state in the
record will be set to 37 to indicate that the job was
terminated by a limit enforcement of master daemon.
After the restart of sge_qmaster(8) the limit enforce-
ment will at first be triggered after the double of the
biggest load_report_interval interval defined in
sge_conf(5) has been elapsed. This will give the execu-
tion daemons enough time to reregister at master dae-
mon.
ENABLE_FORCED_QDEL_IF_UNKNOWN
If this parameter is set then a deletion request for a
job is automatically interpreted as a forced deletion
request (see -f of qdel(1)) if the host, where the job
is running is in unknown state.
ENABLE_FORCED_QDEL
If this parameter is set, non-administrative users can
force deletion of their own jobs via the -f option of
qdel(1). Without this parameter, forced deletion of
jobs is only allowed by the Sun Grid Engine manager or
operator.
Note: Forced deletion for jobs is executed differently
depending on whether users are Sun Grid Engine adminis-
trators or not. In case of administrative users, the
jobs are removed from the internal database of Sun Grid
Engine immediately. For regular users, the equivalent
of a normal qdel(1) is executed first, and deletion is
forced only if the normal cancellation was unsuccess-
ful.
FORBID_RESCHEDULE
If this parameter is set, re-queuing of jobs cannot be
initiated by the job script which is under control of
the user. Without this parameter jobs returning the
value 99 are rescheduled. This can be used to cause the
job to be restarted at a different machine, for
instance if there are not enough resources on the
current one.
FORBID_APPERROR
If this parameter is set, the application cannot set
itself to error state. Without this parameter jobs
returning the value 100 are set to error state (and
therefore can be manually rescheduled by clearing the
error state). This can be used to set the job to error
state when a starting condition of the application is
not fulfilled before the application itself has been
started, or when a clean up procedure (e.g. in the epi-
log) decides that it is necessary to run the job again,
by returning 100 in the prolog, pe_start, job script,
pe_stop or epilog script.
DISABLE_AUTO_RESCHEDULING
Note: Deprecated, may be removed in future release.
If set to "true" or "1", the reschedule_unknown parame-
ter is not taken into account.
ENABLE_RESCHEDULE_KILL
If set to "true" or "1", the reschedule_unknown parame-
ter affects also jobs which have the rerun flag not
activated (see the -r y option of qsub(1) and the rerun
option of queue_conf(5)), but they are just finished as
they can't be rescheduled.
ENABLE_RESCHEDULE_SLAVE
If set to "true" or "1" Sun Grid Engine triggers job
rescheduling also when the host where the slave tasks
of a parallel job executes is in unknown state, if the
reschedule_unknown parameter is activated.
MAX_DYN_EC
Sets the max number of dynamic event clients (as used
by qsub -sync y and by Sun Grid Engine DRMAA API
library sessions). The default is set to 99. The number
of dynamic event clients should not be bigger than half
of the number of file descriptors the system has. The
number of file descriptors are shared among the connec-
tions to all exec hosts, all event clients, and file
handles that the qmaster needs.
MONITOR_TIME
Specifies the time interval when the monitoring infor-
mation should be printed. The monitoring is disabled by
default and can be enabled by specifying an interval.
The monitoring is per thread and is written to the mes-
sages file or displayed by the "qping -f" command line
tool. Example: MONITOR_TIME=0:0:10 generates and prints
the monitoring information approximately every 10
seconds. The specified time is a guideline only and not
a fixed interval. The interval that is actually used is
printed. In this example, the interval could be any-
thing between 9 seconds and 20 seconds.
LOG_MONITOR_MESSAGE
Monitoring information is logged into the messages
files by default. This information can be accessed via
by qping(1). If monitoring is always enabled, the mes-
sages files can become quite large. This switch dis-
ables logging into the messages files, making qping -f
the only source of monitoring data.
PROF_SIGNAL
Profiling provides the user with the possibility to get
system measurements. This can be useful for debugging
or optimization of the system. The profiling output
will be done within the messages file.
Enables the profiling for qmaster signal thread. (e.g.
PROF_SIGNAL=true)
PROF_WORKER
Enables the profiling for qmaster worker threads.
(e.g. PROF_WORKER=true)
PROF_LISTENER
Enables the profiling for qmaster listener threads.
(e.g. PROF_LISTENER=true)
PROF_DELIVER
Enables the profiling for qmaster event deliver thread.
(e.g. PROF_DELIVER=true)
PROF_TEVENT
Enables the profiling for qmaster timed event thread.
(e.g. PROF_TEVENT=true)
Please note, that the cpu utime and stime values contained
in the profiling output are not per thread cpu times. These
cpu usage statistics are per process statistics. So the
printed profiling values for cpu mean "cpu time consumed by
sge_qmaster (all threads) while the reported profiling level
was active".
STREE_SPOOL_INTERVAL
Sets the time interval for spooling the sharetree
usage. The default is set to 00:04:00. The setting
accepts colon-separated string or seconds. There is no
setting to turn the sharetree spooling off. (e.g.
STREE_SPOOL_INTERVAL=00:02:00)
MAX_JOB_DELETION_TIME
Sets the value of how long the qmaster will spend
deleting jobs. After this time, the qmaster will con-
tinue with other tasks and schedule the deletion of
remaining jobs at a later time. The default value is 3
seconds, and will be used if no value is entered. The
range of valid values is > 0 and <= 5. (e.g.
MAX_JOB_DELETION_TIME=1)
gdi_timeout
Sets how long the communication will wait for gdi
send/receive operations. The default value is set to
60 seconds. After this time, the communication library
will retry, if "gdi_retries" is configured, receiving
the gdi request. In case of not configured
"gdi_retries" the communication will return with a "gdi
receive failure" (e.g. gdi_timeout=120 will set the
timeout time to 120 sec) Configuring no gdi_timeout
value, the value defaults to 60 sec.
gdi_retries
Sets how often the gdi receive call will be repeated
until the gdi receive error appears. The default is set
to 0. In this case the call will be done 1 time with no
retry. Setting the value to -1 the call will be done
permanently. In combination with gdi_timeout parameter
it is possible to configure a system with eg. slow NFS,
to make sure that all jobs will be submitted. (e.g.
gdi_retries=4)
cl_ping
Turns on/off a communication library ping. This parame-
ter will create additional debug output. This output
shows information about the error messages which are
returned by communication and it will give information
about the application status of the qmaster. eg, if
it's unclear what's the reason for gdi timeouts, this
may show you some useful messages. The default value is
false (off) (e.g cl_ping=false)
SCHEDULER_TIMEOUT
Setting this parameter allows the scheduler GDI event
acknowledge timeout to be manually configured to a
specific value. Currently the default value is 10
minutes with the default scheduler configuration and
limited between 600 and 1200 seconds. Value is limited
only in case of default value. The default value
depends on the current scheduler configuration. The
SCHEDULER_TIMEOUT value is specified in seconds.
jsv_timeout
This parameter measures the response time of the server
JSV. In the event that the response time of the JSV is
longer than the timeout value specified, this will
cause the JSV to be re-started. The default value for
the timeout is 10 seconds and if modified, must be
greater than 0. If the timeout has been reach, the JSV
will only try to re-start once, if the timeout is
reached again an error will occur.
jsv_threshold
The threshold of a JSV is measured as the time it takes
to perform a server job verification. If this value is
greater than the user defined value, it will cause log-
ging to appear in the qmaster messages file at the INFO
level. By setting this value to 0, all jobs will be
logged in the qmaster messages file. This value is
specified in milliseconds and has a default value of
5000.
Changing qmaster_params will take immediate effect, except
gdi_timeout, gdi_retries, cl_ping, these will take effect
only for new connections. The default for qmaster_params is
none.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
execd_params
This is used for passing additional parameters to the Sun
Grid Engine execution daemon. The following values are
recognized:
ACCT_RESERVED_USAGE
If this parameter is set to true, the usage of
reserved resources is used for the accounting entries
cpu, mem and io instead of the measured usage.
ENABLE_WINDOMACC
If this parameter is set to true, Windows Domain
accounts (WinDomAcc) are used on Windows hosts. These
accounts require the use of sgepasswd(1) (see also
sgepasswd(5)). If this parameter is set to false or is
not set, local Windows accounts are used. On non-
Windows hosts, this parameter is ignored.
KEEP_ACTIVE
This value should only be set for debugging purposes.
If set to true, the execution daemon will not remove
the spool directory maintained by sge_shepherd(8) for a
job.
PTF_MIN_PRIORITY, PTF_MAX_PRIORITY
The maximum/minimum priority which Sun Grid Engine will
assign to a job. Typically this is a negative/positive
value in the range of -20 (maximum) to 19 (minimum) for
systems which allow setting of priorities with the
nice(2) system call. Other systems may provide dif-
ferent ranges.
The default priority range (varies from system to sys-
tem) is installed either by removing the parameters or
by setting a value of -999.
See the "messages" file of the execution daemon for the
predefined default value on your hosts. The values are
logged during the startup of the execution daemon.
PROF_EXECD
Enables the profiling for the execution daemon. (e.g.
PROF_EXECD=true)
NOTIFY_KILL
The parameter allows you to change the notification
signal for the signal SIGKILL (see -notify option of
qsub(1)). The parameter either accepts signal names
(use the -l option of kill(1)) or the special value
none. If set to none, no notification signal will be
sent. If it is set to TERM, for instance, or another
signal name then this signal will be sent as notifica-
tion signal.
NOTIFY_SUSP
With this parameter it is possible to modify the notif-
ication signal for the signal SIGSTOP (see -notify
parameter of qsub(1)). The parameter either accepts
signal names (use the -l option of kill(1)) or the spe-
cial value none. If set to none, no notification signal
will be sent. If it is set to TSTP, for instance, or
another signal name then this signal will be sent as
notification signal.
SHARETREE_RESERVED_USAGE
Note: Deprecated, may be removed in future release.
If this parameter is set to true, the usage of reserved
resources is taken for the Sun Grid Engine share tree
consumption instead of measured usage.
Note: When running tightly integrated jobs with
SHARETREE_RESERVED_USAGE set, and with having
accounting_summary enabled in the parallel environment,
reserved usage will only be reported by the master task
of the parallel job. No per parallel task usage
records will be sent from execd to qmaster, which can
significantly reduce load on qmaster when running large
tightly integrated parallel jobs.
USE_QSUB_GID
If this parameter is set to true, the primary group id
active when a job was submitted will be set to become
the primary group id for job execution. If the parame-
ter is not set, the primary group id as defined for the
job owner in the execution host passwd(5) file is used.
The feature is only available for jobs submitted via
qsub(1), qrsh(1), qmake(1) and qtcsh(1). Also, it only
works for qrsh(1) jobs (and thus also for qtcsh(1) and
qmake(1)) if rsh and rshd components are used which are
provided with Sun Grid Engine (i.e., the rsh_daemon and
rsh_command parameters may not be changed from the
default).
S_DESCRIPTORS, H_DESCRIPTORS, S_MAXPROC, H_MAXPROC,
S_MEMORYLOCKED, H_MEMORYLOCKED, S_LOCKS, H_LOCKS
Specifies soft and hard resource limits as implemented
by the setrlimit(2) system call. See this manual page
on your system for more information. These parameters
complete the list of limits set by the RESOURCE LIMITS
parameter of the queue configuration as described in
queue_conf(5). Unlike the resource limits in the queue
configuration, these resource limits are set for every
job on this execution host. If a value is not speci-
fied, the resource limit is inherited from the execu-
tion daemon process. Because this would lead to
unpredicted results, if only one limit of a resource is
set (soft or hard), the corresponding other limit is
set to the same value.
S_DESCRIPTORS and H_DESCRIPTORS specify a value one
greater than the maximum file descriptor number that
can be opened by any process of a job.
S_MAXPROC and H_MAXPROC specify the maximum number of
processes that can be created by the job user on this
execution host
S_MEMORYLOCKED and H_MEMORYLOCKED specify the maximum
number of bytes of virtual memory that may be locked
into RAM.
S_LOCKS and H_LOCKS specify the maximum number of file
locks any process of a job may establish.
All of these values can be specified using the multi-
plier letters k, K, m, M, g and G, see sge_types(1) for
details.
INHERIT_ENV
This parameter indicates whether the shepherd should
allow the environment inherited by the execution daemon
from the shell that started it to be inherited by the
job it's starting. When true, any environment variable
that is set in the shell which starts the execution
daemon at the time the execution daemon is started will
be set in the environment of any jobs run by that exe-
cution daemon, unless the environment variable is
explicitly overridden, such as PATH or LOGNAME. If set
to false, each job starts with only the environment
variables that are explicitly passed on by the execu-
tion daemon, such as PATH and LOGNAME. The default
value is true.
SET_LIB_PATH
This parameter tells the execution daemon whether to
add the Sun Grid Engine shared library directory to the
library path of executed jobs. If set to true, and
INHERIT_ENV is also set to true, the Sun Grid Engine
shared library directory will be prepended to the
library path which is inherited from the shell which
started the execution daemon. If INHERIT_ENV is set to
false, the library path will contain only the Sun Grid
Engine shared library directory. If set to false, and
INHERIT_ENV is set to true, the library path exported
to the job will be the one inherited from the shell
which started the execution daemon. If INHERIT_ENV is
also set to false, the library path will be empty.
After the execution daemon has set the library path, it
may be further altered by the shell in which the job is
executed, or by the job script itself. The default
value for SET_LIB_PATH is false.
ENABLE_ADDGRP_KILL
If this parameter is set then Sun Grid Engine uses the
supplementary group ids (see gid_range) to identify all
processes which are to be terminated when a job is
deleted, or when sge_shepherd(8) cleans up after job
termination.
PDC_INTERVAL
This parameter defines the interval how often the PDC
(Portable Data Collector) is executed by the execution
daemon. The PDC is responsible for enforcing the
resource limits s_cpu, h_cpu, s_vmem and h_vmem (see
queue_conf(5)) and job usage collection. The parameter
can be set to a time_specifier (see sge_types(5)) , to
PER_LOAD_REPORT or to NEVER.
ENABLE_BINDING
If this parameter is set then Sun Grid Engine enables
the core binding module within the execution daemon to
apply binding parameters that are specified during sub-
mission time of a job. This parameter is not set per
default and therefore all binding related information
will be ignored. Find more information for job to core
binding in the section -binding of qsub(1).
If this parameter is set to PER_LOAD_REPORT the PDC is trig-
gered in the same interval as load_report_time (see above).
If this parameter is set to NEVER the PDC run is never trig-
gered. The default is 1 second.
Note: A PDC run is quite compute extensive may degrade the
performance of the running jobs. But if the PDC runs less
often or never the online usage can be incomplete or totally
missing (for example online usage of very short running jobs
might be missing) and the resource limit enforcement is less
accurate or would not happen if PDC is turned of completely.
Changing execd_params will take effect after it was pro-
pagated to the execution daemons. The propagation is done in
one load report interval. The default for execd_params is
none.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
reporting_params
Used to define the behavior of reporting modules in the Sun
Grid Engine qmaster. Changes to the reporting_params takes
immediate effect. The following values are recognized:
accounting
If this parameter is set to true, the accounting file
is written. The accounting file is prerequisite for
using the qacct command.
reporting
If this parameter is set to true, the reporting file is
written. The reporting file contains data that can be
used for monitoring and analysis, like job accounting,
job log, host load and consumables, queue status and
consumables and sharetree configuration and usage.
Attention: Depending on the size and load of the clus-
ter, the reporting file can become quite large. Only
activate the reporting file if you have a process run-
ning that will consume the reporting file! See report-
ing(5) for further information about format and con-
tents of the reporting file.
flush_time
Contents of the reporting file are buffered in the Sun
Grid Engine qmaster and flushed at a fixed interval.
This interval can be configured with the flush_time
parameter. It is specified as a time value in the for-
mat HH:MM:SS. Sensible values range from a few seconds
to one minute. Setting it too low may slow down the
qmaster. Setting it too high will make the qmaster con-
sume large amounts of memory for buffering data.
accounting_flush_time
Contents of the accounting file are buffered in the Sun
Grid Engine qmaster and flushed at a fixed interval.
This interval can be configured with the
accounting_flush_time parameter. It is specified as a
time value in the format HH:MM:SS. Sensible values
range from a few seconds to one minute. Setting it too
low may slow down the qmaster. Setting it too high will
make the qmaster consume large amounts of memory for
buffering data. Setting it to 00:00:00 will disable
accounting data buffering; as soon as data is gen-
erated, it will be written to the accounting file. If
this parameter is not set, the accounting data flush
interval will default to the value of the flush_time
parameter.
joblog
If this parameter is set to true, the reporting file
will contain job logging information. See reporting(5)
for more information about job logging.
sharelog
The Sun Grid Engine qmaster can dump information about
sharetree configuration and use to the reporting file.
The parameter sharelog sets an interval in which share-
tree information will be dumped. It is set in the for-
mat HH:MM:SS. A value of 00:00:00 configures qmaster
not to dump sharetree information. Intervals of several
minutes up to hours are sensible values for this param-
eter. See reporting(5) for further information about
sharelog.
log_consumables
This parameter controls writing of consumable resources
to the reporting file. When set to
(log_consumables=true) information about all consumable
resources (their current usage and their capacity) will
be written to the reporting file, whenever a consumable
resource changes either in definition, or in capacity,
or when the usage of a consumable resource changes.
When log_consumables is set to false (default), only
those variables will be written to the reporting file,
that are configured in the report_variables in the exec
host configuration, see host_conf(5) for further infor-
mation about report_variables.
finished_jobs
Note: Deprecated, may be removed in future release.
Sun Grid Engine stores a certain number of just finished
jobs to provide post mortem status information. The
finished_jobs parameter defines the number of finished jobs
stored. If this maximum number is reached, the eldest fin-
ished job will be discarded for every new job added to the
finished job list.
Changing finished_jobs will take immediate effect. The
default for finished_jobs is 100.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
qlogin_daemon
This parameter specifies the mechanism that is to be started
on the server side of a qlogin(1) request. Usually this is
the builtin mechanism. It's also possible to configure an
external executable by specifying the full qualified path-
name, e.g. of the system's telnet daemon.
Changing qlogin_daemon will take immediate effect. The
default value for qlogin_daemon is builtin.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
Examples for the two allowed kinds of attributes are:
qlogin_daemon builtin
or
qlogin_daemon /usr/sbin/in.telnetd
qlogin_command
This is the command to be executed on the client side of a
qlogin(1) request. Usually this is the builtin qlogin
mechanism. It's also possible to configure an external
mechanism, usually the absolute pathname of the system's
telnet client program. It is automatically started with the
target host and port number as parameters.
Changing qlogin_command will take immediate effect. The
default value for qlogin_command is builtin.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
Examples for the two allowed kinds of attributes are:
qlogin_command builtin
or
qlogin_command /usr/bin/telnetd
rlogin_daemon
This parameter specifies the mechanism that is to be started
on the server side of a qrsh(1) request without a command
argument to be executed remotely. Usually this is the buil-
tin mechanism. It's also possible to configure an external
executable by specifying the absolute pathname, e.g. of the
system's rlogin daemon.
Changing rlogin_daemon will take immediate effect. The
default for rlogin_daemon is builtin.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
The allowed values are similar to the ones of the examples
of qlogin_daemon.
rlogin_command
This is the mechanism to be executed on the client side of a
qrsh(1) request without a command argument to be executed
remotely. Usually this is the builtin mechanism. If no
value is given, a specialized Sun Grid Engine component is
used. The command is automatically started with the target
host and port number as parameters. The Sun Grid Engine
rlogin client has been extended to accept and use the port
number argument. You can only use clients, such as ssh,
which also understand this syntax.
Changing rlogin_command will take immediate effect. The
default value for rlogin_command is builtin.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
In addition to the examples of qlogin_command , this value
is allowed:
rsh_daemon none
rsh_daemon
This parameter specifies the mechanism that is to be started
on the server side of a qrsh(1) request with a command argu-
ment to be executed remotely. Usually this is the builtin
mechanism. If no value is given, a specialized Sun Grid
Engine component is used.
Changing rsh_daemon will take immediate effect. The default
value for rsh_daemon is builtin.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
In addition to the examples of qlogin_daemon , this value is
allowed:
rsh_daemon none
rsh_command
This is the mechanism to be executed on the client side of a
qrsh(1) request with a command argument to be executed
remotely. Usually this is the builtin mechanism. If no
value is given, a specialized Sun Grid Engine component is
used. The command is automatically started with the target
host and port number as parameters like required for tel-
net(1) plus the command with its arguments to be executed
remotely. The Sun Grid Engine rsh client has been extended
to accept and use the port number argument. You can only use
clients, such as ssh, which also understand this syntax.
Changing rsh_command will take immediate effect. The default
value for rsh_command is builtin.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
In addition to the examples of qlogin_command , this value
is allowed:
rsh_command none
delegated_file_staging
This flag must be set to "true" when the prolog and epilog
are ready for delegated file staging, so that the DRMAA
attribute 'drmaa_transfer_files' is supported. To establish
delegated file staging, use the variables beginning with
"$fs_..." in prolog and epilog to move the input, output and
error files from one host to the other. When this flag is
set to "false", no file staging is available for the DRMAA
interface. File staging is currently implemented only via
the DRMAA interface. When an error occurs while moving the
input, output and error files, return error code 100 so that
the error handling mechanism can handle the error correctly.
(See also FORBID_APPERROR).
reprioritize
Note: Deprecated, may be removed in future release.
This flag enables or disables the reprioritization of jobs
based on their ticket amount. The reprioritize_interval in
sched_conf(5) takes effect only if reprioritize is set to
true. To turn off job reprioritization, the reprioritize
flag must be set to false and the reprioritize_interval to 0
which is the default.
This value is a global configuration parameter only. It can-
not be overridden by the execution host local configuration.
jsv_url
This setting defines a server JSV instance which will be
started and triggered by the sge_qmaster(8) process. This
JSV instance will be used to verify job specifications of
jobs before they are accepted and stored in the internal
master database. The global configuration entry for this
value cannot be overwritten by execution host local confi-
gurations.
Find more details concerning JSV in jsv(1) and
sge_request(1).
The syntax of the jsv_url is specified in sge_types(1).
jsv_allowed_mod
If there is a server JSV script defined with jsv_url parame-
ter, then all qalter(1) or qmon(1) modification requests for
jobs are rejected by qmaster. With the jsv_allowed_mod
parameter an administrator has the possibility to allow a
set of switches which can then be used with clients to
modify certain job attributes. The value for this parameter
has to be a comma separated list of JSV job parameter names
as they are documented in qsub(1) or the value none to indi-
cate that no modification should be allowed. Please note
that even if none is specified the switches -w and -t are
allowed for qalter.
libjvm_path
libjvm_path is usually set during qmaster installation and
points to the absolute path of libjvm.so. (or the
corresponding library depending on your architecture - e.g.
/usr/java/jre/lib/i386/server/libjvm.so) The referenced
libjvm version must be at least 1.5. It is needed by the
jvm qmaster thread only. If the java vm needs additional
starting parameters they can be set in additional_jvm_args.
If the jvm thread is started at all can be defined in the
bootstrap(5) file. If libjvm_path is empty or an incorrect
path the jvm thread fails to start.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
additional_jvm_args
additional_jvm_args is usually set during qmaster installa-
tion. Details about possible values additional_jvm_args can
be found in the help output of the accompanying java com-
mand. This setting is normally not needed.
The global configuration entry for this value may be
overwritten by the execution host local configuration.
SEE ALSO
sge_intro(1), csh(1), qconf(1), qsub(1), jsv(1), rsh(1),
sh(1), getpwnam(3), drmaa_attributes(3), queue_conf(5),
sched_conf(5), sge_types(1), sge_execd(8), sge_qmaster(8),
sge_shepherd(8), cron(8), Sun Grid Engine Installation and
Administration
COPYRIGHT
See sge_intro(1) for a full statement of rights and permis-
sions.
Man(1) output converted with
man2html