SGE_CONF(5)

NAME
sge_conf - Grid Engine Enterprise Edition configuration files

DESCRIPTION
sge_conf defines the global and local Grid Engine Enterprise Edition configurations and can be shown/modified by using the -sconf/-mconf options. Only root or the cluster administrator may modify sge_conf.

At its initial start-up, checks to see if a valid Grid Engine Enterprise Edition configuration is available at a well known location in the Grid Engine Enterprise Edition internal directory hierarchy. If so, it loads that configuration information and proceeds. If not, writes a generic configuration containing default values to that same location. The Grid Engine Enterprise Edition execution daemons upon start-up retrieve their configuration from

The actual configuration for both and is a superposition of a so called global configuration and a local configuration being pertinent for the host on which a master or execution daemon resides. If a local configuration is available, its entries overwrite the corresponding entries of the global configuration. Note: The local configuration does not have to contain all valid configuration entries, but only those which need to be modified against the global entries.

FORMAT
The paragraphs that follow provide brief descriptions of the individual parameters that compose the global and local configurations for a Grid Engine Enterprise Edition cluster:

qmaster_spool_dir
The location where the master spool directory resides. Only the and need to have access to this directory. It needs read/write permission for root, however. The master spool directory - in particular the jobs directory and the message log file - may become quite large depending on the size of the cluster and the number of jobs. Be sure to allocate enough disk space and regularly clean off the log files, e.g. via a job.

Being a parameter set at installation time changing qmaster_spool_dir in a running system is not supported.

The default location for the master spool directory is <sge_root>/<cell>/spool/qmaster.

This value is a global configuration parameter only. It cannot be overwritten by the execution host local configuration.

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 parameter can be overwritten by execution host local configurations, i.e. each 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 possible 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, however).

Being a parameter set at installation time changing the global execd_spool_dir in a running system is not supported.

The default location for the execution daemon spool directory is <sge_root>/<cell>/spool.

The global configuration entry for this value may be overwritten by the execution host local configuration.

binary_path
The directory path where the Grid Engine Enterprise Edition binaries reside. It is used within Grid Engine Enterprise Edition components to locate and startup other Grid Engine Enterprise Edition programs.

The path name given here is searched for binaries as well as any directory below with a directory name equal to the current operating system architecture. Therefore, /usr/SGE/bin will work for all architectures, if the corresponding binaries are located in subdirectories named aix43, cray, glinux, hp10, irix6, osf4, solaris, etc.

Each may have its private binary path. Changing the binary path will have immediate effect for

The default location for the binary path is <sge_root>/bin

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 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 Grid Engine Enterprise Edition 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 terminal emulator,

Each 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 and to be used in order to retrieve site configurable load information (e.g. free space on a certain disk partition).

