QCONF(1)

โœจ qconf โ€” the Grid Engine Queue Configuration glow-up โœจ

okay bestie, gather round, because this is qconf from Grid Engine User Commands and she is that girl ๐Ÿ’…


๐ŸŒธ NAME ๐ŸŒธ

qconf โ€” Grid Engine Queue Configuration. that's it, that's the name, iconic.


๐Ÿฆ‹ SYNTAX ๐Ÿฆ‹

qconf options

๐Ÿ’– DESCRIPTION ๐Ÿ’–

so qconf is the tool that lets the system administrator add, delete, and modify the current Grid Engine configuration โ€” and we're talking the whole vibe here: queue management, host management, complex management, and user management. she also lets you examine the current queue configuration for existing queues, so you can peek at what's going on ๐Ÿ‘€

also, qconf supports the backslash character, \, at the end of a line to say "hey, the next line is a continuation of this one, no cap." and when it's displaying settings โ€” like the output of one of the -s* options โ€” qconf will break up long lines (meaning lines longer than 80 characters) into smaller lines using that backslash line continuation, where possible. important detail though: lines only get broken up at commas or whitespace. you can turn this whole feature off by setting the SGE_SINGLE_LINE environment variable. periodt.


โœจ OPTIONS โœจ

unless it says otherwise, all of these options and their operations are available to all users with a valid account. yes, really. ๐Ÿซถ


๐Ÿ’œ the A-team (adding things)

  • -Aattr obj_spec fname obj_instance,... โ€” <add to object attributes>. it's like -aattr (peep below) but it pulls the specs for the object attributes you wanna enhance from a file named fname. and unlike -aattr, you can enhance multiple attributes at once. their spec has to be listed in fname following the file format of the corresponding object (check queue_conf(5) for the queue, for example). requires root or manager privileges. ๐Ÿ‘‘
  • -Acal fname โ€” <add calendar>. adds a brand-new calendar definition to the Grid Engine environment. calendars are what Grid Engine uses to define the availability and unavailability schedules of queues. the format of a calendar definition is described in calendar_conf(5). the definition itself gets taken from the file fname. requires root or manager privileges.
  • -Ackpt fname โ€” <add checkpointing environment>. adds the checkpointing environment as defined in fname (see checkpoint(5)) to the list of supported checkpointing environments. requires root or manager privileges.
  • -Aconf fname_list โ€” <add configurations>. adds the configurations (see sge_conf(5)) specified in the files listed in the comma-separated fname_list. the configuration gets added for the host that is identical to the file name. requires root or manager privileges.
  • -Ae fname โ€” <add execution host>. adds the execution host defined in fname to the Grid Engine cluster. the format of the execution host specification is described in host_conf(5). requires root or manager privileges.
  • -Ahgrp fname โ€” <add host group configuration>. adds the host group configuration defined in the file. the file format of fname must comply with the format specified in hostgroup(5). requires root or manager privileges.
  • -Arqs fname โ€” <add RQS configuration>. adds the resource quota set (RQS) defined in the file named fname to the Grid Engine cluster. requires root or manager privileges.
  • -Ap fname โ€” <add PE configuration>. adds the parallel environment (PE) defined in fname to the Grid Engine cluster. requires root or manager privileges.
  • -Aprj fname โ€” <add new project>. adds the project description defined in fname to the list of registered projects (see project(5)). requires root or manager privileges.
  • -Aq fname โ€” <add new queue>. adds the queue defined in fname to the Grid Engine cluster. requires root or manager privileges.
  • -Au fname โ€” <add an ACL>. adds the user access list (ACL) defined in the file fname to Grid Engine. user lists are used for queue usage authentication. requires root, manager, or operator privileges. the file format of fname must comply with the format specified in access_list(5).

