RSL(5)

💖 NAME 💖

okay bestie, this is the manual page for rsl — the GRAM5 RSL Attributes. It lives in section 5 of the Grid Community Toolkit manual. No cap, it's a whole vibe. 💅

🌸 DESCRIPTION 🌸

so basically RSL attributes are the little keys you set to tell GRAM5 how to run your job. Here's every single one, in order, with all the defaults and caveats. Let's go. 🚀

• arguments — the command line args for the executable. If a single argument needs a space in it, wrap it in quotes.
• count — how many times the executable gets run. [Default: 1]
• directory — sets the path of the directory the jobmanager uses as the default directory for the requested job. [Default: $(HOME)]
• dry_run — if dryrun = yes, the jobmanager does not submit the job for execution and just returns success. [Default: no]
• environment — the environment variables that get defined for the executable, on top of the default set the jobmanager already gives the job.
• executable — name of the executable file to run on the remote machine. If the value is a GASS URL, the file gets transferred to the remote gass cache before the job runs, then removed after the job terminates.
• expiration — time (in seconds) after a job fails to receive a two-phase commit end signal before it gets cleaned up. [Default: 14400]
• file_clean_up — a list of files that get removed after the job is completed.
• file_stage_in — a list of ("remote URL" "local file") pairs that say which files to stage to the nodes that will run the job.
• file_stage_in_shared — a list of ("remote URL" "local file") pairs that say which files to stage into the cache. A symlink from the cache to the "local file" path gets made.
• file_stage_out — a list of ("local file" "remote URL") pairs that say which files to stage from the job to a GASS-compatible file server.
• gass_cache — location to override the GASS cache location.
• gram_my_job — obsolete and ignored. [Default: collective]
• host_count — only applies to clusters of SMP computers, like newer IBM SP systems. It defines the number of nodes ("pizza boxes") to spread the "count" processes across.
• job_type — this specifies how the jobmanager should start the job. Possible values are:
  • single — even if the count > 1, only start 1 process or thread
  • multiple — start count processes or threads
  • mpi — use the appropriate method (e.g. mpirun) to start a program compiled with a vendor-provided MPI library. Program is started with count nodes
  • condor — starts condor jobs in the "condor" universe.

[Default: multiple]

