Submit Command Reference

AutoDump 
Command
Cpus
Criteria 
DependOn 
DoneCommand 
DoneMail 
Frames
ImgCommand 
LogDir
LogFlags 
NeverCpus
Notes
Priority
Ram
State
Title
WaitFor

Dump job on completion
Criteria for matching hosts
Render script to execute
Hosts (or hostgroups) to use for rendering
Command to run when job done
Send mail when job done
Frame ranges to render
Directory for log files
Controls logfile behavior
Cpus to never use for rendering
Job notes
Default priority
Ram job expects to use (max)
Initial state for job
Title for job
Wait for other jobs to complete

AutoDump (rush -autodump)

Enables a job to automatically dump itself. Can be any of:
 

autodump off autodump done autodump donefail

# Don't autodump; job remains when frames are done. # Job dumps itself when all frames are DONE # Job dumps itself If all frames are DONE or FAIL

In the case of 'autodump done', the job will not dump if there were any FAIL frames. If you want it to dump anyway, then use 'autodump donefail'.

Command (rush -command)

Sets the command (and optional arguments) that is executed on a per frame basis on all the remote machines.

Usually, this is always an absolute NFS path to the Render Script.

It can, however, be an absolute path to any executable or script, provided it returns rush exit codes (0,1,2), and knows how to access RUSH_FRAME to determine which frame its working on.

    command /job/MARINER/DIVE/rush/render-script 640 480

WinNT Note - Use UNC paths for the absolute path to the render script. This prevents problems with inconsistently mapped drive letters. A UNC example: command //server-01/large6/rush/bin/myrender.bat 640 480

This command tells rush which remote machines are to be used during rendering. It is an error not to specify any cpus.

When specifying a cpu, your are telling rush at least three things:

• The name of the host (or hosts when host groups are specified)
• The number of cpus to use on that host (or hosts)
• The job's priority to use when running on that host

The number of cpus defaults to 1 if unspecified.

If unspecified, the priority value defaults to the Priority value for the job.

Priority is a value between 1 and 999, with 999 being highest priority, 1 being lowest. Priority values can be followed by optional flags 'k' and/or 'a'. See Priority Description for a full description of how the priority mechanism works.

 

cpus pabst cpus pabst=4 cpus pabst=4@900 cpus pabst=4@900,2@500     cpus +any=10@1 cpus +farm=50@1 cpus pabst=4/2

# 1 cpu on pabst, default priority # 4 cpus on pabst, default priority # 4 cpus at 900 priority # 4 cpus at 900 priority, 2 cpus at 500 # use up to 10 cpus on 'any available machine' # use up to 50 machines on the 'farm' host group # 4 cpus, 2 cpus per frame (threading)

Note that '+any' and '+farm' are Host Group specifications which represent more than one hostname. "+any" is a special host group that includes all machines on the network.

Host Groups are configured by your sysadmin in the Hosts file.

Criteria (rush -criteria)

Criteria contains a list of words separated by logical operators (&) and (|). The strings are configured by your systems administrator, and are to be values in the Criteria column of the  'rush -lah' reports.

[erco@howland] % rush -lah
IP               Hostname   Ram  Cpus Pri Criteria
192.168.10.3     rotwang    100  2    0   +any,linux,linux6.0,intel,+dante
192.168.10.2     how        256  2    0   +any,sgi,irix,irix6.2
192.168.10.1     nt         256  1    0   +any,winnt,+dante

When you specify hosts to render, any Criteria you specify will limit which machines your renders will run on; if the criteria you specify don't match a particular host, even if the host is specifically requested by a Cpus command, frames will be turned away from rendering on that machine.

For instance, if your job depends on using only linux machines or sgis running IRIX 6.2, you might submit your job with a criteria line that reads:
 

criteria    ( linux | irix6.2 )


The above presumes your sysadmin uses 'linux' and 'irix6.2' as qualifiers in the host list. If you need new criteria strings configured, ask your sysadmin to add them to the rush system's hosts file.

Only one Criteria command should appear in a submit script; multiple instances of the command are not cumulative.

Here are some more examples:

criteria ( linux | ( irix6 & octane ) )
criteria ( linux | irix6.2 )
criteria ( linux & !alpha )
criteria ( linux & alpha & carrera )    
criteria ( +any )
criteria ( !intel )

# Use linux machines OR irix6 octanes.
# Only linux machines OR  irix6.2 machines.
# Use only linux machines that are NOT dec-alphas.
# Use only linux dec-alphas built by Carrera.
# Use all available machines
# Use all machines that are NOT intel based machines.

Caveat: There is currently no default precedence for logical operators at this time; operators are simply parsed from left to right. So be sure to use parens to imply any kind of precedence, as shown above.

DependOn (rush -dependon)

Make the current job's frames depend on the completion of frames in other jobs first. This lets one setup a dependency tree of jobs.

When a job is submitted with 'dependon', all the frames in the job enter the 'Hold' state. (Frames in the 'Hold' state will not be rendered until switched back to the 'Que' state) As a particular frame in the jobs that are depended on enter the 'Done' state (ie. finish rendering successfully), it is then that the corresponding frame in the current job will switch from Hold to Que, allowing the frame to begin rendering, as resources become available.

You can have a job depend on several others, the only stipulations being that the dependon jobs:

• Must already be in the queue
• Must have been submitted from the same machine (ie. jobids must have the same hostname)
• Should have corresponding frames in the current job

Frames will *not* switch from Hold -> Que until *all* the jobs depended on have their corresponding frames in the Done state. Otherwise those frames will remain in the Hold state.

See Chaining Jobs for scripting techniques to do this. Example usage:

dependon   radius-445 radius-446

DoneCommand (rush -donecommand)

When a job dumps, after the 'framelist' and 'jobinfo' files are saved in the LogDir, the optional DoneCommand script can be executed. This command can be used to compress logfiles, or parse them for errors, or yield customized web page reports, etc.

This command is executed only once, on the job server.

If the done command is set to '-', or if donecommand is not specified at all, it will be disabled.

For the DoneCommand to be executed, the job must dump. For automatic invocation, you will need to have the AutoDump command enabled, for the job to dump when all the frames are done. If AutoDump is disabled, the only way the DoneCommand will execute, is if someone manually invokes 'rush -dump'.

DoneCommand scripts are passed the jobid in the RUSH_JOBID environment variable, so it's possible for the script to use rush(1) commands to query the job. Exit codes are currently ignored. The stdout and stderr output from the DoneCommand is writted to a file called 'done.log' in the LogDir.

#!/bin/csh -f # EXAMPLE 'DoneCommand' SCRIPT set $wwwreport = /somewhere/MYPROJECT/html/`logname`/jobreport.html # CREATE A CUSTOMIZED WEBPAGE REPORT set logdir = `dirname $RUSH_LOGFILE` cat $logdir/framelist | \ my_report_generator > $wwwreport # MAIL THE REPORT TO SOMEONE Mail -s "$RUSH_JOBID Html Report" `logname` < $wwwreport