๐Ÿ’… the D/M/R girlies (deleting, modifying, replacing)

  • -Dattr obj_spec fname obj_instance,... โ€” <del. from object attribs>. like -dattr (see below) but the definition of the list attributes you're deleting entries from lives in the file named fname. and unlike -dattr, you can modify multiple attributes. their spec has to be listed in fname following the file format of the corresponding object (see queue_conf(5) for the queue, for example). requires root or manager privileges.
  • -Mattr obj_spec fname obj_instance,... โ€” <mod. object attributes>. like -mattr (see below) but it takes the specs for the object attributes you're modifying from the file named fname. and unlike -mattr, you can modify multiple attributes. their spec has to be listed in fname following the file format of the corresponding object (see queue_conf(5) for the queue, for example). requires root or manager privileges.
  • -Mc fname โ€” <modify complex>. overwrites the complex configuration with the contents of fname. the argument file must comply with the format specified in complex(5). requires root or manager privileges.
  • -Mcal fname โ€” <modify calendar>. overwrites the calendar definition as specified in fname. the argument file must comply with the format described in calendar_conf(5). requires root or manager privileges.
  • -Mckpt fname โ€” <modify ckpt. environment>. overwrites an existing checkpointing environment with the definitions in fname (see checkpoint(5)). heads up: the name attribute in fname has to match an existing checkpointing environment. requires root or manager privileges.
  • -Mconf fname_list โ€” <modify configurations>. modifies the configurations (see sge_conf(5)) specified in the files listed in the comma-separated fname_list. the configuration gets modified for the host that is identical to the file name. requires root or manager privileges.
  • -Me fname โ€” <modify execution host>. overwrites the execution host configuration for the specified host with the contents of fname, which must comply with the format defined in host_conf(5). requires root or manager privilege.
  • -Mhgrp fname โ€” <modify host group configuration>. lets you change the host group configuration with a single command. every host group configuration entry contained in fname gets applied, and any configuration entries not contained in fname get deleted. the file format of fname must comply to the format specified in hostgroup(5). requires root or manager privileges.
  • -Mrqs fname [mrqs_name] โ€” <modify RQS configuration>. same as -mrqs (see below) but instead of firing up an editor to modify the RQS configuration, the file fname is treated as containing a changed configuration. the name of the rule set in fname must be the same as rqs_name. if rqs_name is not set, all rule sets are overwritten by the rule sets in fname. refer to sge_resource_quota(5) for the deets on the RQS configuration format. requires root or manager privileges.
  • -Mp fname โ€” <modify PE configuration>. same as -mp (see below) but instead of invoking an editor to modify the PE configuration, the file fname is considered to contain a changed configuration. refer to sge_pe(5) for details on the PE configuration format. requires root or manager privilege.
  • -Mprj fname โ€” <modify project configuration>. same as -mprj (see below) but instead of invoking an editor to modify the project configuration, the file fname is considered to contain a changed configuration. refer to project(5) for details on the project configuration format. requires root or manager privilege.
  • -Mq fname โ€” <modify queue configuration>. same as -mq (see below) but instead of invoking an editor to modify the queue configuration, the file fname is considered to contain a changed configuration. refer to queue_conf(5) for details on the queue configuration format. requires root or manager privilege.
  • -Msconf fname โ€” <modify scheduler configuration from fname>. the current scheduler configuration (see sched_conf(5)) is overridden with the configuration specified in the file. requires root or manager privilege.
  • -Mstree fname โ€” <modify share tree>. modifies the definition of the share tree (see share_tree(5)). the modified sharetree is read from the file fname. requires root or manager privileges.
  • -Mu fname โ€” <modify ACL>. takes the user access list (ACL) defined in fname and uses it to overwrite any existing ACL with the same name. see access_list(5) for info on the ACL configuration format. requires root or manager privilege.
  • -Muser fname โ€” <modify user>. modifies the user defined in fname in the Grid Engine cluster. the format of the user specification is described in user(5). requires root or manager privileges.
  • -Rattr obj_spec fname obj_instance,... โ€” <replace object attribs>. like -rattr (see below) but the definition of the list attributes whose content is getting replaced lives in the file named fname. and unlike -rattr, you can modify multiple attributes. their spec has to be listed in fname following the file format of the corresponding object (see queue_conf(5) for the queue, for example). requires root/manager privileges.

and bestie, we are so not done yet โ€” there's more of this page to come, don't you dare close the tab ๐Ÿ’–โœจ

  • -aattr obj_spec attr_name val obj_instance,... โ€” add to object attributes

okay so this one is a whole vibe ๐Ÿ’… it lets you add specs to one single configuration list attribute across multiple instances of an object, all with a single command. Efficiency queen.

The object types it supports rn are: queues, hosts, host groups, parallel environments, resource quota sets, users, projects, calendars, and checkpointing interface configurations โ€” and you name them in obj_spec as queue, exechost, hostgroup, pe, resource_quota, user, project, calender, userset, or ckpt. (yes bestie, calender is spelled like that in here, don't come for me, I don't make the rules ๐Ÿ™ˆ)

For the obj_spec queue, obj_instance can be a cluster queue name, a queue domain name, or a queue instance name. All the deets about the different queue names live in sge_types(5). Depending on what kind of obj_instance you pass, this adds to the cluster queues attribute sublist either the cluster queue's implicit default configuration value, or the queue domain configuration value, or the queue instance configuration value. โœจ

The queue load_thresholds parameter is a classic example of a list attribute, iykyk. With -aattr you can add entries to lists like that โ€” delete them with -dattr, modify them with -mattr, and replace them with -rattr. Whole little family ๐Ÿซถ