• library_path — a list of paths to append to the system-specific library path environment variables. [Default: $(GLOBUS_LOCATION)/lib]
• loglevel — override the default log level for this job. The value is a combination of the strings FATAL, ERROR, WARN, INFO, DEBUG, TRACE joined by the | character.
• logpattern — override the default log path pattern for this job. The value is a string (maybe containing RSL substitutions) that gets evaluated to the path where the log gets written. If the resulting string contains $(DATE) (or any other RSL substitution), it gets reevaluated at log time.
• max_cpu_time — explicitly set the max cputime for a single execution of the executable. Units are minutes. The value goes through an atoi() conversion to get an integer. If the GRAM scheduler cannot set cputime, an error is returned.
• max_memory — explicitly set the max amount of memory for a single execution of the executable. Units are Megabytes. The value goes through an atoi() conversion to get an integer. If the GRAM scheduler cannot set maxMemory, an error is returned.
• max_time — the max walltime or cputime for a single execution of the executable. Whether walltime or cputime gets used is picked by the GRAM scheduler being interfaced. Units are minutes. The value goes through an atoi() conversion to get an integer.
• max_wall_time — explicitly set the max walltime for a single execution of the executable. Units are minutes. The value goes through an atoi() conversion to get an integer. If the GRAM scheduler cannot set walltime, an error is returned.
• min_memory — explicitly set the minimum amount of memory for a single execution of the executable. Units are Megabytes. The value goes through an atoi() conversion to get an integer. If the GRAM scheduler cannot set minMemory, an error is returned.
• project — target the job to be allocated to a project account as defined by the scheduler at the defined (remote) resource.
• proxy_timeout — obsolete and ignored. Now a job-manager-wide setting.
• queue — target the job to a queue (class) name as defined by the scheduler at the defined (remote) resource.
• remote_io_url — writes the given value (a URL base string) to a file, and adds the path to that file to the environment through the GLOBUS_REMOTE_IO_URL environment variable. If this is specified as part of a job restart RSL, the job manager updates the file’s contents. This is for jobs that want to access files via GASS, but the URL of the GASS server changed because of a GASS server restart.
• restart — start a new job manager, but instead of submitting a new job, start managing an existing job. The job manager searches for the job state file created by the original job manager. If it finds the file and successfully reads it, it becomes the new manager of the job, sending callbacks on status and streaming stdout/err if appropriate. It fails if it detects that the old jobmanager is still alive (via a timestamp in the state file). If stdout or stderr was being streamed over the network, new stdout and stderr attributes can be specified in the restart RSL and the jobmanager streams to the new locations (useful when output is going to a GASS server started by the client that’s listening on a dynamic port, and the client was restarted). The new job manager returns a new contact string that should be used to communicate with it. If a jobmanager is restarted multiple times, any of the previous contact strings can be given for the restart attribute.
• rsl_substitution — a list of values that can be substituted into other rsl attributes' values through the $(SUBSTITUTION) mechanism.
• save_state — causes the jobmanager to save its job state info to a persistent file on disk. If the job manager exits or gets suspended, the client can later start a new job manager that continues monitoring the job.
• savejobdescription — save a copy of the job description to $HOME. [Default: no]
• scratch_dir — location to create a scratch subdirectory in. A SCRATCH_DIRECTORY RSL substitution gets filled with the name of the directory that is created.
• stderr — name of the remote file to store the standard error from the job. If the value is a GASS URL, the standard error from the job gets transferred dynamically during the execution of the job. There are two accepted forms: a single destination: stderr = URL, or a sequence of destinations: stderr = (DESTINATION) (DESTINATION). In the latter case, the DESTINATION may itself be a URL or a sequence of an x-gass-cache URL followed by a cache tag. [Default: /dev/null]
• stderr_position — where in the file remote standard error streaming should be restarted from. Must be 0.
• stdin — name of the file used as standard input for the executable on the remote machine. If the value is a GASS URL, the file gets transferred to the remote gass cache before the job runs, then removed after the job terminates. [Default: /dev/null]
• stdout — name of the remote file to store the standard output from the job. If the value is a GASS URL, the standard output from the job gets transferred dynamically during the execution of the job. There are two accepted forms: a single destination: stdout = URL, or a sequence of destinations: stdout = (DESTINATION) (DESTINATION). In the latter case, the DESTINATION may itself be a URL or a sequence of an x-gass-cache URL followed by a cache tag. [Default: /dev/null]
• stdout_position — where in the file remote output streaming should be restarted from. Must be 0.
• two_phase — use a two-phase commit for job submission and completion. The job manager responds to the initial job request with a WAITING_FOR_COMMIT error. It then waits for a signal from the client before doing the actual job submission. The integer you supply is the number of seconds the job manager should wait before timing out. If the job manager times out before receiving the commit signal, or if a client issues a cancel signal, the job manager cleans up the job’s files and exits, sending a callback with the job status as GLOBUS_GRAM_PROTOCOL_JOB_STATE_FAILED. After the job manager sends a DONE or FAILED callback, it waits for a commit signal from the client. If it receives one, it cleans up and exits as usual. If it times out and save_state was enabled, it leaves all of the job’s files in place and exits (assuming the client is down and will attempt a job restart later). The timeoutvalue can be extended via a signal. When one of the following errors occurs, the job manager does not delete the job state file when it exits: GLOBUS_GRAM_PROTOCOL_ERROR_COMMIT_TIMED_OUT, GLOBUS_GRAM_PROTOCOL_ERROR_TTL_EXPIRED, GLOBUS_GRAM_PROTOCOL_ERROR_JM_STOPPED, GLOBUS_GRAM_PROTOCOL_ERROR_USER_PROXY_EXPIRED. In these cases, it can not be restarted, so the job manager will not wait for the commit signal after sending the FAILED callback.
• username — verify that the job is running as this user.

👑 AUTHOR 👑

Copyright © 1999-2016 University of Chicago

and that's the whole page, bestie. this was Grid Community Toolkit 6, dated 03/31/2018, and the page is RSL(5). slay. 💖✨