The DoneCommand should avoid doing anything to the job that might make it continue running. Though possible, this would confuse someone manually trying to dump the job, only to find it requeuing itself.

donecommand - donecommand $cwd/cleanup

# Disable done commands # Setup script to run before job dumps itself

DoneMail (rush -donemail)

When a job completes, rush can be configured to send mail to a list of people using DoneMail. Only one DoneMail command should appear in a submit script; multiple instances of the command are not cumulative.

Arguments should all be valid email addresses. If more than one address needs to be specified, separate with commas. There should be no spaces in the list of addresses. Use '-' to disable sending completion mail (default). Some possible settings for DoneMail:

 

donemail  -                donemail  erco@netcom.com     donemail  fred,jack

# Mail disabled # Send mail to erco@netcom.com # Send mail to fred and jack

Keep in mind if LogDir is configured, framelist and jobinfo reports will be written into its directory, so sending mail might be redundant.

Frames (rush -af/-rf)

Defines the range(s) of frames to be rendered by this job. There can be several Frames commands in a submit script; they are cumulative.
 

frames  1-10 frames  100-150,2 frames  500 507 615

# Frames 1 thru 10 # Frames  100 thru 150 on twos # Frames  500, 507 and 615

Frame States. You can set the initial state for the frame on a per-frame basis. Possible frame state values are Done|Fail|Hold|Queue:
 

frames  1-5=Done       frames  6-10=Fail      frames  11-15=Hold     frames  16-20=Queue

# Frames 1 thru 5 in DONE state # Frames 6 thru 10 in FAIL state # Frames 11 thru 15 in HOLD state # Frames 16 thru 20 in QUEUE state (default)

Notes In Frames. On a per-frame basis, frames can contain notes, which show up in the last column of frame lists. Notes can be specified in the Frames command:
 

frames  1-10:Black          frames  11:Fade_up_on_sc17

# Notes for frames 1 thru 10  is "Black" # Frame 11 has note "Fade_up_on_sc17"

The above example creates a frame list that looks like:

    [erco@howland]% rush -lf
    STAT FRAME TRY HOSTNAME PID   START          ELAPSED  NOTES
    Que  0001  0   -        0     00/00,00:00:00 00:00:00 Black
    Que  0002  0   -        0     00/00,00:00:00 00:00:00 Black
    Que  0003  0   -        0     00/00,00:00:00 00:00:00 Black
    Que  0004  0   -        0     00/00,00:00:00 00:00:00 Black
    Que  0005  0   -        0     00/00,00:00:00 00:00:00 Black
    Que  0006  0   -        0     00/00,00:00:00 00:00:00 Black
    Que  0007  0   -        0     00/00,00:00:00 00:00:00 Black
    Que  0008  0   -        0     00/00,00:00:00 00:00:00 Black
    Que  0009  0   -        0     00/00,00:00:00 00:00:00 Black
    Que  0010  0   -        0     00/00,00:00:00 00:00:00 Black
    Que  0011  0   -        0     00/00,00:00:00 00:00:00 Fade_up_on_sc17

States and Notes. Frame states and notes specifications can appear together, e.g.:

    frames  1-5=Done:This_is_a_test

 
Caveat: In submit scripts, frame notes currently cannot contain spaces; use underbars instead.

ImgCommand (rush -imgcommand)

(New in rush 102.20c and up)
Optional.

This command sets up IRUSH to be able to display the rendered image when you double click on one of the frames in the 'Frames' report.

Normally, this should be an actual command that brings up one of your job's images in the background. The only difference being that you use %d or %04d in place of the frame number, eg:

    imgcommand ipaste -sx /job/MYSHOW/MYSHOT/images/foo.%04d.rgb

So if someone double clicks on frame 37 in an IRUSH report, IRUSH will invoke:

    ipaste -sx /job/MYSHOW/MYSHOT/images/foo.0037.rgb

..which will display frame 37 in the SGI 'ipaste' utility. All printf(3) style '%d' values are supported. Include any arguments you think are necessary in the imgcommand.

The image viewer command should background itself. If it doesn't, it will hang IRUSH until you exit the viewer. You can force the command to background itself in these platform specific ways:

• Unix: Append an '&' to the command. This will make it run in the background.

• Windows: Insert 'start /b ' before the image command. This will make the command run in the background. See the windows DOS utility 'start /?' for more info.

Examples:

 

imgcommand imgworks /job/images/att.%04d.sgi	# Unix: Invokes imgworks(1) to view the image. # (imgworks backgrounds itself; no need for '&')
imgcommand xv /job/images/att.%04d.sgi &	# Unix: Invokes 'xv' to view the image. # ('&' assures 'flip' runs in the background.)
imgcommand start /b flip //ntserver/images/att.%04d.sgi	# WINNT: Invokes 'flip' to view images. # 'start /b' assures it runs in the background
imgcommand -	# Disable image commands

LogDir (rush -logdir)

Sets the directory where logs containing the stdout/stderr of rendered frames are written to, one file per frame. The filenames are the four digit padded frame number for the rendered frame.

When a job is dumped, two other files appear in this directory;

• framelist -- The job's frame list (ie. 'rush -lf') at the time the job was dumped
• jobinfo -- The 'rush -ljf' report

The directory must exist relative to both the job server and all machines participating in rendering, and the directory must be read/writable by the user submitting the job.

logdir /jobs/myjob/logs  logdir -

# Logs are dumped in this directory # Disable log files

WinNT Note - Use a UNC path for the absolute path to the logdir. This prevents problems with inconsistently mapped drive letters. A UNC example: logdir //server-01/large6/rush/soft/logs

LogFlags (rush -logflags)

Sets optional flags that control how log files are created.

The default behavior is to overwrite frame logfiles, each time a frame renders.

KeepLast tells the system to always keep the previous logfile, if there is one. It does this by renaming the previous log to a ".old" file, before creating the new log for a running frame, similar to running the command:

mv logs/0055 logs/0055.old

KeepAll is similar to KeepLast, with the additional behavior that all 'previous' logs are kept; before a framelog is overwritten, it is concatenated to the .old file, similar to running:

cat logs/0055 >> logs/0055.old

Beware; if your logfiles are long, KeepAll will create significant use of disk space, since the logs will accumulate. A good reason to use KeepLast instead.

logflags -	# Logs are overwritten (Default)
logflags keepall	# Keep all logs; concatenate old logs in 0000.old
logflags keeplast	# Like 'keepall', but only keeps last log (don't concatenate)

NeverCpus (rush -an/-rn)

Sets hostnames that should never be used for rendering. Overrides any Cpus specifications, ensuring hosts are not used even if specified by name in the Cpus list. More than one NeverHosts command can appear in a Submit Script; multiple instances of the command are cumulative.