For the obj_spec rqs, the obj_instance is a unique identifier for a specific rule. That identifier = a rule-set name + either the number of the rule in the list, or the name of the rule, separated by a /.

The name of the configuration attribute you're enhancing goes in attr_name, followed by val as a name=value pair. And the space-separated list of object instances (like, the list of queues) that the changes apply to goes at the end of the command.

One restriction, and it's real: for the exechost object, the load_values attribute cannot be modified (see host_conf(5)). ๐Ÿšซ

Requires root or manager privileges. ๐Ÿ’€

  • -acal calendar_name โ€” add calendar

Adds a brand new calendar definition to the Grid Engine environment. ๐ŸŒธ Calendars are how Grid Engine defines availability and unavailability schedules for queues. The format of a calendar definition is described in calendar_conf(5).

Give it the calendar name in the option argument and qconf will open a temporary file and start up the text editor indicated by the EDITOR environment variable (default vi(1) if EDITOR is not set). After you enter the calendar definition and close the editor, the new calendar is checked and registered with sge_qmaster(8). Requires root/manager privileges. ๐Ÿ‘‘

  • -ackpt ckpt_name โ€” add checkpointing environment

Adds a checkpointing environment under the name ckpt_name to the list of checkpointing environments maintained by Grid Engine, and to the set that's usable for submitting checkpointing jobs (see checkpoint(5) for details on the format of a checkpointing environment definition). ๐ŸŽ€

qconf retrieves a default checkpointing environment configuration and runs vi(1) (or $EDITOR if the EDITOR environment variable is set) so you can customize it. Upon exit from the editor, the checkpointing environment is registered with sge_qmaster(8). Requires root/manager privileges.

  • -aconf host,... โ€” add configuration

Successively adds configurations (see sge_conf(5)) for the hosts in the comma-separated host list. ๐Ÿฆ‹ For each host, an editor ($EDITOR, if defined, or vi(1)) is invoked and the configuration for that host can be entered. The configuration is registered with sge_qmaster(8) after saving the file and quitting the editor. Requires root or manager privileges.

  • -ae [host_template] โ€” add execution host

Adds a host to the list of Grid Engine execution hosts. Lowkey convenient: if a queue is configured on a host, that host is automatically added to the Grid Engine execution host list. ๐Ÿ’ซ

Adding execution hosts explicitly gets you the perk of being able to specify parameters โ€” like load scale values โ€” at registration time. But ngl, those parameters can be modified (from their defaults) at any later time via the -me option described below.

If the host_template argument is present, qconf retrieves the configuration of the specified execution host from sge_qmaster(8), or a generic template otherwise. The template then gets stored in a file and qconf executes vi(1) (or the editor indicated by $EDITOR if the EDITOR environment variable is set) to change the entries in that file. The format of the execution host specification is described in host_conf(5). When the changes are saved in the editor and the editor is quit, the new execution host is registered with sge_qmaster(8). Requires root/manager privileges. ๐Ÿ”ฅ

  • -ah hostname,... โ€” add administrative host

Adds hosts hostname to the Grid Engine trusted host list. ๐Ÿซถ (a host must be in this list to execute administrative Grid Engine commands โ€” the sole exception being running qconf on the sge_qmaster(8) node). The default Grid Engine installation procedures usually add all designated execution hosts (see the -ae option above) to the Grid Engine trusted host list automatically. Requires root or manager privileges.

  • -ahgrp group โ€” add host group configuration

Adds a new host group with the name specified in group. ๐ŸŽ€ This command invokes an editor (either vi(1) or the editor indicated by the EDITOR environment variable). The new host group entry is registered after changing the entry and exiting the editor. Requires root or manager privileges.

  • -arqs [rqs_name] โ€” add new RQS

Adds one or more Resource Quota Set (RQS) description(s) under the names rqs_name to the list of RQSs maintained by Grid Engine. โœจ (See sge_resource_quota(5) for details on the format of an RQS definition.)

qconf retrieves a default RQS configuration and executes vi(1) (or $EDITOR if the EDITOR environment variable is set) to let you customize the RQS configuration. Upon exit from the editor, the RQS is registered with sge_qmaster(8). Requires root/manager privileges.

  • -am user,... โ€” add managers

Adds the indicated users to the Grid Engine manager list. Requires root or manager privileges. ๐Ÿ‘‘

Managers have full access to the Grid Engine configuration and operational features. Superusers on administration hosts have manager privileges by default.

  • -ao user,... โ€” add operators

Adds the indicated users to the Grid Engine operator list. Requires root or manager privileges.

Operators have the same privileges as managers, except they cannot make configuration changes. ๐Ÿ’… (so close, yet so far)

  • -ap pe_name โ€” add new PE

