bootstrap - Grid Engine bootstrap file
bootstrap contains parameters that are needed for the startup of Grid
Engine components. It is created during the sge_qmaster installation.
Modifying bootstrap 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
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.
The admin_user 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 in a
running system is not supported. The default for default_domain is
"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 in a
running system is not supported. The default for ignore_fqdn is "true".
Defines how sge_qmaster(8) writes its configuration and the status
information of a running cluster.
The available spooling methods are berkeleydb and classic.
The name of a shared library containing the spooling_method to be
loaded at sge_qmaster(8) initialization time. The extension
characterizing a shared library (.so, .sl, .dylib etc.) is not
contained in spooling_lib. The value should be the full filename less
the extension, unless the shared library resides somewhere where the
system will normally find it.
If spooling_method was set to berkeleydb during installation,
spooling_lib is set to libspoolb, and if classic was chosen as
spooling_method, spooling_lib is set to libspoolc.
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
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 is
e.g. "/opt/sge/default/spool/qmaster/spooldb" for spooling to a local
filesystem, or "myhost:sge" for spooling over a Berkeley DB RPC server.
rpc_server 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
is the directory containing the spool files, and options is a list of
options for the database. Currently the only valid value for options
is private, 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 database directory 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
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
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,
The default location for the binary path is <sge_root>/bin
The location where the master spool directory resides. Only the
sge_qmaster(8) and sge_shadowd(8) 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 in
a 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 <http://dun.github.io/munge/>). 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 program
$SGE_ROOT/utilbin/$ARCH/starter_cred as a wrapper for the shepherd
unless NO_SECURITY is specified in execd_params in sge_conf(5).
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 sge_conf(5);) it requires the munged daemon
to be running on each host, with a shared secret and doesn't encrypt
NB. 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 and/or worker_threads (below) to use additional
cores/hardware threads on the master host may improve performance in
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 qconf(1) -kt/-at option).
The number of JVM threads (allowed: 0-1, default set by installation,
See sge_intro(1) for a full statement of rights and permissions.
SGE 8.1.3pre 2012-04-26 BOOTSTRAP(5)
Man(1) output converted with