NAME
sge_conf - Grid Engine configuration files
DESCRIPTION
sge_conf defines the global and local Grid Engine configura-
tions 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 Grid Engine configuration is available at a well known
location in the Grid Engine internal directory hierarchy.
If so, it loads that configuration information and proceeds.
If not, sge_qmaster(8) writes a generic configuration con-
taining default values to that same location. The 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 so called global confi-
guration 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 con-
figuration 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 con-
figurations for a Grid Engine cluster:
qmaster_spool_dir
The location where the master spool directory resides. Only
the sge_qmaster(8) needs 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 allo-
cate enough disk space and regularly clean off the log
files, e.g. via a cron(8) job.
Changing the master spool directory will have an effect
after restarting sge_qmaster(8) only.
The default location for the master spool directory is
<sge_root>/<cell>/spool/qmaster.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
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 phy-
sically reference the same directory path (the root access
restrictions mentioned above need to be met, however).
Changing the execution daemon spool directory will have an
effect after restarting sge_execd(8) only.
The default location for the execution daemon spool direc-
tory 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 binaries reside. It
is used within Grid Engine components to locate and startup
other Grid Engine 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 sge_execd(8) may have its private binary path. Chang-
ing the binary path will have immediate effect for
sge_execd(8).
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 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 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 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,
sge_exec(8) searches for an executable file named qloadsen-
sor in the execution host's 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 Grid Engine jobs with the same environment set-
ting as that for the Grid Engine jobs to be started after-
wards. An optional prefix "user@" specifies the user under
which this procedure is to be started. This procedure is
intended as a means for the Grid Engine 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 sge_execd(8)
may use a private prologue script. Correspondingly, the exe-
cution host local configurations is can be overwritten by
the queue configuration (see queue_conf(5) ). Changing pro-
log will take immediate effect.
Note: prolog is executed exactly as the job script. There-
fore, 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 pro-
cedures are started.
$job_owner
The user name of the job owner.
$job_id
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 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 jobs with the same environment set-
ting as that for the Grid Engine jobs that has just com-
pleted. An optional prefix "user@" specifies the user under
which this procedure is to be started. This procedure is
intended as a means for the Grid Engine 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 sge_execd(8)
may use a private epilogue script. Correspondingly, the exe-
cution host local configurations is can be overwritten by
the queue configuration (see queue_conf(5) ). Changing epi-
log will take immediate effect.
Note: epilog is executed exactly as the job script. There-
fore, 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 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 inter-
preter to start to interpret the script. This mechanism
is used by 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 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 inter-
preters instead. Thus, if shell_start_mode is set to
posix_compliant 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 Grid Engine to open the job script as well
as the epilogue and prologue 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 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 Grid Engine - see qsub(1)).
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 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 configura-
tion.
user_lists
The user_lists parameter contains a comma separated list of
so called 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 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 can-
not be overwritten by the execution host local configura-
tion.
xuser_lists
The xuser_lists parameter contains a comma separated list of
so called 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
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 can-
not be overwritten by the execution host local configura-
tion.
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 Edi-
tion. If users belong to projects in the projects list (see
above) and the xprojects list, they also cannot use the sys-
tem.
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.
stat_log_time
Grid Engine 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 can-
not be overwritten by the execution host local configura-
tion.
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 2 minutes 30 seconds.
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 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
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 can-
not be overwritten by the execution host local configura-
tion.
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 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
configuration.
set_token_cmd
This parameter is only present if your Grid Engine system is
licensed to support AFS.
Set_token_cmd points to a command which sets and extends AFS
tokens for Grid Engine jobs. In the standard 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 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 system 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
This parameter is only present if your Grid Engine system is
licensed to support AFS.
the time period for which AFS tokens are periodically
extended. 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.
gid_range
This parameter is only available for Grid Engine Enterprise
Edition systems. It is not present in Grid Engine.
The gid_range is a comma separated list of range expressions
of the form n-m (n as well as m being positive non-zero
integer numbers), 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 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 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
qdel(1). Without this parameter, forced deletion of
jobs is only allowed by the Grid Engine manager or
operator.
Note: Forced deletion for jobs is executed differently
depending on whether users are Grid Engine administra-
tors or not. In case of administrative users, the jobs
are removed from the internal database of 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.
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 con-
figuration.
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.
Changing qmaster_params will take immediate effect. 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.
schedd_params
This is foreseen for passing additional parameters to the
Grid Engine 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 sched_conf(5), 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.
Changing schedd_params will take immediate effect. The
default for schedd_params is none.
This value is a global configuration parameter only. It can-
not be overwritten by the execution host local configura-
tion.
IGNORE_FQDN
Ignore fully qualified domain names. It is switched on
if set to either "true" or "1". Can be used if all
hosts belonging to a Grid Engine cluster are part of a
single DNS domain. Switching it on my solve problems
with load reports due to different hostname resolutions
across the cluster.
execd_params
This is foreseen for passing additional parameters to the
Grid Engine 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.
DISABLE_AUTO_RESCHEDULING
If set to "true" or "1", the execd_param
RESCHEDULE_UNKNOWN (see below) is not taken into
account.
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 parameters are only available in a Grid Engine
Enterprise Edition system.
The maximum/minumum priority which Grid Engine Enter-
prise 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 nice(2) system call. Other systems
may provide different 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.
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.
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
contact 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, Grid Engine can reschedule jobs running on
such hosts to another system. RESCHEDULE_UNKNOWN con-
trols the time which Grid Engine will wait before jobs
are rescheduled after a host became unknown. The time
format specification is RESCHEDULE_UNKNOWN=hh:mm:ss. If
the special value RESCHEDULE_UNKNOWN=00:00:00 is set,
then jobs will not be rescheduled from this host.
Rescheduling is only initiated for jobs which have
actiated 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
tasks executes is in unknown state. Interactive jobs
(see qsh(1), qrsh(1), qtcsh(1)) are not rescheduled.
Migrating checkpointing jobs (and starting from the
last checkpoint) will be supported in a future release.
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 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 Grid Engine (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 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).
Changing admin_user will take immediate effect, but if
access to the Grid Engine 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 can-
not be overwritten by the execution host local configura-
tion.
finished_jobs
Grid Engine 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 can-
not be overwritten by the execution host local configura-
tion.
qlogin_daemon
This parameter specifies the executable that is to be
started on the server side of a qlogin(1) request. Usually
this is the fully qualified pathname of the system's telnet
daemon. If no value is given, a specialized Grid Engine com-
ponent 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
qlogin(1) request. Usually this is the fully qualified
pathname of the systems's telnet client program. If no value
is given, a specialized Grid Engine 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 qrsh(1) 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 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
qrsh(1) 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 component is used. The command is
automatically started with the target host and port number
as parameters like required for telnet(1). The Grid Engine
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 qrsh(1) request with a com-
mand 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 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
qrsh(1) 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 component is used. The command is
automatically started with the target host and port number
as parameters like required for telnet(1) plus the command
with its arguments to be executed remotely. The Grid Engine
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.
default_domain
Should be set if your hostname resolving yields unqualified
hostnames for your cluster hosts. In that case, the value of
default_domain is appended to the unqualified hostname to
define a fully qualified hostname.
Changing default_domain will take immediate effect. The
default for default_domain is none, in which case it will
not be used.
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), rsh(1), sh(1),
getpwnam(3), queue_conf(5), sched_conf(5), sge_execd(8),
sge_qmaster(8), sge_shepherd(8), cron(8), Grid Engine Ins-
tallation and Administration Guide.
COPYRIGHT
See sge_intro(1) for a full statement of rights and permis-
sions.
Man(1) output converted with
man2html