Adds a Parallel Environment (PE) description under the name pe_name to the list of PEs maintained by Grid Engine, and to the set that's usable for submitting parallel jobs (see sge_pe(5) for details on the format of a PE definition). ๐ŸŒˆ

qconf retrieves a default PE configuration and executes vi(1) (or $EDITOR if the EDITOR environment variable is set) so you can customize the PE configuration. Upon exit from the editor, the PE is registered with sge_qmaster(8). Requires root/manager privileges.

  • -at thread_name โ€” activates thread in master

Activates an additional thread in the master process. ๐Ÿงš thread_name can be either "scheduler" or "jvm". The corresponding thread is only started when it is not already running. There may be only one scheduler and only one JVM thread in the master process at the same time. (monogamous threads, periodt)

  • -aprj โ€” add new project

Adds a project description to the list of registered projects (see project(5)). ๐Ÿ“ qconf retrieves a template project configuration and executes vi(1) (or $EDITOR if the EDITOR environment variable is set) to let you customize the new project. Upon exit from the editor, the template is registered with sge_qmaster(8). Requires root or manager privileges.

  • -aq [queue_name] โ€” add new queue

qconf retrieves the default queue configuration (see queue_conf(5)) and executes vi(1) (or $EDITOR if the EDITOR environment variable is set) so you can customize the queue configuration. ๐Ÿ’œ Upon exit from the editor, the queue is registered with sge_qmaster(8).

A minimal configuration requires only that the queue name and queue hostlist be set. That's it, that's the whole bar. โœจ

Requires root or manager privileges.

  • -as hostname,... โ€” add submit hosts

Add hosts hostname to the list of hosts allowed to submit Grid Engine jobs and control their behavior only. ๐Ÿฆ‹ Requires root or manager privileges.

  • -astnode node_path=shares,... โ€” add share tree node

Adds the specified share tree node(s) to the share tree (see share_tree(5)). ๐ŸŒณ The node_path is a hierarchical path:

([/]node_name[[/.]node_name...])

specifying the location of the new node in the share tree. The base name of the node_path is the name of the new node. The node is initialized to the number of specified shares. Requires root or manager privileges.

  • -astree โ€” add share tree

Adds the definition of a share tree to the system (see share_tree(5)). ๐ŸŒธ A template share tree is retrieved and an editor (either vi(1) or the editor indicated by $EDITOR) is invoked for modifying the share tree definition. Upon exiting the editor, the modification is registered with sge_qmaster(8). Requires root or manager privileges.

  • -Astree fname โ€” add share tree

