SGE_EXECD(8)

πŸ’– SGE_EXECD(8) β€” the Grid Engine job execution agent & load sensor interface πŸ’–

okay so bestie, you know how there's a manual here, right? This is from the Grid Engine Administrative Commands corner of the man-page universe. Sit down, hydrate, and let's get into it. 🫢


✨ NAME ✨

sge_execd, sge_loadsensor β€” the Grid Engine job execution agent AND the load sensor interface. Two names, one glorious page. πŸ‘‘


✨ SYNOPSIS ✨

sge_execd [ -help ]

That's literally it. She's low-maintenance like that. πŸ’…


✨ DESCRIPTION ✨

So sge_execd runs the show for the Grid Engine queues that live local to the machine it's running on. It also executes and controls the jobs that sge_qmaster(8) sends over to be run on those queues β€” and it does that via sge_shepherd(8) or via the shepherd_cmd of sge_conf(5). ✨

Basically: qmaster says "here's a job", execd says "say less, bestie" and makes it happen on the local queues. No cap. πŸ”₯


✨ OPTIONS ✨

  • -help β€” prints a listing of all options. That's the whole list. She said "one option, and it's the help flag." 🌸

🌈 LOAD SENSORS 🌈

Okay this part is so important. One or more load sensors can be configured for sge_execd through the possibilities listed in sge_conf(5):

  • the global host configuration,
  • the execution-host-specific cluster configuration,
  • the default qloadsensor, or
  • qidle (when USE_QIDLE is set β€” see sge_conf(5)).

The executable path of the load sensor gets invoked by sge_execd on the regular (the schedule is governed by load_report_time in sge_conf(5)), and it delivers one or multiple load figures for the execution host (like, e.g., users currently logged in) or for the complete cluster (like, e.g., free disk space on a network wide scratch file system). πŸ’Ύβœ¨

A load sensor can be a script or a binary executable. Either way, its handling of the STDIN and STDOUT streams and its control flow must comply with the rules below. Periodt.

Load sensors are restarted if their modification time changes, or if they are killed. And heads up: if a sensor reads a configuration file, for instance, killing it will be necessary to pick up modifications to that file β€” unless the sensor will re-read a modified version. So like, know which one you're dealing with. 😭

πŸ¦‹ Load sensor interface πŸ¦‹

The load sensor must be written as an infinite loop, waiting at a certain point for input from STDIN.

  • If the string "quit" is read from STDIN, the load sensor should exit. πŸ‘‹
  • When an end-of-line is read from STDIN, a load data retrieval cycle should start.

The load sensor then performs whatever operation is necessary to compute the desired load figures. At the end of the cycle, the load sensor writes the result to stdout. And the format is giving:

  • A load value report starts with a line containing only either the word "start" or the word "begin".
  • Individual load values are separated by newlines.
  • Each load value report consists of three parts separated by colons (":") and containing no blanks.
  • The first part of a load value information is either the name of the host for which load is reported or the special name "global".
  • The second part is the symbolic name of the load value as defined in the host or global complex list (see complex(5) for details). This must be the full name of the complex, not the shortcut name. And if a load value is reported for which no entry in the host or global complex list exists, the reported load value is not used. πŸ’€
  • The third part is the measured load value.
  • A load value report ends with a line with only the word "end".
NB. If the runtime of the language in which the sensor is written buffers the output (e.g. Perl), ensure it is flushed on each iteration. Do not skip this. Fr fr. 😀

✨ 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, sge_execd 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.
  • 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 for the service "sge_qmaster" 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 for the service "sge_execd" instead to define that port.
  • SGE_ND β€” if set, don't daemonize the program (for debugging). πŸ›
  • SGE_ENABLE_COREDUMP β€” if set, enable core dumps on Linux when the admin_user is not root. Linux normally disables core dumps when the daemon has changed uid or gid. Setting SGE_ENABLE_COREDUMP in sge_execd's environment defeats that, to enable core dumps for debugging if they are otherwise allowed. This is typically not a big hazard with SGE, since most information is exposed in the spool area anyhow. Dumps will appear in the qmaster spool directory, which need not be world-readable. On Solaris, coreadm(1) may be used to enable such dumps. 🩹
  • SGE_EXECD_PIDFILE β€” path name of file to which to write the daemon process id at startup (default "execd.pid"). Note that this must be writable by the admin user (see bootstrap(5)).

πŸ”₯ RESTRICTIONS πŸ”₯

sge_execd usually gets started from root on each machine in the Grid Engine pool. But if it's started by a normal user, a spool directory must be used that the user has read/write access to. And in that case β€” heads up, bestie β€” only jobs being submitted by that same user are handled correctly by the system. So like, it works, but it's giving "very specific circumstances only." πŸ™ˆ


🌸 FILES 🌸

  • <sge_root>/<cell>/common/configuration β€” Grid Engine global configuration
  • <sge_root>/<cell>/common/local_conf/<host> β€” Grid Engine host specific configuration
  • <sge_root>/<cell>/spool/<host> β€” default execution host spool directory
  • <sge_root>/<cell>/common/act_qmaster β€” Grid Engine master host file
  • <sge_root>/bin/<arch>/qloadsensor β€” default load sensor
  • <sge_root>/bin/<arch>/qidle β€” idle load sensor per USE_QIDLE in execd_params
  • <sge_root>/<cell>/common/sgepasswd β€” password information used on Microsoft Windows hosts. See sgepasswd(5).

πŸŽ€ SEE ALSO πŸŽ€

sge_intro(1), sge_conf(5), complex(5), load_parameters(5), sgepasswd(5), sge_shepherd(8), sge_qmaster(8).

Go read those too, bestie. Iykyk. πŸ“šπŸ’–


See sge_intro(1) for a full statement of rights and permissions. ✨


and that's the whole page, bestie!! this one's from SGE 8.1.3pre, dated 2011-12-29 β€” an absolute icon of a release, we stan a vintage queen. bye ily, go run your jobs responsibly!! πŸ’–βœ¨πŸŽ€πŸ¦‹πŸŒΈπŸ’…πŸ«ΆπŸ‘‘πŸŒˆβ­πŸ“πŸ§šπŸ’œ