Each may use a set of private load_sensor programs or scripts. Changing load_sensor will take effect after two load report intervalls (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, searches for an executable file named qloadsensor in the execution host's Grid Engine Enterprise Edition binary directory path. If such a file is found, it is treated like the configurable 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 Grid Engine Enterprise Edition jobs with the same environment setting as that for the Grid Engine Enterprise Edition 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 Grid Engine Enterprise Edition administrator to automate the execution of general site specific tasks like the preparation of temporary file systems with the need for the same context information as the job. Each may use a private prologue script. Correspondingly, the execution host local configurations is can be overwritten by the queue configuration (see ). Changing prolog will take immediate effect.

Note: prolog is executed exactly as the job script. Therefore, all implications described under the parameters shell_start_mode and login_shells below apply.

The default for prolog is the special value NONE, which prevents from execution of a prologue script.

The following special variables being 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 procedures are started.

$job_owner
    The user name of the job owner.

$job_id
    Grid Engine Enterprise Edition's unique job identification number.

$job_name
    The name of the job.

$processors
    The processors string as contained in the queue configuration (see of the master queue (the queue in which the prolog and epilog procedures are started).

$queue
    The master queue, i.e. the queue in which the prolog and epilog procedures are started.

The global configuration entry for this value may be overwritten by the execution host local configuration.

epilog
The executable path of a shell script that is started after execution of Grid Engine Enterprise Edition jobs with the same environment setting as that for the Grid Engine Enterprise Edition 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 Grid Engine Enterprise Edition administrator to automate the execution 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 may use a private epilogue script. Correspondingly, the execution host local configurations is can be overwritten by the queue configuration (see ). Changing epilog will take immediate effect.

Note: epilog is executed exactly as the job script. Therefore, all implications described under the parameters shell_start_mode and login_shells below apply.

The default for epilog is the special value NONE, which prevents from execution of a epilogue script. The same special 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.

shell_start_mode
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 interactively by invoking it just with the script name the operating system's executable loader uses the information 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 Grid Engine Enterprise Edition 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 being 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 interpreters instead. Thus, if shell_start_mode is set to posix_compliant Grid Engine Enterprise Edition will either use the command interpreter indicated by the -S option of the command or the shell parameter of the queue to be used (see 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 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 execute jobs.
    If this violates your site's security policies you may want to set shell_start_mode to script_from_stdin. This will force Grid Engine Enterprise Edition to open the job script as well as the epilogue and prologue scripts for reading into STDIN as root (if 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 command or the shell parameter of the queue to be used (see 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 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 cannot be overwritten by the execution host local configuration.

login_shells
UNIX command interpreters like the Bourne-Shell (see or the C-Shell (see can be used by Grid Engine Enterprise Edition 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 Grid Engine Enterprise Edition - see The parameter login_shells contains a comma separated list of the executable names of the command interpreters 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,csh,tcsh,ksh.

This value is a global configuration parameter only. It cannot be overwritten by the execution host local configuration.

min_uid
min_uid places a lower bound on user IDs that may use the cluster. Users whose user ID (as returned by 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 cannot be overwritten by the execution host local configuration.

min_gid
This parameter sets the lower bound on group IDs that may use the cluster. Users whose default group ID (as returned by 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 cannot be overwritten by the execution host local configuration.

user_lists
The user_lists parameter contains a comma separated list of so called user access lists as described in 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 being 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 cannot be overwritten by the execution host local configuration.

xuser_lists
The xuser_lists parameter contains a comma separated list of so called user access lists as described in 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 cannot be overwritten by the execution host local configuration.

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 configuration 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 cannot be overwritten by the execution host local configuration.

projects
This parameter is only available for Grid Engine Enterprise Edition systems. It is not present in Grid Engine.

The projects list contains all projects which are granted access to Grid Engine Enterprise Edition. User belonging to none of these projects cannot use Grid Engine Enterprise Edition. If users belong to projects 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 cannot be overwritten by the execution host local configuration.

xprojects
This parameter is only available for Grid Engine Enterprise Edition systems. It is not present in Grid Engine.

The xprojects list contains all projects which are granted access to Grid Engine Enterprise Edition. User belonging to one of these projects cannot use Grid Engine Enterprise Edition. If users belong to projects 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 cannot be overwritten by the execution host local configuration.

load_report_time
System load is reported periodically by the execution daemons to The parameter load_report_time defines the time interval between load reports.

Each 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 especially if the number of execution hosts is large. Moreover, since the system load typically increases and decreases smoothly, frequent 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 cannot establish contact to the 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 may not be executing on such hosts.

In any case, Grid Engine Enterprise Edition can reschedule jobs running on such hosts to another system. reschedule_unknown controls the time which Grid Engine Enterprise Edition 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 and the rerun option of Parallel jobs are only rescheduled if the host on which their master task executes is in unknown state. Checkpointing jobs will only be rescheduled when the when option of the corresponding checkpointing environment containes an appropriate flag. (see Interactive jobs (see are not rescheduled.

The default for reschedule_unknown id 00:00:00

The global configuration entry for this value may be over written by the execution host local configuration.

stat_log_time
Grid Engine Enterprise Edition periodically logs a snapshot of the status of the queues currently configured in the cluster to disk. The time interval in seconds between consecutive snapshots is defined by stat_log_time.

Changing stat_log_time takes immediate effect. The default for stat_log_time is 2 hours 30 minutes.

This value is a global configuration parameter only. It cannot be overwritten by the execution host local configuration.

max_unheard
If 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. 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 2 minutes 30 seconds.

This value is a global configuration parameter only. It cannot be overwritten by the execution host local configuration.

loglevel
This parameter specifies the level of detail that Grid Engine Enterprise Edition components such as or 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 qmaster_spool_dir and 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_info.

This value is a global configuration parameter only. It cannot be overwritten by the execution host local configuration.

max_aj_instances
This parameter defines the maximum amount of array tasks to be scheduled to run simultaneously per array job. An instance of an array task will be created within the master daemeon 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 daemon. 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 cannot be overwritten by the execution host local configuration.

max_aj_tasks
This parameter defines the maximum number of array job tasks within an array job. 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 cannot be overwritten by the execution host local configuration.

max_u_jobs
The number of active (not finished) jobs which each Grid Engine Enterprise Edition user can have in the system simultaneously is controlled 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 cannot be overwritten by the execution host local configuration.

enforce_project
This parameter is only available for Grid Engine Enterprise Edition systems. It is not present in Grid Engine.

If set to true, users are required to request a project whenever submitting a job. See the -P option to 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 cannot be overwritten by the execution host local configuration.

enforce_user
This parameter is only available for Grid Engine Enterprise Edition systems. It is not present in Grid Engine.

If set to true, a Grid Engine Enterprise Edition must exists to allow for job submission. Jobs are rejected if no corresponding user exists.

Changing enforce_user will take immediate effect. The default for enforce_user is false.

This value is a global configuration parameter only. It cannot be overwritten by the execution host local configuration.

set_token_cmd
This parameter is only present if your Grid Engine Enterprise Edition system is licensed to support AFS.

Set_token_cmd points to a command which sets and extends AFS tokens for Grid Engine Enterprise Edition jobs. In the standard Grid Engine Enterprise Edition 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 self written daemon at the AFS server. The token must be forged at the AFS server and returned to the local machine, where SetToken is executed.

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
This parameter is only present if your Grid Engine Enterprise Edition system is licensed to support AFS.

The path to your pagsh is specified via this parameter. The 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
This parameter is only present if your Grid Engine Enterprise Edition system is licensed to support AFS.

the time period for which AFS tokens are periodically extended. Grid Engine Enterprise Edition 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.

gid_range
The gid_range is a comma separated list of range expressions of the form n-m (n as well as m being integer numbers greater than 99), where m is an abbreviation for m-m. These numbers are used in to identify processes belonging to the same job.

Each 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 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 Grid Engine Enterprise Edition.

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 Grid Engine Enterprise Edition qmaster. The following values are recognized:

ENABLE_FORCED_QDEL
    If this parameter is set, non-administrative users can foce deletion of their own jobs via the -f option of Without this parameter, forced deletion of jobs is only allowed by the Grid Engine Enterprise Edition manager or operator.

    Note: Forced deletion for jobs is executed differently depending on whether users are Grid Engine Enterprise Edition administrators or not. In case of administrative users, the jobs are removed from the internal database of Grid Engine Enterprise Edition immediately. For regular users, the equivalent of a normal is executed first, and deletion is forced only if the normal cancellation was unsuccessful.

    Changing qmaster_params will take immediate effect. The default for qmaster_params is none.

    This value is a global configuration parameter only. It cannot be overwritten by the execution host local configuration.

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.

DISABLE_AUTO_RESCHEDULING
    If set to "true" or "1", the reschedule_unknown parameter is not taken into account.

Changing qmaster_params will take immediate effect. The default for qmaster_params is none.

This value is a global configuration parameter only. It cannot be overwritten by the execution host local configuration.

schedd_params
This is foreseen for passing additional parameters to the Grid Engine Enterprise Edition scheduler. The following values are recognized currently:

FLUSH_SUBMIT_SEC, FLUSH_FINISH_SEC
    The parameters are provided for tuning the system's scheduling behavior. By default, a scheduler run is triggered in the scheduler interval which is defined in the scheduler configuration parameter schedule_interval.
    The parameters FLUSH_SUBMIT_SEC/FLUSH_FINISH_SEC define the time gaps between triggering a scheduler run and the submitting/finishing of a job.
    The most immediate scheduler reaction can be activated by setting both values to 0. The default scheduling behavior is enforced by either removing the parameters or setting them to a value of -1.

CLASSIC_SGEEE_SCHEDULING
    If set to "true" or "1", use the original SGEEE pending job scheduling algorithm. The original SGEEE pending job scheduling algorithm calculates the tickets for pending jobs by dividing up the tickets in each scheduling policy among all the active and pending jobs. The pending job list is then ordered based on the tickets assigned to the pending jobs. The default value is "false". This parameter is only valid in a SGEEE system.

POLICY_HIERARCHY
    This parameter sets up a dependency chain of policies. Each policy in the dependency chain is influenced by the previous policies and influences the following policies. A typical scenario is to assign precedence for the override policy over the share-based policy. The override policy determines in such a case how share-based tickets are assigned among jobs of the same user or project. Note that all policies contribute to the ticket amount assigned to a particular job regardless of the policy hierarchy definition. Yet the tickets calculated in each of the policies can be differend depending on "POLICY_HIERARCHY".

    The "POLICY_HIERARCHY" parameter can be a up to 4 letter combination of the first letters of the 4 policies S(hare-based), F(unctional), D(eadline) and O(verride). So a value "OFSD" means that the override policy takes precedence over the functional policy, which influences the share-based policy and which finaly preceeds the deadline policy. Less than 4 letters mean that some of the policies do not influence other policies and also are not influenced by other policies. So a value of "FS" means that the functional policy influences the share-based policy and that there is no interference with the other policies.

    The special value "NONE" switches off policy hierarchies.

SHARE_OVERRIDE_TICKETS
    If set to "true" or "1", override tickets of any override object instance are shared equally among all jobs associated with the object. If set to "false" or "0", each job gets the full value of the override tickets associated with the object. The default value is "true". This parameter is only valid in a SGEEE system.

SHARE_FUNCTIONAL_SHARES
    If set to "true" or "1", functional shares of any functional object instance are shared among all the jobs associated with the object. If set to "false" or "0", each job associated with a functional object, gets the full functional shares of that object. The default value is "true". This parameter is only valid in a SGEEE system.

SHARE_DEADLINE_TICKETS
    If set to "true" or "1", the total deadline tickets are shared among all deadline jobs. If set to "false" or "0", each deadline job will receive the total deadline tickets once the job deadline has been reached. The default value is "true". This parameter is only valid in a SGEEE system.

MAX_FUNCTIONAL_JOBS_TO_SCHEDULE
    The maximum number of pending jobs to schedule in the functional policy. The default value is 200. This parameter is only valid in a SGEEE system.

MAX_PENDING_TASKS_PER_JOB
    The maximum number of subtasks per pending array job to schedule. This parameter exists in order to reduce scheduling overhead. The default value is 50. This parameter is only valid in a SGEEE system.

PROFILE
    If set, the scheduler logs profiling information summarizing each scheduling run.

Changing schedd_params will take immediate effect. The default for schedd_params is none.

This value is a global configuration parameter only. It cannot be overwritten by the execution host local configuration.

execd_params
This is foreseen for passing additional parameters to the Grid Engine Enterprise Edition execution daemon. The following values are recognized:

ACCT_RESERVED_USAGE
    If this parameter is set to true, for reserved usage is used for the accounting entries cpu, mem and io instead of the measured usage.

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 for a job.

NO_REPRIORITIZATION
    If set to "true" or "1", jobs are not reprioritized dynamically. Without setting this attribute the priority parameter in has no durable effect in a SGEEE system because of dynamic reprioritization performed by the PTF module inside

PTF_MIN_PRIORITY, PTF_MAX_PRIORITY
    The parameters are only available in a Grid Engine Enterprise Edition system.
    The maximum/minumum priority which Grid Engine Enterprise Edition will assign to a job. Typically this is a negative/postive value in the range of -20 (maximum) to 19 (minimum) for systems which allow setting of priorties with the system call. Other systems may provide different ranges.
    The default priority range (varies from system to system) 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.

NOTIFY_KILL
    The parameter allows you to change the notification signal for the signal SIGKILL (see -notify option of The parameter either accepts signal names (use the -l option of 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 notification signal.

NOTIFY_SUSP
    With this parameter it is possible to modify the notification signal for the signal SIGSTOP (see -notify parameter of The parameter either accepts signal names (use the -l option of or the special 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.

SET_SGE_ENV, SET_COD_ENV, SET_GRD_ENV
    In qsub(1) you can find a list of environment variables which are exported into the execution environment of each Grid Engine Enterprise Edition job. Some of these variables names begin with the prefix "SGE_". In the predecessor products of Grid Engine Enterprise Edition (Codine, GRD) the prefixes "COD_" and "GRD_" were used for those variables. This makes it necessary to update all job scripts relying one of those environment variables. The parameters SET_SGE_ENV, SET_COD_ENV and SET_GRD_ENV can be used to accomplish a smoother transition from Codine/GRD to Grid Engine Enterprise Edition. Each of those parameters makes sure that a set of environment variables mentioned in qsub(1) and beginning with the corresponding prefix will be exported into the job environmnet. Every parameter can be set to "true", "1" or "false", "0". Defaults are "SET_SGE_ENV=1, SET_COD_ENV=0 and SET_GRD_ENV=0". If all three parameters are set to "false" or "0" jobs might fail as none of the corresponding environment variables would be set. Therefore in this case the environment variables beginning with the prefix "SGE_" are set.

SHARETREE_RESERVED_USAGE
    If this parameter is set to true, reserved usage is taken for the Grid Engine Enterprise Edition share tree consumption instead of measured usage.

Changing execd_params will take immediate effect. The default for execd_params is none.

The global configuration entry for this value may be overwritten by the execution host local configuration.

USE_QSUB_GID
    If this parameter is set to true, the primary group id being active when a job was submitted will be set to become the primary group id for job execution. If the parameter is not set, the primary group id as defined for the job owner in the execution host file is used.
    The feature is only available for jobs submitted via and Also, it only works for jobs (and thus also for and if rsh and rshd components are used which are provided with Grid Engine Enterprise Edition (i.e., the rsh_daemon and rsh_command parameters may not be changed from the default).

admin_user
Administrative user account used by Grid Engine Enterprise Edition for all internal file handling (status spooling, message logging, etc.). Can be used in cases where the root account does not have the corresponding file access permissions (e.g. on a shared file system without global root read/write access).

Being a parameter set at installation time changing admin_user in a running system is not supported. Changing it manually on a shut-down cluster is possible, but if access to the Grid Engine Enterprise Edition spooling area is interrupted, this will result in unpredictable behaviour. The admin_user parameter has no default value, but instead it is defined during the master installation procedure.

This value is a global configuration parameter only. It cannot be overwritten by the execution host local configuration.

finished_jobs
Grid Engine Enterprise Edition stores a certain number of just finished jobs to provide post mortem status information. The finished_jobs parameter defines the number of finshed jobs being stored. If this maximum number is reached, the eldest finshed job will be discarded for every now job being added to the finshed job list.

Changing finished_jobs will take immediate effect. The default for finished_jobs is 0.

This value is a global configuration parameter only. It cannot be overwritten by the execution host local configuration.

qlogin_daemon
This parameter specifies the executable that is to be started on the server side of a request. Usually this is the fully qualified pathname of the system's telnet daemon. If no value is given, a specialized Grid Engine Enterprise Edition component is used.

Changing qlogin_daemon will take immediate effect. The default for qlogin_daemon is none.

The global configuration entry for this value may be overwritten by the execution host local configuration.

qlogin_command
This is the command to be executed on the client side of a request. Usually this is the fully qualified pathname of the systems's telnet client program. If no value is given, a specialized Grid Engine Enterprise Edition component is used. It is automatically started with the target host and port number as parameters.

Changing qlogin_command will take immediate effect. The default for qlogin_command is none.

The global configuration entry for this value may be overwritten by the execution host local configuration.

rlogin_daemon
This parameter specifies the executable that is to be started on the server side of a request without a command argument to be executed remotely. Usually this is the fully qualified pathname of the system's rlogin daemon. If no value is given, a specialized Grid Engine Enterprise Edition component is used.

Changing rlogin_daemon will take immediate effect. The default for rlogin_daemon is none.

The global configuration entry for this value may be overwritten by the execution host local configuration.

rlogin_command
This is the command to be executed on the client side of a request without a command argument to be executed remotely. Usually this is the fully qualified pathname of the system's rlogin client program. If no value is given, a specialized Grid Engine Enterprise Edition component is used. The command is automatically started with the target host and port number as parameters like required for The Grid Engine Enterprise Edition rlogin client has been extened 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 for rlogin_command is none.

The global configuration entry for this value may be overwritten by the execution host local configuration.

rsh_daemon
This parameter specifies the executable that is to be started on the server side of a request with a command argument to be executed remotely. Usually this is the fully qualified pathname of the system's rsh daemon. If no value is given, a specialized Grid Engine Enterprise Edition component is used.

Changing rsh_daemon will take immediate effect. The default for rsh_daemon is none.

The global configuration entry for this value may be overwritten by the execution host local configuration.

rsh_command
This is the command to be executed on the client side of a request with a command argument to be executed remotely. Usually this is the fully qualified pathname of the system's rsh client program. If no value is given, a specialized Grid Engine Enterprise Edition component is used. The command is automatically started with the target host and port number as parameters like required for plus the command with its arguments to be executed remotely. The Grid Engine Enterprise Edition rsh client has been extened 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 for rsh_command is none.

The global configuration entry for this value may be overwritten by the execution host local configuration.

ignore_fqdn
Ignore fully qualified domain name component of hostnames. Should be set if all hosts belonging to a Grid Engine Enterprise Edition cluster are part of a single DNS domain. It is switched on if set to either "true" or "1". Switching it on may solve problems with load reports due to different hostname resolutions across the cluster.

Being a parameter set at installation time changing ignore_fqdn in a running system is not supported. The default for ignore_fqdn is "true".

This value is a global configuration parameter only. It cannot be overwritten by the execution host local configuration.

default_domain
Only needed if your Grid Engine Enterprise Edition cluster covers hosts belonging to more than a single DNS domain. In this case it can be used if your hostname resolving yields both qualified and unqualified hostnames for the hosts in one of the DNS domains. The value of default_domain is appended to the unqualified hostname to define a fully qualified hostname. The default_domain parameter will have no effect if ignore_fqdn is set to "true".

Being a parameter set at installation time changing default_domain in a running system is not supported. The default for default_domain is "none", in which case it will not be used.

This value is a global configuration parameter only. It cannot be overwritten by the execution host local configuration.

SEE ALSO
Grid Engine Enterprise Edition Installation and Administration Guide.

COPYRIGHT
See for a full statement of rights and permissions.