Adds the definition of a share tree to the system (see share_tree(5)) from the file fname. ๐Ÿ“‚ Requires root or manager privileges.

  • -au user,... acl_name,... โ€” <add users to ACLs> ๐Ÿ’– drops users into Grid Engine user access lists (ACLs). These lists are what queue usage authentication checks against, so it's a real-privilege kind of situation: you need root/manager/operator privileges. Once someone's in, they can submit jobs and run them โ€” as long as they've got access to a submit host and an execution host โ€” but they cannot mess with the Grid Engine configuration or operation. The one exception? They can alter or delete their own jobs. That's it, that's the whole vibe.
  • -Auser fname โ€” <add user> โž• adds the user defined in fname to the Grid Engine cluster. The format of that user spec lives over in user(5). Needs root or manager privileges.
  • -auser โ€” <add user> โœจ adds a user to the list of registered users (peep user(5)). This one literally opens an editor for you โ€” either vi(1) or whatever $EDITOR says โ€” on a template user. Change the entry, exit the editor, and boom: the new user is registered. Needs root or manager privileges.
  • -bonsai โ€” <human-readable sharetree> ๐ŸŒณ shows a textual tree layout of the share tree, basically the same energy as the graphical view in qmon(1). For the same info in a way less readable (linearized) form, that's what -sstree is for.
  • -clearusage [user_list] โ€” <clear sharetree usage> ๐Ÿงน clears usage from the sharetree. Give it a user_list and it wipes just those; leave it off and it's all users and projects. Either way, every bit of specified usage gets set to zero.
  • -cq wc_queue_list โ€” <clean queue> ๐Ÿšฎ cleans a queue of jobs that haven't been reaped. (Real talk: it actually purges jobs still remaining on the queue.) This is primarily a development tool, bestie. Needs root/manager/operator privileges. You can find a description of wc_queue_list in sge_types(5).
  • -dattr obj_spec attr_name val obj_instance,... โ€” <delete in object attribs> ๐Ÿ’… lets you delete specifications in a single configuration list attribute across multiple instances of an object, all with one command. More on obj_spec and obj_instance is in the description of -aattr.
  • -dcal calendar_name,... โ€” <delete calendar> ๐Ÿ“… deletes the specified calendar definition from Grid Engine. Needs root/manager privileges.
  • -dckpt ckpt_name โ€” <delete checkpointing environment> ๐Ÿ—‘๏ธ deletes the specified checkpointing environment. Needs root/manager privileges.
  • -dconf host,... โ€” <delete local configuration> ๐Ÿงผ the local configuration entries for the specified hosts get deleted from the configuration list. Needs root or manager privilege.
  • -de host_name,... โ€” <delete execution host> ๐Ÿ–ฅ๏ธ deletes hosts from the Grid Engine execution host list. Needs root or manager privileges.
  • -dh host_name,... โ€” <delete administrative host> ๐Ÿ” deletes hosts from the Grid Engine trusted host list. Heads up: the host where sge_qmaster(8) is currently running cannot be removed from the list of administrative hosts. Needs root or manager privileges.
  • -dhgrp group โ€” <delete host group configuration> ๐Ÿ‘ฏ deletes the host group configuration with the name given in group. Needs root or manager privileges.
  • -drqs rqs_name_list โ€” <delete RQS> ๐ŸŽฏ deletes the specified resource quota sets (RQS). Needs root or manager privileges.
  • -dm user[,user,...] โ€” <delete managers> ๐Ÿ‘‘ deletes managers from the manager list. Needs root or manager privileges. And nope โ€” it is not possible to delete the admin user or the user root from the manager list. Periodt.
  • -do user[,user,...] โ€” <delete operators> ๐Ÿ› ๏ธ deletes operators from the operator list. Needs root or manager privileges. Same rule as above: you cannot delete the admin user or the user root from the operator list.
  • -dp pe_name โ€” <delete parallel environment> ๐ŸŒˆ deletes the specified parallel environment (PE). Needs root or manager privileges.
  • -dprj project,... โ€” <delete projects> ๐Ÿ“ deletes the specified project(s). Needs root/manager privileges.
  • -dq queue_name,... โ€” <delete queue> ๐Ÿงบ removes the specified queue(s) โ€” and they must be empty. Needs root or manager privileges.
  • -ds host_name,... โ€” <delete submit host> ๐Ÿ“ค deletes hosts from the Grid Engine submit host list. Needs root or manager privileges.
  • -dstnode node_path,... โ€” <delete share tree node> ๐ŸŒฒ deletes the specified share tree node(s). The node_path is a hierarchical path ([/]node_name[[/.]node_name...]) that says where the node to be deleted lives in the share tree. Needs root or manager privileges.
  • -dstree โ€” <delete share tree> ๐Ÿช“ deletes the current share tree. Needs root or manager privileges.
  • -du user,... acl_name,... โ€” <delete users from ACL> ๐Ÿ’” deletes one or more users from one or more Grid Engine user access lists (ACLs). Needs root/manager/operator privileges.
  • -dul acl_name,... โ€” <delete user lists> ๐Ÿ—‚๏ธ deletes one or more user lists from the system. Needs root/manager/operator privileges.
  • -duser user,... โ€” <delete users> ๐Ÿšซ deletes the specified user(s) from the list of registered users. Needs root or manager privileges.
  • -help โ€” prints a listing of all options. ๐Ÿ’โ™€๏ธ
  • -k{m|s|e[j] {host,...|all}} โ€” <shutdown Grid Engine> ๐Ÿ›‘
โš ๏ธ Note: the -ks switch is deprecated and may be removed in a future release. Please use the -kt switch instead. (Do not come crying to me later.)