nevercpus tahoe rotwang   # Never use tahoe or rotwang for rendering

Notes (rush -notes)

Each job has a free form 'notes' field, which can be used for various purposes, such as passing informational notes to other programs, or possibly other users who will be taking over this job in a hand-off.
 

..
notes Please don't dump this job until you have visually
notes verified the matte transition at frames 205-219.
notes Call me at home if there are problems! -fred
..


Notes for the job appear in the 'rush -ljf' reports:

[erco@howland]% rush -ljf : : Elapsed: 00:00:00 Frames: 22 Cpus: rotwang=2@100k Cpus: how=3@100k Notes[0]: Please don't dump this job until you have visually Notes[1]: verified the matte transition at frames 205-219. Notes[2]: Call me at home if there are problems! -fred

Priority (rush -priority)

The 'priority' value is used when cpus commands don't specify a priority value, ie. 'cpus tahoe=4'. In such a case, the value set by 'priority' is used.

Example.

    priority 10
    :
    :
    cpus erie=2@100
    cpus tahoe=4
    cpus +any=10
    

See Priority Description for a description of how priority values work.

Ram (rush -ram)

All jobs must have a Ram value that tells the system how much memory each process is expected to use. Values are in MB, and are compared against the values shown in the Ram column of List All Cpus reports ('rush -lah').

While job is running, the configured Ram value is compared against the available ram on the remote processors. If the amount of ram your job wants is more than the remote machine has available, then the frame will not be started. This behavior prevents swapping the remote machines.
 

ram 128      # Only run on machines that have at least 128MB of ram available

State (rush -pause/-cont)

You can set the initial state for the job on submission. The only current option is to submit the job in the Pause state, to prevent the job from starting up right away.

    :
    state  Pause        # Submit job in paused state
    :

After you submit the job, the job will be in the paused state:

    [erco@howland]% rush -lj
    STATUS JOBID       TITLE        OWNER    %DONE BUSY NOTES 
    ------ ----------- ------------ -------- ----- ---- -----------
    Pause  how-857     THX/LOGO     erco     %0    0    Job paused.

Title (rush -title)

Each job has a free form 'Title' which appears in the job reports, audit logs, etc. Some shops use this information for billing purposes.

    title THX/LOGO

Here's an example report showing where the title might show up:

    [erco@howland]% rush -lj 
    STATUS JOBID       TITLE        OWNER    %DONE BUSY NOTES 
    ------ ----------- ------------ -------- ----- ---- ----------- 
    Run    how-857     THX/LOGO     erco     %0    0    00:00:05

Titles cannot contain spaces, and should be short (<15 characters) to prevent reports from loosing columnar formatting.

WaitFor (rush -waitfor)

Sets up the current job to wait for other jobs to dump. When the current job has 'waitfor' configured, it won't begin rendering frames until the jobids specified have dumped themselves. In this way, jobs can be chained together so that one waits for the other. See Chaining Jobs for scripting techniques to do this. Example usage:
 
waitfor   radius-445 radius-446

rush -ac <cpuspec..> [jobid..]

Add Cpus.
Adds cpus to the running job. Examples:

% rush -ac tahoe@300 # Add one cpu on tahoe at 300 priority % rush -ac tahoe=2@300 +farm=10@100k # Add two tahoe cpus, # 10 cpus in +farm hostgroup % rush -ac +any=10@10 # Add any 10 available cpus

See the Cpus submit command for more info. To remove cpus, see 'rush -rc'.

rush -af <framerange..> [jobid..]

Add Frames.
Adds frames to the current framelist. Adding frames that already exists yields an error. Example:

% rush -af 10-15 # Add frames 10 thru 15 to the current job % rush -af 20-25=Hold # Add frames 20 thru 25 in Hold state % rush -af 30-35:"To be done" # Add frames 30 thru 35, set Notes to "To be done" % rush -af 40-45=Done:"To be done" # Add frames 40 thru 45 in Done state with Notes

See Frames submit command for more info.

rush -an <hostname|+group..> [jobid..]

Add Nevercpus.
Prevents the job from rendering on the specified hosts. Example:

% rush -an tahoe +farm

See Nevercpus submit command for more info.

rush -autodump <off|done|donefail> [jobid..]

Automatic Dump.
Configures job to automatically dump when there are no more frames to render. See AutoDump submit command for more info.

rush -checkconf <filename>

(Administrative) Checks a rush.conf file for errors. Returns an exit code indicating success or failure; 0=ok, 1=error(s) found. Example:

    #!/bin/csh -f
    ###
    ### Script to edit the rush.conf file, and rdist it out
    ###
    set TMPFILE=/usr/tmp/rush.conf.$$
    cp /usr/local/rush/etc/rush.conf $TMPFILE
    vi $TMPFILE
    rush -checkconf $TMPFILE
    if ( $? ) then
        echo You lose, game over.
	set err=1
    else
	foreach i ( tahoe superior erie )
	    rdist -c $TMPFILE ${i}:/usr/local/rush/etc/rush.conf
	end
	set err=0
    endif
    rm -f $TMPFILE
    exit $err
    

rush -checkhosts <filename>

(Administrative) Checks a hosts file for errors. Returns an exit code indicating success or failure; 0=ok, 1=error(s) found.

rush -command 'cmd [args..]' [jobid..]

Set Render Command.
Change the command string being executed by a job. Example:

% rush -command '/bin/sleep 30' # change command to run 'sleep 30' % rush -command '/job/run/myrender' tahoe-21 tahoe-22   # change command for two jobs

Note that a full path to the command is normally required. Spaces are used to separate arguments, but the entire command and arguments must be quoted.

See also the submit script docs on Command for more info.

rush -cont [jobid..]

Continue Paused Job.
Continues a job that was paused with rush -pause.

rush -cp [jobid..] <.JobTid [..]> <@pri>

(New in 102.21a+)
Change Priority.
Changes priority for the cpus specified by 'JobTid' to the new priority '<@pri>'. JobTid values (Job Task IDs) can be found in the 'rush -lc' report.

Priorities can be changed while cpus are busy. If a busy cpu's priority is changed, the busy task(s) inherit the new priority, which is used for all subsequent scheduling and priority battles.

Example:

% rush -lc
CPUSPEC[HOST]        STATE       FRM  PID     JOBTID  PRI   ELAPSED  NOTES
+any=10@100[vaio]    Busy        0007 1030    131     100   00:01:45 
+any=10@100[vaio]    Busy        0008 1031    132     100   00:01:45 
+any=10@100[tahoe]   Busy        0004 19829   133     100   00:00:05 
+any=10@100[tahoe]   Busy        0005 19831   134     100   00:00:05 

% rush -cp .131 .132 @350k
vaio.21 +any=10@100: priority was 100, now 350k
vaio.21 +any=10@100: priority was 100, now 350k

