bootstrap - Grid Engine bootstrap file
contains parameters that are needed for the startup of Grid
Engine components. It is created during the sge_qmaster installation.
in a running system is not supported.
The paragraphs that follow provide brief descriptions of the individual
parameters that comprise the bootstrap configuration for a Grid Engine
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).
As 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 spooling area is interrupted, this
will result in unpredictable behavior.
parameter has no default value, but instead it is defined
during the master installation procedure.
Only needed if your Grid Engine 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
As a parameter set at installation time, changing default_domain
running system is not supported. The default for default_domain
"none", in which case it will not be used.
Ignore fully qualified domain name component of hostnames. Should be set if all
hosts belonging to a Grid Engine 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.
As a parameter set at installation time, changing ignore_fqdn
running system is not supported. The default for ignore_fqdn
Defines how writes its configuration and the status information of a running
The available spooling methods are berkeleydb
The name of a shared library containing the spooling_method
to be loaded
at initialization time. The extension characterizing a shared library (.so,
.sl, .dylib etc.) is not contained in spooling_lib
was set to berkeleydb
is set to libspoolb
, and if classic
chosen as spooling_method
is set to
Not all operating systems allow the dynamic loading of libraries. On these
platforms a certain spooling method (default: berkeleydb) is compiled into the
binaries and the parameter spooling_lib
will be ignored.
Defines parameters of the chosen spooling method that are needed to initialize
the spooling framework, e.g. to open database files.
The spooling parameters value for spooling method berkeleydb
e.g. "/opt/sge/default/spool/qmaster/spooldb" for spooling to a local
filesystem, or "myhost:sge" for spooling over a Berkeley DB RPC
is obsolete since recent BDB versions don't support RPC and
support has been removed from Grid Engine; it must be replaced if it occurs in
an old configuration before an upgrade. database directory
directory containing the spool files, and options
is a list of options
for the database. Currently the only valid value for options
, which means to open the database with the DB_PRIVATE flag to
specify that it is only accessed by a single process. This allows the
to be on an NFSv3 filesystem (as opposed to an NFSv4
one, which is otherwise necessary), but it is unsafe to access it with any
other program. In particular, this means that the backup script (inst_sge
-bup), similar scripts using the DB utilities, spooledit
etc., must not
be used while qmaster is running with berkeleydb spooling.
For spooling method classic
the spooling parameters take the form
<common_dir>;<qmaster spool dir>, e.g.
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 aix51, lx-amd64, lx-x86, hp11,
hp11-64, sol-amd64, sol-sparc etc.
The default location for the binary path is <sge_root>/bin
The location where the master spool directory resides. Only the and need to have
access to this directory. The master spool directory - in particular the
job_scripts directory and the messages 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
As a parameter set at installation time, changing qmaster_spool_dir
running system is not supported.
The default location for the master spool directory is
The security mode defines the set of security features the installed cluster is
using, as a comma-separated list.
Possible security mode settings are "none", "afs",
"dce", "kerberos", "csp", "munge" (no
additional security, AFS, DCE/GSSAPI, Kerberos/GSSAPI, X.509 certificate-based
security, and MUNGE authentication ⟨URL: http://munge.googlecode.com/
⟩). Their availability depends on how Grid Engine was built/installed.
The "dce" and "kerberos" methods are nearly equivalent,
calling the GSSAPI security modules in the same way, whether they were built
for Kerberos/GSSAPI or DCE/GSSAPI, except that "dce" runs the
as a wrapper for the
shepherd unless NO_SECURITY
is specified in execd_params
Only the CSP and MUNGE methods are currently properly functional and safe (from
the point of view of not exposing credentials generally). Both provide user
authentication, preventing impersonation of other users. CSP requires
certificates to be generated for each user and available on each host which
the user can access; it is appropriate for a loosely coupled system, e.g.
including desktop systems, particularly as it protects the communication
stream as well as providing authentication. MUNGE is appropriate in the
security domain of a tightly coupled system, such as a normal cluster, and
allows operation with enforce_user=auto
(see it requires the
daemon to be running on each host, with a shared secret and
doesn't encrypt the communication.
Do not use AFS security without some means of user authentication,
otherwise it is possible to submit jobs as another user and steal their
credential from a job running on the same node.
The number of listener threads (defaults set by installation). Increasing this
(below) to use additional cores/hardware threads
on the master host may improve performance in demanding cases.
The number of qmaster worker threads (defaults set by installation).
The number of qmaster scheduler threads (allowed: 0-1, default set by
installation: 1, off: 0; see -kt/-at option).
The number of JVM threads (allowed: 0-1, default set by installation, off: 0).
See for a full statement of rights and permissions.