Used to shut down Grid Engine components (daemons). In the form -km, sge_qmaster(8) is forced to terminate in a controlled fashion. Same deal with -ks โ€” it causes termination of the scheduler thread. Shutdown of running sge_execd(8) processes that are currently registered is initiated by the -ke option. If you specify -kej instead, all jobs running on the execution hosts are aborted prior to termination of the corresponding sge_execd(8). The comma-separated host list says which execution hosts get addressed by the -ke and -kej options. And if you hand it the keyword all instead of a host list, every running sge_execd(8) process gets shut down. Job abortion initiated by -kej will result in dr state for all running jobs until sge_execd(8) is running again. Needs root or manager privileges.

  • -kt thread_name โ€” <terminate master thread> ๐Ÿงต terminates a thread in the master process. Currently the only supported ones are shutting down the "scheduler" and the "jvm" thread. The command will only be successful if the corresponding thread is actually running.
  • -kec {id,...|all} โ€” <kill event client> ๐Ÿ“ด used to shut down event clients registered at sge_qmaster(8). The comma-separated event client list says which event clients get addressed by -kec. If you use the keyword all instead of an event client list, all running event clients get terminated โ€” except special clients like the scheduler thread, they're safe. Needs root or manager privilege.
  • -mattr obj_spec attr_name val obj_instance,... โ€” <modify object attributes> ๐ŸŽ€ lets you change a single configuration attribute across multiple instances of an object with one single command. More on obj_spec and obj_instance over in the description of -aattr.
  • -mc โ€” <modify complex> ๐Ÿงฉ the complex configuration (see complex(5)) gets retrieved, an editor runs (either vi(1) or whatever $EDITOR says), and the changed complex configuration is registered with sge_qmaster(8) when the editor exits. Needs root or manager privilege.
  • -mcal calendar_name โ€” <modify calendar> ๐Ÿ—“๏ธ the specified calendar definition (see calendar_conf(5)) gets retrieved, an editor runs (either vi(1) or whatever $EDITOR says), and the changed calendar definition is registered with sge_qmaster(8) when the editor exits. Needs root or manager privilege.
  • -mckpt ckpt_name โ€” <modify checkpointing environment> ๐Ÿ’พ retrieves the current configuration for the specified checkpointing environment, runs an editor (either vi(1) or whatever the EDITOR environment variable points at), and registers the new configuration with the sge_qmaster(8). Details on the checkpointing environment configuration format are in checkpoint(5). Needs root or manager privilege.
  • -mconf [host,...|global] โ€” <modify configuration> โš™๏ธ the configuration for the specified host gets retrieved, an editor runs (either vi(1) or whatever $EDITOR says), and the changed configuration is registered with sge_qmaster(8) when the editor exits. If you skip the optional host argument โ€” or pass the special host name global โ€” then the global configuration is what gets modified. The format of the configuration is described in sge_conf(5). Needs root or manager privilege.
  • -me hostname โ€” <modify execution host> ๐Ÿ–ฅ๏ธโœจ retrieves the current configuration for the specified execution host, runs an editor (either vi(1) or whatever the EDITOR environment variable points at), and registers the changed configuration with sge_qmaster(8) when you exit the editor. The format of the execution host configuration is described in host_conf(5). Needs root or manager privilege.
  • -mhgrp group โ€” <modify host group configuration> ๐Ÿซถ the host group entries for the host group named in group get retrieved and an editor runs (either vi(1) or whatever the EDITOR environment variable points at) so you can modify the host group configuration. Close the editor and the modification is registered. The format of the host group configuration is described in hostgroup(5). Needs root or manager privileges.
  • -mrqs [rqs_name] โ€” pulls up the resource quota set (RQS) configuration that you named in rqs_name. If you don't hand it a rqs_name, it goes and grabs every single resource quota set instead, pops open an editor (vi(1) or whatever editor your EDITOR environment variable points at), and then registers the fresh config with sge_qmaster(8). Want the format deets? They're in sge_resource_quota(5). Requires root or manager privilege. ๐Ÿ‘‘
  • -mp pe_name โ€” grabs the current configuration for the parallel environment (PE) you specified, opens an editor (vi(1) or the one from EDITOR), and registers the new config with sge_qmaster(8). Format specs live in sge_pe(5). Requires root or manager privilege. ๐Ÿฆ‹
  • -mprj project โ€” the data for that specific project gets retrieved (peep project(5)), an editor (vi(1) or the one $EDITOR names) is invoked so you can edit the project definition, and the moment you exit the editor the modification is registered. Requires root or manager privileges. ๐Ÿ’…
  • -mq queuename โ€” retrieves the current config for the queue you named, runs an editor (vi(1) or the one in EDITOR), and registers the new config with sge_qmaster(8). Queue config format? queue_conf(5). Requires root or manager privilege. ๐ŸŽ€
  • -msconf โ€” the current scheduler configuration (sched_conf(5)) gets retrieved, an editor runs (vi(1) or the one $EDITOR says), and the changed config is registered with sge_qmaster(8) as soon as you exit. Requires root or manager privilege. โญ
  • -mstnode node_path=shares,... โ€” modifies the share tree node(s) you point at inside the share tree (see share_tree(5)). node_path is a hierarchical path ([/]node_name[[/.]node_name...]) that spells out where an existing node lives in the share tree. The node gets set to the number of shares you specify. Requires root or manager privileges. ๐ŸŒธ
  • -mstree โ€” modifies the share tree definition itself (share_tree(5)). The current share tree is retrieved, an editor (vi(1) or the one $EDITOR names) is invoked so you can edit it, and once you exit the editor the modification is registered with sge_qmaster(8). Requires root or manager privileges. ๐Ÿ”ฅ
  • -mu acl_name โ€” retrieves the current config for the user access list you named, runs an editor (vi(1) or the one in EDITOR), and registers the new config with sge_qmaster(8). The config format has to comply with what's laid out in access_list(5). Requires root or manager privilege. ๐Ÿซถ
  • -muser user โ€” retrieves the data for that specific user (user(5)), invokes an editor (vi(1) or the one EDITOR indicates) so you can edit the user definition, and registers the modification when you exit. Requires root or manager privileges. ๐Ÿ™ˆ
  • -purge queue attr_nm,... obj_spec โ€” deletes the values of the attributes listed in attr_nm from the object defined in obj_spec. obj_spec can be queue_instance or queue_domain. The attribute names are described over in queue_conf(5). Heads up, bestie: this only works on a single queue instance or domain. It cannot be used on a cluster queue. In the case where obj_spec is queue@@hostgroup, the attribute values defined in attr_nm that are set for the indicated hostgroup get deleted, but not those set for the hosts contained by that hostgroup. And if attr_nm is '*', all attribute values set for the given queue instance or domain are deleted. ๐Ÿ’€ The main difference between -dattr and -purge is that -dattr removes a value from a single list attribute, whereas -purge removes one or more overriding attribute settings from a cluster queue configuration. With -purge, the entire attribute is deleted for the given queue instance or queue domain.
  • -rattr obj_spec attr_name val obj_instance,... โ€” lets you replace a single configuration list attribute across multiple instances of an object with just one command. Want more on obj_spec and obj_instance? It's in the description of -aattr. Requires root or manager privilege. ๐Ÿ‘‘
  • -rsstnode node_path,... โ€” recursively shows the name and shares of the share tree node(s) you named, plus the names and shares of their child nodes (leaves stay hidden). See share_tree(5). The node_path is a hierarchical path ([/]node_name[{/|.}node_name...]) specifying where a node sits in the share tree. ๐ŸŒˆ
  • -sc โ€” displays the complex configuration. ๐Ÿฆ‹
  • -scal calendar_name โ€” displays the configuration of the calendar you named. ๐ŸŽ€
  • -scall โ€” shows a list of all calendars currently defined. โญ
  • -sckpt ckpt_name โ€” displays the configuration of the checkpointing environment you named. ๐Ÿ’œ
  • -sckptl โ€” shows a list of the names of all checkpointing environments currently configured. ๐ŸŒธ
  • -sconf [host,...|global] โ€” prints the global or local (host specific) configuration. If you omit the optional comma-separated host list argument, or you pass the special string global, the global configuration is displayed. The config in effect on a certain host is the merger of the global configuration and the host specific local configuration. The format is described in sge_conf(5). ๐Ÿ’…
  • -sconfl โ€” displays a list of hosts that have configurations available. The special host name global refers to the global configuration. โœจ
  • -sds โ€” displays detached settings in the cluster configuration (see queue_conf(5)). ๐Ÿ”ฅ
  • -se hostname โ€” displays the definition of the execution host you named. ๐Ÿฆ‹
  • -sel โ€” displays the Grid Engine execution host list. ๐Ÿ‘‘
  • -secl โ€” displays the Grid Engine event client list. ๐ŸŽ€
  • -sh โ€” displays the Grid Engine administrative host list. โญ
  • -shgrp group โ€” displays the host group entries for the group specified in group. ๐ŸŒธ
  • -shgrpl โ€” displays a name list of all currently defined host groups that have a valid host group configuration. ๐Ÿ’œ
  • -shgrp_tree group โ€” shows a tree like structure of the host group. ๐ŸŒˆ
  • -shgrp_resolved group โ€” shows a list of all hosts that are part of the definition of the host group. If the host group definition contains sub host groups, then those groups get resolved too and the hostnames are printed. โœจ
  • -srqs [rqs_name_list] โ€” shows the definition of the resource quota sets (RQS) specified by the argument. ๐Ÿซถ
  • -srqsl โ€” shows a list of all currently defined resource quota sets (RQSs). ๐Ÿ“
  • -sm โ€” displays the managers list. ๐Ÿ‘‘
  • -so โ€” displays the operator list. ๐Ÿ’…
  • -sobjl obj_spec attr_name val โ€” shows a list of all configuration objects for which val matches at least one configuration value of the attributes whose name matches attr_name. obj_spec can be "queue" or "queue_domain" or "queue_instance" or "exechost". Note: when "queue_domain" or "queue_instance" is specified as obj_spec, matching is only done with the attribute overridings concerning the host group or the execution host. In that case queue domain names respectively queue instances are returned. ๐Ÿฆ‹ attr_name can be any of the configuration file keywords listed in queue_conf(5) or host_conf(5). Wildcards can also be used to match multiple attributes. ๐ŸŽ€ val can be an arbitrary string or a wildcard expression. โœจ
  • -sp pe_name โ€” shows the definition of the parallel environment (PE) specified by the argument. ๐ŸŒธ
  • -spl โ€” shows a list of all currently defined parallel environments (PEs). ๐Ÿ’œ
  • -sprj project โ€” shows the definition of the project you named (see project(5)). โญ
  • -sprjl โ€” shows the list of all currently defined projects. ๐ŸŒˆ
  • -sq wc_queue_list โ€” displays one or multiple cluster queues or queue instances. A description of wc_queue_list can be found in sge_types(5). ๐Ÿ”ฅ
  • -sql โ€” shows a list of all currently defined cluster queues. ๐Ÿ‘‘
  • -ss โ€” displays the Grid Engine submit host list. ๐Ÿซถ
  • -ssconf โ€” displays the current scheduler configuration in the format explained in sched_conf(5). ๐Ÿ’…
  • -sstnode node_path,... โ€” show share tree node: bestie, this shows the name and shares of the specified share tree node(s) (see share_tree(5)). The node_path is a hierarchical path ([/]node_name[{/|.}node_name...) specifying where a node lives in the share tree. ๐Ÿ’…
  • -sstree โ€” show share tree: shows the definition of the share tree (see share_tree(5)). A different view is provided by -bonsai. ๐ŸŒณ
  • -sst โ€” show formatted share tree: shows the definition of the share tree in a tree view (see share_tree(5)). โœจ
  • -sss โ€” show scheduler status: rn it displays the host on which the Grid Engine scheduler is active, or an error message if no scheduler is running. ๐Ÿซถ
  • -su acl_name โ€” show user ACL: displays a Grid Engine user access list (ACL). ๐Ÿ”
  • -sul โ€” show user lists: displays a list of names of all currently defined Grid Engine user access lists (ACLs). ๐Ÿ“‹
  • -suser user,... โ€” show user: shows the definition of the specified user(s) (see user(5)). ๐Ÿ‘ค
  • -suserl โ€” show users: shows the list of all currently defined users. ๐Ÿ‘ฅ
  • -tsm โ€” trigger scheduler monitoring: the Grid Engine scheduler is forced by this option to print trace messages of its next scheduling run to the file <sge_root>/<cell>/common/schedd_runlog. The messages indicate the reasons for jobs and queues not being selected in that run. Requires root or manager privileges. ๐Ÿšจ
Note, that the reasons for job requirements being invalid with respect to resource availability of queues are displayed using the format as described for the qstat(1) -F option (see description of Full Format in section OUTPUT FORMATS of the qstat(1) manual page. ๐Ÿ’€

๐ŸŒˆ ENVIRONMENT VARIABLES ๐ŸŒˆ

  • SGE_ROOT โ€” specifies the location of the Grid Engine standard configuration files. ๐Ÿ“
  • SGE_CELL โ€” if set, specifies the default Grid Engine cell. To address a Grid Engine cell qconf uses (in the order of precedence):
    1. The name of the cell specified in the environment variable SGE_CELL, if it is set.
    2. The name of the default cell, i.e. default.

slay

  • SGE_DEBUG_LEVEL โ€” if set, specifies that debug information should be written to stderr. In addition the level of detail in which debug information is generated is defined. ๐Ÿ›
  • SGE_QMASTER_PORT โ€” if set, specifies the tcp port on which sge_qmaster(8) is expected to listen for communication requests. Most installations will use a services map entry instead to define that port. ๐Ÿ”Œ
  • SGE_EXECD_PORT โ€” if set, specifies the tcp port on which sge_execd(8) is expected to listen for communication requests. Most installations will use a services map entry instead to define that port. ๐Ÿ”Œ
  • SGE_SINGLE_LINE โ€” if set, indicates that long lines should not be broken up using backslashes. This setting is useful for scripts which expect one entry per line. ๐Ÿ“

๐Ÿ’… RESTRICTIONS ๐Ÿ’…

Modifications to a queue configuration do not affect an active queue, taking effect on next invocation of the queue (i.e., the next job). So like, the queue won't change until it wakes up for its next job, periodt. ๐Ÿ˜ญ


๐ŸŽ€ FILES ๐ŸŽ€

  • <sge_root>/<cell>/common/act_qmaster โ€” Grid Engine master host file. ๐Ÿ—‚๏ธ

๐Ÿฆ‹ SEE ALSO ๐Ÿฆ‹

sge_intro(1), access_list(5), checkpoint(5), complex(5), host_conf(5), project(5), qstat(1), queue_conf(5), sge_conf(5), sge_execd(8), sge_pe(5), sge_qmaster(8), sge_resource_quota(5). All the besties you need to vibe with. ๐Ÿ’–


See sge_intro(1) for a full statement of rights and permissions. ๐Ÿ“œ


And that's the whole vibe, bestie! This page was brought to you by SGE 8.1.3pre, dated 2012-09-17, and it's the one and only QCONF(1). Stay slaying those Grid Engine configs! ๐Ÿ’…โœจ