Name
condor_submit - Queue jobs for execution under Condor
Synopsis
condor_submit [ -verbose ] [ -unused ] [ -name schedd_name ] [ -remote
schedd_name ] [ -pool pool_name ] [ -disable ] [ -password passphrase ]
[ -debug ] [ -append command ... ] [ -spool ] [ -dump filename ] [
submit description file ]
Description
condor_submit is the program for submitting jobs for execution under
Condor. condor_submit requires a submit description file which
contains commands to direct the queuing of jobs. One submit description
file may contain specifications for the queuing of many Condor jobs at
once. A single invocation of condor_submit may cause one or more
clusters. A cluster is a set of jobs specified in the submit
description file between queue commands for which the executable is not
changed. It is advantageous to submit multiple jobs as a single cluster
because:
* Only one copy of the checkpoint file is needed to represent all
jobs in a cluster until they begin execution.
* There is much less overhead involved for Condor to start the next
job in a cluster than for Condor to start a new cluster. This can
make a big difference when submitting lots of short jobs.
Multiple clusters may be specified within a single submit description
file. Each cluster must specify a single executable.
The job ClassAd attribute ClusterIdidentifies a cluster. See specifics
for this attribute in the Appendix on page .
Note that submission of jobs from a Windows machine requires a stashed
password to allow Condor to impersonate the user submitting the job. To
stash a password, use the condor_store_cred command. See the manual
page at page for details.
See section for the commands that may be placed in the submit
description file to direct the submission of a job.
Options
-verbose
Verbose output - display the created job ClassAd
-unused
As a default, causes no warnings to be issued about user-defined
macros not being used within the submit description file. The
meaning reverses (toggles) when the configuration variable
WARN_ON_UNUSED_SUBMIT_FILE_MACROSis set to the nondefault value of
False. Printing the warnings can help identify spelling errors of
submit description file commands. The warnings are sent to stderr.
-name schedd_name
Submit to the specified condor_schedd . Use this option to submit to
a condor_schedd other than the default local one. schedd_name is
the value of the NameClassAd attribute on the machine where the
condor_schedd daemon runs.
-remote schedd_name
Submit to the specified condor_schedd , spooling all required input
files over the network connection. schedd_name is the value of the
NameClassAd attribute on the machine where the condor_schedd daemon
runs. This option is equivalent to using both -name and -spool .
-pool pool_name
Look in the specified pool for the condor_schedd to submit to. This
option is used with -name or -remote .
-disable
Disable file permission checks.
-password passphrase
Specify a password to the MyProxy server.
-debug
Cause debugging information to be sent to stderr, based on the value
of the configuration variable SUBMIT_DEBUG.
-append command
Augment the commands in the submit description file with the given
command. This command will be considered to immediately precede the
Queue command within the submit description file, and come after all
other previous commands. The submit description file is not
modified. Multiple commands are specified by using the -append
option multiple times. Each new command is given in a separate
-append option. Commands with spaces in them will need to be
enclosed in double quote marks.
-spool
Spool all required input files, user log, and proxy over the
connection to the condor_schedd . After submission, modify local
copies of the files without affecting your jobs. Any output files
for completed jobs need to be retrieved with condor_transfer_data .
-dump filename
Sends all ClassAds to the specified file, instead of to the
condor_schedd .
submit description file
The pathname to the submit description file. If this optional
argument is missing or equal to ‘‘-’’, then the commands are taken
from standard input.
Exit Status
condor_submit will exit with a status value of 0 (zero) upon success,
and a non-zero value upon failure.
Examples
* Submit Description File Example 1: This example queues three jobs
for execution by Condor. The first will be given command line
arguments of 15 and 2000 , and it will write its standard output to
foo.out1. The second will be given command line arguments of 30 and
2000 , and it will write its standard output to foo.out2. Similarly
the third will have arguments of 45 and 6000 , and it will use
foo.out3for its standard output. Standard error output (if any) from
all three programs will appear in foo.error.
####################
#
# submit description file
# Example 1: queuing multiple jobs with differing
# command line arguments and output files.
#
####################
Executable = foo
Universe = standard
Arguments = 15 2000
Output = foo.out1
Error = foo.err1
Queue
Arguments = 30 2000
Output = foo.out2
Error = foo.err2
Queue
Arguments = 45 6000
Output = foo.out3
Error = foo.err3
Queue
* Submit Description File Example 2: This submit description file
example queues 150 runs of program foo which must have been compiled
and linked for Sun workstations running Solaris 8. Condor will not
attempt to run the processes on machines which have less than 32
Megabytes of physical memory, and it will run them on machines which
have at least 64 Megabytes, if such machines are available. Stdin,
stdout, and stderr will refer to in.0, out.0, and err.0for the first
run of this program (process 0). Stdin, stdout, and stderr will
refer to in.1, out.1, and err.1for process 1, and so forth. A log
file containing entries about where and when Condor runs, takes
checkpoints, and migrates processes in this cluster will be written
into file foo.log.
####################
#
# Example 2: Show off some fancy features including
# use of pre-defined macros and logging.
#
####################
Executable = foo
Universe = standard
Requirements = Memory >= 32 && OpSys == "SOLARIS28" && Arch
=="SUN4u"
Rank = Memory >= 64
Image_Size = 28 Meg
Error = err.$(Process)
Input = in.$(Process)
Output = out.$(Process)
Log = foo.log
Queue 150
* Command Line example: The following command uses the -append
option to add two commands before the job(s) is queued. A log file
and an error log file are specified. The submit description file is
unchanged.
condor_submit -a "log = out.log" -a "error = error.log" mysubmitfile
Note that each of the added commands is contained within quote marks
because there are space characters within the command.
* periodic_removeexample: A job should be removed from the queue, if
the total suspension time of the job is more than half of the run
time of the job.
Including the command
periodic_remove = CumulativeSuspensionTime >
((RemoteWallClockTime - CumulativeSuspensionTime)
/ 2.0)
in the submit description file causes this to happen.
General Remarks
* For security reasons, Condor will refuse to run any jobs submitted
by user root (UID = 0) or by a user whose default group is group
wheel (GID = 0). Jobs submitted by user root or a user with a
default group of wheel will appear to sit forever in the queue in an
idle state.
* All path names specified in the submit description file must be
less than 256 characters in length, and command line arguments must
be less than 4096 characters in length; otherwise, condor_submit
gives a warning message but the jobs will not execute properly.
* Somewhat understandably, behavior gets bizarre if the user makes
the mistake of requesting multiple Condor jobs to write to the same
file, and/or if the user alters any files that need to be accessed
by a Condor job which is still in the queue. For example, the
compressing of data or output files before a Condor job has
completed is a common mistake.
* To disable checkpointing for Standard Universe jobs, include the
line:
+WantCheckpoint = False
in the submit description file before the queue command(s).
See Also
Condor User Manual
Author
Condor Team, University of Wisconsin-Madison
Copyright
Copyright (C) 1990-2009 Condor Team, Computer Sciences Department,
University of Wisconsin-Madison, Madison, WI. All Rights Reserved.
Licensed under the Apache License, Version 2.0.
See the Condor Version 7.2.4 Manual or
http://www.condorproject.org/licensefor additional notices. condor-
admin@cs.wisc.edu
date just-man-pages/condor_submit(1)