% rush -lc
CPUSPEC[HOST]        STATE       FRM  PID     JOBTID  PRI   ELAPSED  NOTES
+any=10@100[vaio]    Busy        0007 1030    131     350k  00:02:03 
+any=10@100[vaio]    Busy        0008 1031    132     350k  00:02:03 
+any=10@100[tahoe]   Busy        0004 19829   133     100   00:00:28 
+any=10@100[tahoe]   Busy        0005 19831   134     100   00:00:28 

Caveats:
• Currently the CPUSPEC column does not reflect the change, though the effective priority (shown in the PRI column) does.

• GUIs (like IRUSH) make best use of this option, since they hide the mundane task of visually indexing JOBTIDs from the -lc report, and inserting dot prefixes on the rush command line.

rush -criteria 'criteria strings' [jobid..]

Job Criteria.
Set the criteria string for the job. Use '-' to specify no criteria.

See Criteria submit command for more info on how criteria is specified.

rush -dcatlog [host..]

Daemon cat(1) Log File.
View the rushd.log daemon on the local [remote] host.
• rush -dcatlog prints the current rushd.log (usually today's)
• rush -dcatoldlog prints the last rotated log (usually yesterday's).

Caveat: for reasons strange and unusual, all daemon 'catlog' output has a '>' prepended to each line.

rush -deltaskfu [..]

Delete Task, Force Unlink
(Administrative) Delete a task from a cpu server. Only root and the rush adminuser can use this command.

rush -dependon [-|depjobid[,..]]

Set Dependency On Other Jobs.
Sets new 'dependon' jobids for the current [specific] job. See the submit script docs on DependOn for more info on 'dependon'.

Read the examples carefully to avoid confusing jobid(s) to affect with new jobids for the dependon command; remeber to separate all 'dependon' jobids with commas instead of spaces.

CAVEATS

Setting 'dependon' to a new value disables all previous values (ie. clears them first).

Setting dependon to '-' will disable it, but you will have to manually un-Hold any frames manually.

All 'dependon' jobids must have the same hostname as the job being modified.

To differentiate between the new value for 'dependon', and the jobid(s) to be affected, the new value for 'dependon' must be a comma separated list of jobids with no spaces. Examples:

rush -dependon - # Disable all dependencies rush -dependon tahoe-37,tahoe-38, # Job now depends on 'tahoe-37' and 'tahoe-38'. # Trailing comma required rush tahoe-40 -dependon tahoe-37,tahoe-38, # tahoe-40 now depends on 'tahoe-37' and 'tahoe-38' rush tahoe-40 -dependon tahoe-37, # tahoe-40 now depends on job 'tahoe-37' # Trailing comma on tahoe-37 is required

See also, rush -waitfor.

rush -dexit [remotehost..]

Daemon Exit.
(Administrative) Tells a daemon to exit immediately via TCP. Acknowledges success. Only root and the rush adminuser can use this command.

rush -dexitnow [remotehost..]

Daemon Exit Now.
(Administrative) Tells daemon to exit immediately, via UDP. There is no acknowledge. Only root and the rush adminuser can use this command. Use only in case of emergency.

rush -dlog <flags> [remotehost..]

Daemon Debug Logging
(Administrative) Enables certain daemon debug logging. Only root and the rush adminuser can use this command.

Logging Flags These are flags that can be used with rush -dlog, rushd -d, and the rush.conf file's LogFlags. These flags can be combined to accumulate logging verbosity. All flags can be enabled by specifying 'a'.

a - all b - bump mechanism logging d - log duplicate/redundant receipt of packet drops e - events (time oriented, async) f - fork h - hostname lookups j - Log job submissions k - Log bumped/killed/usurped tasks l - Logical string evaluations o - connect()/open()/close()/bind()/socket() (low level) p - parse command line arguments, submit scripts m - memory calculations (RAM) during priority battles, etc n - network commands (udp/tcp) r - reboot management/transactions s - signals t - tcp u - udp w - 'waitfor' checks y - yp lookups C - class ToWords/FromWords F - File loading line-by-line debugging E - Errors not normally displayed (benign, but suspect) T - task/taskack transactions U - update (scheduling, priority mechanism, idle cpu management) R - Reaper msgs S - Server/Client context switches X - Random UDP message dropping -- TESTING ONLY!! ('a' does not affect this option, it must be specified)

rush -done <framerange|framestate..> [jobid..]

Done Frames.
Change frame(s) into the Done state for current [specific] job. If frames are running, they are killed and enter the 'Done' state on completion.

The frames to affect can either be specified as a frame range (ie. 1-100) or as a frame state, for which all frames matching that state will be changed. Examples:

% rush -done 1-100 # 'Done' frames 1 through 100 % rush -done fail # 'Done' all frames currently Fail % rush -done fail que    # 'Done' all frames currently Fail or Que

rush -donecommand [jobid..] <command|-|>

Set Job Done Command.
Changes the donecommand for the job. The donecommand is executed when the job is dumped.

Setting the done command to '-' will disable it. Examples:

% rush -donecommand "/bin/sleep 30"   # set donecommand to '/bin/sleep 30' % rush -donecommand "-" # disable donecommand

See also the submit script DoneCommand for more info.

rush -donemail [email[,email..]] [jobid..]

Set Job Done Mail.
Change who to send mail when job is done.

See DoneMail submit command for more info and examples.

rush -dump [jobid|user|user@host..]

Dump Job.
Dump the job. Busy frames are killed right away.

If no arguments are specified, the RUSH_JOBID variable is used to determine which job to dump.

If jobid(s) are specified, those jobs will be dumped.

If a user's name is specified, all jobs owned by that user on the local machine will be dumped. (eg. 'rush -dump fred')

In the case of user@host, all jobs owned by 'user' submitted to 'host' will be dumped. ie. 'rush -dump fred@tahoe' will dump all jobs owned by fred that were submitted to host tahoe.

rush -end [jobid..]

End Job.
Ends a job. Similar to rush -dump, but waits for running frames to finish. (ie. running frames are not killed.)

rush -fail <framerange|framestate..> [jobid..]

Fail Frames.
Change frame(s) into the Fail state for current [specific] job. If frames are running, they are killed and enter the 'Fail' state on completion.

The frames to affect can either be specified as a frame range (ie. 1-100) or as a frame state, for which all matching frames will be affected. Examples:

% rush -fail 1-100 # Fail frames 1 through 100 % rush -fail done # Fail all frames currently Done % rush -fail done hold    # Fail all frames currently Done or Hold

rush -fu [option]

Force User¹
The -fu flag overrides warnings pertaining to lack of permission to do an operation, because the user invoking it is not the owner of the job.

For instance, if you want to control another person's job, you might get an error, eg:

% rush -an vaio va-229 rush: va-229: you're not owner! % rush -an vaio va-229 -fu Add Neverhosts vaio # Attempt to add 'vaio' as a neverhost to someone's job # Fails because you're not the job's owner # Same command with -fu to force it.. # ..now it works!

See also the RUSH_FU environment variable.

Note: This feature may be disabled by the system administrator via the DisableFu flag in the Rush Configuration File.

¹ This acronym is rumored to have an alternate, pejorative expansion.

rush -getoff [remotehost]

Get Off My Machine.
Similar to 'rush -offline', but kills and requeues any currently running frames before taking the local [remote] machine offline.

rush -hold <framerange|framestate..> [jobid..]

Hold Frames.
Change frame(s) into the Hold state for current [specific] job. If frames are running, they are killed and enter the 'Hold' state on completion.

When a frame is in the Hold state, the frame will not be rendered, and a job will not autodump if there are any Hold frames in the frame list.

The frames to affect can either be specified as a frame range (ie. 1-100) or as a frame state, for which all matching frames will be affected. Examples:

% rush -hold 1-100 # Hold frames 1 through 100 % rush -hold fail # Hold all frames currently Fail % rush -hold fail done    # Hold all frames currently Fail or Done

rush -imgcommand '<command [args..]>' [jobid..]

Set Image Display Command
Used by IRUSH to determine the command to execute whenever the user double clicks on a frame in the IRUSH 'Frames' report. Normally, the command invoked should display the rendered image for that frame.

This should be a complete command to view an image in your favorite image viewer, with %d or %04d in place of the frame number.

The image viewing command must background itself, or you must force it by using '&' (unix), or 'start /b' (windows). Examples:

% rush -imgcommand 'xv /job/images/foo.%04d.sgi &'	# (Unix) Invoke 'xv' to view images
C:\> rush -imgcommand "start /b flip //nt/images/s1.%04d.png"	# (Windows) Invokes 'flip' in background to view images

See the ImgCommand submit command for more info.

rush -jobnotes '<notes>' [jobid..]

Set Job Notes.
Associates free form strings of 'job notes' to the current [specific] job, viewable in 'rush -ljf'. Notes must be quoted if it contains spaces.

See Notes submit command for more info.

rush -lac [-s secs] [-c count]

List All Cpus.
Lists the status of all rush cpus on the network. Report should come up quickly, even on large networks.

This report is useful in seeing which cpus are running who's jobs.

[-s secs] is an optional argument to specify the number of seconds to wait for responses from the remote hosts. Default is 5.

[-c count] is an optional argument to specify the number of times to automatically regenerate the report (for continuous updates). A value of 0 indicates infinite updating. Default is 1. Example report:

% rush -lac HOST OWNER JOBID TITLE FRM PRI PID ELAPSED tahoe - - - - - - Online tahoe - - - - - - Online superior erco vaio-50 FOREST_RENDER 0034 100 4026 00:10:01 superior erco vaio-50 FOREST_RENDER 0035 100 4027 00:10:02 superior tamu ibm4-208 AUTO_CAD 0101 300k 2031 02:43:31 superior tamu ibm4-208 AUTO_CAD 0102 300k 2035 02:43:31 erie erco vaio-50 FOREST_RENDER 0041 900k 14560 00:10:15 erie erco vaio-50 FOREST_RENDER 0042 900k 14561 00:10:15 michigan - - - - - - Offline michigan - - - - - - Offline michigan - - - - - - Offline michigan - - - - - - Offline *** NO RESPONSE FROM: *** ontario huron

Note that machines that did not respond are listed in the summary at the bottom of the report; all lines of these summaries are prefixed by '***'.

rush -lacf

List All Cpus Full.
Lists the full info of all rush cpus on the network. This report may take a while to run.

This report prints out more information than people usually need, this command is more intended to either be parsed by external scripts needing access to all information rush can provide, or for debugging.

rush -lah [hostname..]

List All Hosts.
Lists the Ram/Criteria configuration for all hosts in the render queue, which is loaded directly from the $RUSH_DIR/etc/hosts file. Example:

% rush -lah IP Hostname Ram Cpus MinPri Criteria 10.100.100.1 tahoe 512 2 0 +any,irix 10.100.100.2 superior 512 2 0 +any,irix,+dante 10.100.100.3 erie 512 2 0 +any,irix,+dante 10.100.100.4 ontario 512 2 0 +any,irix,+dante 10.100.100.5 vaio 128 1 0 +any,linux,intel 10.100.100.6 rotwang 128 1 100 +any,linux,intel

If hostname is specified, ie. 'rush -lah hostname', the output comes from the cache of the daemon running on the specified host; useful in determining hostname caching problems.

rush -lahf [hostname..]

List All Hosts Full.
Full hosts report for all hosts on local [remote] host.

This report prints out more information than people usually need, this command is more intended to either be parsed by external scripts needing access to all information rush can provide, or for debugging.

rush -laj

List All Jobs.
Queries all hosts on the network for what jobs are running.

% rush -laj STATUS JOBID TITLE OWNER %DONE %FAIL BUSY ELAPSED Run erie-167 100/340/master tamu %18 %0 8 01:15:28 Run erie-169 100/410/master tamu %75 %0 20 01:11:21 Run erie-170 100/390/master tamu %10 %34 4 01:10:44 Run erie-171 100/360/master tamu %10 %34 4 01:02:43 Run huron-454 W:090/440/all krement %100 %0 0 26:25:31 Run huron-457 W:090/425/master krement %100 %0 0 26:11:59 Run huron-476 W:090/425/master krement %100 %0 0 23:40:37 Run huron-519 Q:090/460/master krement %5 %0 8 00:21:27 Pause tahoe-76 230/250/layout_lock erco %2 %0 0 01:52:08 Run allek-790 qr2 tje %80 %1 4 06:58:20 Run allek-794 180/260/DAY tje %80 %1 2 06:38:48 Run allek-796 180/250/DAY tje %0 %0 0 06:34:21 Run allek-801 qr2 tje %0 %0 0 05:27:40 Run vaio-663 230/tdcheck/roomBC woz %80 %20 0 00:44:53

rush -lajf

List All Jobs Full.
Full job report for all jobs on the network. This report may take a while to run.

This report prints out more information than people usually need, this command is more intended to either be parsed by external scripts needing access to all information rush can provide, or for debugging.

rush -lc [jobid..]

List Cpus.
List cpus for current [specific] job. List a job's cpus, and what they're doing (or not doing). Example:

% rush -lc CPUSPEC[HOST] STATE FRM PID JOBTID ELAPSED NOTES huron=4@800k JobPass - - 178 00:00:00 This is a 'neverhost' huron=4@800k JobPass - - 179 00:00:00 This is a 'neverhost' huron=4@800k JobPass - - 180 00:00:00 This is a 'neverhost' huron=4@800k JobPass - - 181 00:00:00 This is a 'neverhost' +any=10@100[howland] Busy 0080 14733 165 00:00:01 +any=10@100[howland] Busy 0078 14731 166 00:00:01 +any=10@100[howland] Busy 0079 14732 167 00:00:01 +any=10@100[toronto] Idle/Nak - - 171 00:00:00 - +any=10@100[toronto] Idle/Nak - - 172 00:00:00 - +any=10@100[toronto] Idle/Nak - - 173 00:00:00 - +any=10@100[vaio] Busy 0074 4107 174 00:00:03 +any=10@100[vaio] Busy 0071 4100 175 00:00:03 +any=10@100[vaio] Busy 0072 4101 176 00:00:03 +any=10@100[vaio] Busy 0073 4106 177 00:00:03

rush -lcf [jobid..]

List Cpus Full.
A 'full' report for all of the current [specific] job's cpus.

This report prints out more information than people usually need, this command is more intended to either be parsed by external scripts needing access to all information rush can provide, or for debugging.

rush -lf [jobid..]

List Frames.
List Frames for current [specific] job. List a jobs frames to see what state they're in.

% rush -lf STAT FRAME TRY HOSTNAME PID START ELAPSED NOTES Run 5000 1 vaio 18092 02/26,02:15:40 00:00:21 Run 5001 1 vaio 18093 02/26,02:15:40 00:00:21 Run 5002 1 vaio 18100 02/26,02:15:50 00:00:11 Que 5003 0 - 0 00/00,00:00:00 00:00:00 Que 5004 0 - 0 00/00,00:00:00 00:00:00 Que 5005 0 - 0 00/00,00:00:00 00:00:00 Que 5006 0 - 0 00/00,00:00:00 00:00:00 Que 5007 0 - 0 00/00,00:00:00 00:00:00 Que 5008 0 - 0 00/00,00:00:00 00:00:00

The columns contain the following information:

Frame List Headings Heading Description Stat The status of the frame. Can be any of: Que - The frame is queued, ready to be run by an available cpu Run - The frame is busy running Done - The frame completed successfully Fail - The frame failed to run successfully (exit code was 1) Hold - The frame will not run until changed manually to Que The following are transitional states for frames, which you should only see for a short time: Strt - Frame just started to run, no process id yet Die - The frame is being killed, but hasn't gotten an exit code back yet Frame The frame number, padded 4 digits. Try The number of times this frame has been tried. Includes requeues due to exit(2), but does not include priority bumps. Hostname The name of the host that is running (or ran) the frame. PID The process id of the render script. This is also the process group leader for the frame's process hierarchy. Start The date/time the render began running. Elapsed The wall clock elapsed time in hours:minutes:seconds. Notes Free form notes text, set by the user's invocation of 'rush -notes frm:"text"'.

rush -lff [jobid..]

List Frames Full.
A 'full' report of all frame's state information.

This report prints out more information than people usually need, this command is more intended to either be parsed by external scripts needing access to all information rush can provide, or for debugging.

rush -lfi [jobid..]

List Frame Information.
List Frame info for current [specific] job, including average render times, ETAs, percent Busy/Done/Fail, etc. Example:

% rush -lfi vaio-139 Jobid State Total Perc Average Average ETA ------------ ----- ----- ---- ---------- ------------------------ vaio-139 Que 7 %69 - - vaio-139 Run 1 %10 - - vaio-139 Done 2 %20 00:32:16 Thu Sep 28 00:41:43 2000 vaio-139 Fail 0 %0 - - vaio-139 Hold 0 %0 - -

Some description of the average columns:

• Average
  The average render times. This is the sum of all the Done frames' render times divided by the total done frames.

• Average ETA
  This is the estimated time of completion for the job, based on the average render time for frames rendered successfully so far vs. the wall clock time spent running the job. eg:

  oldest_start = "The oldest start time for all Done frames" recent_end = "Most recent end time for all Done frames" time_spent = ( recent_end - oldest_start ) time_per_frame = time_spent / total_done_frames time_to_go = time_per_frame * ( total_que + total_hold )

Warning: the ETA is meant for ball park estimates only, and is not meant to be taken literally.

rush -lj [remotehost..]

List Jobs.
Shows all jobs running on the local [remote] host.

[you@erie] % rush -lj STATUS JOBID TITLE OWNER %DONE %FAIL BUSY ELAPSED Run erie-167 100/340/master tamu %18 %0 8 01:15:28 Run erie-169 100/410/master tamu %75 %0 20 01:11:21 Run erie-170 100/390/master tamu %10 %34 4 01:10:44 Run erie-171 100/360/master tamu %10 %34 4 01:02:43 [you@erie] % rush -lj tahoe STATUS JOBID TITLE OWNER %DONE %FAIL BUSY ELAPSED Run tahoe-5 100/540/master izzie %25 %0 4 00:30:01 Run tahoe-6 100/540/comp izzie %25 %0 4 00:30:02 Run tahoe-10 100/640/master izzie %10 %0 4 00:22:48 Run tahoe-11 100/640/comp izzie %12 %0 4 00:22:49

The columns contain the following information:

Job Report Headings Heading Description Status The status of the job. Can be any of: Wait - The job is waiting for another job to finish (WaitFor, -waitfor) Run - The job is available to run frames Pause - The job has been paused with -pause The following are transitional states for the job, which you should only see for a short time: End - the job was ended with -end Dump - the job was dumped with -dump Done - all frames done, about to run DoneCommand, -donecommand DoneCmd - the configured DoneCommand is running Remove - about to be removed from the system Jobid The job's jobid. Title The job's title (Title, -title). Owner The user that submitted the job. %Done The percentage of frames that are in the Done state. %Fail The percentage of frames that are in the Fail state. Busy The number of frames currently in the Run state. Elapsed The elapsed time in HH:MM:SS since the job started running. This field may also contain the messages 'Job paused' or 'Wait for other jobs'.

rush -ljf [jobid..]

List Jobs Full.
Lists all jobs running on the local [remote] host, showing 'full information' in a multi-line format.

This report prints out more information than people usually need, this command is more intended to either be parsed by external scripts needing access to all information rush can provide, or for debugging.

rush -log <framerange..> [jobid..]

View Frame Error Logs.
Print the frame logs for the specified frame range. Using the job's 'logdir' value, prints the logs found in that directory for the frames you specify. eg:

% rush -log 1-10,2 20   # view logs for frms #1-10 on 2s, and frm #20

rush -logdir pathname [jobid..]

Log Directory.
Changes the job's log directory, where frame log files are written to.

This does not affect commands that are already running or have run. ie. old logs are not moved to the new location, or renamed on the fly.

When changing the logdir with -logdir, no checks are made to see if 'path' is a valid directory.

See LogDir for more information.

rush -logflags <-|keeplast|keepall> [jobid..]

Log Flags.
Changes the log flags for the job. Examples:

rush -logflags - # Logs are overwritten (Default) rush -logflags keepall # Keep all logs; concatenate old to *.old (eg. 0012.old) rush -logflags keeplast # Like 'keepall', but only keeps last log (don't concatenate)

See LogFlags for more information.

rush -notes <framerange>:'notes..' [jobid..]

Frame Notes.
Set Notes for frame(s) on current [specific] job. These notes will show up in the right most column of 'rush -lf' reports. Examples:

rush -notes 155:"license error"   # set notes for frame 155 to 'license error' rush -notes 200-250:"redo" # set notes for frames 200 thru 250 to "redo"

rush -offline [remotehost|+group..]

Offline My Machine.
Offline the local [remote] daemon.

Lets frames that are already rendering complete before taking the processors offline. Once offline, no new frames will be started.

'rush -offline' is similar to 'rush -getoff', differing only in that -offline allows any currently rendering frames to complete before taking the processors offline. 'rush -getoff' will bump any running renders, freeing up the processors right away. The bumped frames will be requeued.

Examples of using 'rush -offline':

rush -offline   # offline all cpus on local host rush -offline tahoe # offline all of tahoe's cpus rush -offline +farm   # offline the entire render farm

To return processors to the online state, use rush -online.

rush -online [remotehost|+group..]

Online My Machine.
Online the local [remote] daemon. Frames will be allowed to start running on the host.

To take hosts offline, use either rush -offline or rush -getoff.

rush -pause [jobid..]

Pause Job.
Pause the current [specific] job. Busy frames will be allowed to finish, no new frames will be started.

To continue a job from pause, use rush -cont.

rush -ping [remotehost|+group..]

Ping Rush Daemon.
(Administrative) Pings the local [remote] daemon to see if it's running, and what it's doing.

rush -priority [jobid..]

Change Default Job Priority.
Changes the default priority for the job, which affects all 'cpus' specifications that did not indicate priority values (and therefore used the default priority).

Example. If a job submitted the following 'cpus' specifications:

    priority 10
    :
    :
    cpus erie=2@100
    cpus tahoe=4
    cpus +any=10
    

..this would create a job with 2 cpus on erie at a priority of 100, and all other cpus at a priority of 10.

Changing this job later with 'rush -priority 20' would cause all cpus (except erie, which specified a priority) to change their priorities to 20.

See the Priority submit command for setting the initial default priority.
See Priority Description for a description of how priority values work.

rush -que <framerange|framestate..> [jobid..]

Re-Queue Frames.
Change frame(s) into the Que state for current [specific] job. If frames are running, they are killed and enter the 'Que' state on completion.

The frames to affect can either be specified as a frame range (ie. 1-100) or as a frame state, for which all frames matching that state will be changed. Examples:

% rush -que 1-100 # Que frames 1 through 100 % rush -que fail # Que all frames currently Fail % rush -que fail done # Que all frames currently Fail or Done

rush -ram <ramval> [jobid..]

Set Job's Ram Use.
Sets the Ram use (in MB) for the job. See Ram submit command for more info.

rush -rc <cpuspec|tidspec|hostname> [jobid..]

Remove Cpu.
Remove Cpu from cpu list of current [specific] job. If the cpus being removed are busy running frames, the frames are killed and re-submitted elsewhere.

Cpus can be removed in one of several ways:

• Individually by the JOBTID number, eg. rush -rc .32
• By hostname, eg. rush -rc tahoe
• By a particular cpu specification as shown in the 'rush -lc' report, eg. rush -rc tahoe=4@200

To remove a cpu via 'JOBTID' values (eg. 'rush -rc .334') you must precede each value with a period. When you delete by JOBTID, you are deleting single cpus from the 'rush -lc' report. Note this report includes the JOBTID values so you can see which values to delete. If the cpu you delete is part of a larger specification, (eg. tahoe=4@12), then the cpu count for the spec will be modified, the cpu count in that spec will be decremented as well (eg. tahoe=3@12)

If you remove a hostname (eg. 'rush -rc tahoe') then all cpu specifications that have that host name (eg. tahoe=3@100) will be removed. Also, any host groups that expand to include that host will have that host removed from the expansion (eg. +any=3@100, which includes tahoe).

If you remove a cpu specification (eg. 'rush -rc +any=3@100'), it must match character-for-character the entry shown in the 'rush -lc' report for the job:

% rush -ac tahoe@100 # Add a cpu. % rush -rc tahoe@100 # Now try to remove it 'tahoe@100' no such cpu specification # FAILED: need to use spec shown in 'rush -lc' % rush -lc # Look at 'rush -lc' report CPUSPEC STATE FRM PID ELAPSED .. tahoe=1@100 Run 0002 26747 00:00:11 .. # More complete specification in report. % rush -rc tahoe=1@100 # Remove using spec shown in report 'tahoe=1@100' removed. # It works

rush -reserve <cpuspec> [ramval]

Reserve Cpus.
Reserves cpus by creating a 'dummy' job that holds the cpus. The job's title will be RESERVE. Reservation jobs are like any other; to remove a reservation, dump the job. To change the reservation, you can use IRUSH or the usual rush commands like -ac/-rc to modify the job.

'cpuspec' indicates which processors are reserved, and at what priority. It is an error not to include a priority value in the cpuspec.

Making a reservation at a priority of '500' will prevent jobs with priorities less than 500, but yields to jobs higher than 500k. If you make your reservation include the 'k' flag, it will also bump any renderings that are running on your machine that are lower than 500 priority. See Priority Description for more info on how rush priorities work.

As an example of reserving cpus on your workstation, lets assume you sit at a dual proc workstation called 'tahoe':

• To reserve both processors of your dual proc workstation at a priority of '500', use:

  % rush -reserve tahoe=2@500k     # Reserve both cpus at 500k priority

• To submit a job that actually renders on your own workstation, just submit with a cpu specification that requests your workstation at a priority higher than your reservation with the 'kill' flag, eg:

  tahoe=1@510k         # Request one cpu on tahoe

• To get both cpus, just request both as you normally would:

  tahoe=2@510k         # Request both cpus on tahoe

• To remove the reservation for your machine, simply dump the reservation job.

• To prevent all jobs from rendering on your workstation, even your own, make your reservation at a priority of 999. Or just use 'rush -offline' and/or 'rush -getoff'.

The optional 'ram value' allows one to reserve an amount of ram per processor. This is useful on multiproc machines where you want to prevent large jobs from rendering on the few processors left unreserved. Increasing the ram value you reserve will decrease the size of jobs rush will allow to run on the unused processors.

If 'cpuspec' doesn't include the number of processors, one processor is assumed. If 'ramval' is unspecified, a value of '1' is assumed.

rush -reserve tahoe@998 # Reserve 1 cpu on tahoe@998 rush -reserve tahoe=2@998 128 # Reserve 2 cpus @998, 128MB of ram to each rush -reserve tahoe=2@500 128 # Reserve 2 cpus @500, 128MB of ram to each

rush -reorder <framerange..> [jobid..]

Reorder Frames.
Reorders frames in the frame list to the new order specified. <framerange> specifies the new order of the frames in the frame list. Several frame ranges can be specified. Unspecified frames are simply left alone.

Changing the order of the framelist affects the order frames are rendered, since frames are issued from the top of the list, down.

Example. If you have a job with 10 frames in the frame list in normal 1 thru 10 order, you can use 'rush -reorder' to get different orderings, such as these:

rush -reorder 10-1 # becomes 10 9 8 7 6 5 4 3 2 1 rush -reorder 1-10,2 2-10,2 # becomes 1 3 5 7 9 2 4 6 8 10

rush -rf <framerange..> [jobid..]

Remove Frames.
Removes frames from the frame list of the current [specific] job.

rush -rn <hostname|+group..> [jobid..]

Remove Neverhosts.
Remove Neverhosts for current [specific] job.

rush -rotate [remotehost|+group..]

Rotate Daemon Log File.
(Administrative) Rotate daemon logs on local [remote] host. Can be used in crontab scripts to rotate logs to parse output.

Logs can be automatically rotated with the LogRotateHour command in the rush.conf file.

Only root and the rush adminuser can use this command.

rush -status [-s secs] [-c count] [remhost|+hostgroup..]

Status Of Host.
(Administrative) 'rush -status' quickly reports the status of jobs and cpus on the local [remote] hosts.

Commonly used as 'rush -status +any'.

Output is intended for other programs to parse and regenerate.

Optionally, a continuously updating report can be generated, where [-c count] specifies the number of updates, and [-s secs] specifies the seconds delay between each report. If -c is zero, updating is continuous.

The output contains several records of information for each host, one record per line. Host records start with an 'h' record, and terminate with a line of '---'.

4 different types of data records are possible. Data record types are defined by the first character in each record line, and can be one of:

    h - hostname header. Leads off records for the specified host.
    d - daemon information. Info about the running daemon.
    j - job information. One line per job.
    p - processor status. One line per processor. 
    

Each record has its own fields:

    h <hostname>
    d <sequence-id> <daemon> <version> <PID=pid> <online state> <jobs> <busy procs> <total procs>
    j <owner> <jobid> <job title> <job state> <elapsed> <percent done> <percent fail> <# frms busy>
    p <owner> <jobid> <job title> <frame> <priority> <pid> <elapsed>
    

rush -submit [remotehost]

Submit Job.
Submits a job to be managed by the local [remote] job server. Optional [remotehost] can be specified, to make the remotehost the job server.

rush -tasklist [remotehost..]

Task List.
List scheduled tasks on local [remote] cpu server. This is the scheduler's sorted list of tasks wanting to run on the host in question.

Tasks are sorted in the order they will be executed; the top most task is the next one to be rendered.

Tasks that are busy are sorted to the bottom. Tasks that were denied by either the job, or by cpu criteria are also sorted to the bottom.

Tasks are sorted into 'groups' of the same priority, and will round robin.

rush -title <text> [jobid..]

Job Title.
Set title for current [specific] job. For more information, see Title.

rush -trs

Template Render Script.
Prints the template render script on stdout. This can be redirected to a file, to quickly create a working script, which should then be customized using a text editor.
 
% rush -trs > render_me
% chmod +x render_me
% vi render_me
 
You will at least need to setup the render commands (the '### YOUR RENDER COMMAND(S) HERE' section) at minimum.

Caveat; the template render script can be modified and customized by the sysadmin via $RUSH_DIR/etc/templates.

rush -try <count> <framerange..> [jobid..]

Set Try Count.
Change the 'Try' count for the frames specified.

A 'try count' is maintained for each frame in a job's frame list. This value is shown in the 'Try' column of 'rush -lf' reports, and is passed to render scripts via the $RUSH_TRY environment variable.

% rush -lf STAT FRAME TRY HOSTNAME PID START ELAPSED NOTES Done 0001 4 superior 4144 10/04,03:29:10 00:00:18 Done 0002 4 tahoe 4160 10/04,03:29:30 00:00:16 Done 0003 4 placid 4163 10/04,03:29:47 00:00:16 Done 0004 6 huron 4168 10/04,03:30:04 00:00:16 Done 0005 4 finger 4171 10/04,03:30:21 00:00:16 % rush -try 0 1-5 0001: tries was 4, now 0 0002: tries was 4, now 0 0003: tries was 4, now 0 0004: tries was 6, now 0 0005: tries was 4, now 0 % rush -lf STAT FRAME TRY HOSTNAME PID START ELAPSED NOTES Done 0001 0 superior 4144 10/04,03:29:10 00:00:18 Done 0002 0 tahoe 4160 10/04,03:29:30 00:00:16 Done 0003 0 placid 4163 10/04,03:29:47 00:00:16 Done 0004 0 huron 4168 10/04,03:30:04 00:00:16 Done 0005 0 finger 4171 10/04,03:30:21 00:00:16

rush -tss

Template Submit Script.
Prints a template submit script on stdout. This can be redirected to a file, to quickly create a working script, which should then be customized using a text editor.
 
 
% rush -tss > submit_me
% chmod +x submit_me
% vi submit_me
 
You will, for instance, need to customize the 'command', 'title', 'cpus' and 'ram' values at minimum.

Caveat; the template submit script can be modified and customized by the sysadmin via $RUSH_DIR/etc/templates.

rush -uping [-c count] [remotehost..]

UDP Ping.
(Administrative) UDP Ping the local [remote] daemon. Useful for checking for UDP packet dropping. Optional argument '-c' can set the number of udp transmissions to send to the remote.

rush [jobid] -waitfor [-|waitjobid,[..,..]]

Wait For Other Jobs.
Sets new 'waitfor' jobids for the current [specified] job. See the submit script docs on WaitFor for more info on 'waitfor'.

Read the examples carefully to avoid confusing jobid(s) to affect with new jobids for the waitfor command; remeber to separate all 'waitfor' jobids with commas instead of spaces.

CAVEATS

Setting 'waitfor' to a new value disables all previous values (ie. clears them first).

Setting waitfor to '-' will disable the job from waiting for anything.

All 'waitfor' jobids must have the same hostname as the job being modified.

To differentiate between the new value for 'waitfor', and the jobid(s) to be affected, the new value for 'waitfor' must be a comma separated list of jobids with no spaces. Examples:

rush -waitfor -	# Disable all waitfor's
rush -waitfor tahoe-37,tahoe-38,	# Job waits for 'tahoe-37' and 'tahoe-38' to dump
rush tahoe-40 -waitfor tahoe-37,tahoe-38,	# tahoe-40 now waits for 'tahoe-37' and 'tahoe-38' to dump
rush tahoe-40 -waitfor tahoe-37,	# tahoe-40 now waits for 'tahoe-37' to dump # Trailing comma on tahoe-37 is important!

See also, rush -dependon.