CONDOR_RUN(1)
π condor_run π β the HTCondor Manual, section 1, user commands
okay bestie, so this page comes straight out of the HTCondor Manual, and it's about condor_run, which is genuinely one of the most underrated lil' tools in the whole suite. no cap. it's giving "I don't wanna write a whole submit file, I just wanna run my thing" energy, and I respect it so much. π
β¨ NAME β¨
condor_run β submit a shell command-line as an HTCondor job π«Ά
πΈ SYNOPSIS πΈ
condor_run [-u universe] [-getenv] [-a submitcmd] "shell command"
π¦ DESCRIPTION π¦
So here's the vibe: condor_run takes a shell command line, bundles it up into an HTCondor job, and submits it. then it just... waits. patiently. like a bestie holding your bag. π when the HTCondor job finishes, condor_run writes the job's output to your terminal and exits with the exit status of the HTCondor job. and hear me when I say this: no output appears until the job completes. none. zero. it's a whole β¨ reveal moment β¨, not a livestream.
Enclose the shell command line in double quote marks, so it can be passed to condor_run without modification. super important, don't skip it. also, condor_run will not read input from the terminal while the job executes β so if your shell command line needs input, you gotta redirect the input from a file instead. like this:
$ condor_run "myprog < input.data"
condor_run jobs rely on a shared file system for access to any necessary input files. and the current working directory of the job has to be accessible to the machine within the HTCondor pool where the job actually runs. so like, no shared fs, no slay. that's the rule. π
There are also these specialized environment variables you can set to specify requirements for the machine where the job may run:
CONDOR_ARCHβ specifies the architecture of the required platform. the values will be the same as theArchmachine ClassAd attribute.CONDOR_OPSYSβ specifies the operating system of the required platform. the values will be the same as theOpSysmachine ClassAd attribute.CONDOR_REQUIREMENTSβ specifies any additional requirements for the HTCondor job. it is recommended that the value defined forCONDOR_REQUIREMENTSbe enclosed in parenthesis. (yes, really. trust.) π
When one or more of these environment variables is specified, the job is submitted with:
Requirements = $CONDOR_REQUIREMENTS && Arch == $CONDOR_ARCH && OpSys == $CONDOR_OPSYS
Without these environment variables, the job receives the default requirements expression, which requests a machine of the same platform as the machine on which condor_run is executed. (a "same hat" situation, if you will. π©)
Also: all environment variables set when condor_run is executed will be included in the environment of the HTCondor job. all of them. the whole friend group gets invited. π
And if condor_run gets killed before the HTCondor job completes, it removes the HTCondor job from the queue and deletes its temporary files. it cleans up after itself. iconic behavior fr fr. πβ¨
π OPTIONS π
-u universeβ submit the job under the specified universe. the default isvanilla. and okay, technically you can specify any universe, but only thevanilla,scheduler, andlocaluniverses result in a submit description file that may work properly. so like, the others are giving false confidence, ngl. π-a submitcmdβ add the specified submit command to the implied submit description file for the job. if you want to include spaces within submitcmd, enclose the submit command in double quote marks. and if you want to include double quote marks within submitcmd, enclose the submit command in single quote marks. yes, it's quote-ception. nest responsibly. πͺ-getenvβ adds thegetenv = trueto the generated submit description file.
β EXAMPLES β
condor_run can be used to compile an executable on a different platform. which is lowkey the dream scenario, right? π¦
First, set the environment variables for the required platform:
$ export CONDOR_ARCH="SUN4u"
$ export CONDOR_OPSYS="SOLARIS28"
Then use condor_run to submit the compilation β here are two ways to do it:
$ condor_run "f77 -O -o myprog myprog.f"
or
$ condor_run "make"
both ate, honestly. π
π FILES π
condor_run creates the following temporary files in the user's working directory. the placeholder <pid> is replaced by the process id of condor_run.
.condor_run.<pid>β a shell script containing the shell command line..condor_submit.<pid>β the submit description file for the job..condor_log.<pid>β the HTCondor job's log file; it is monitored bycondor_run, to determine when the job exits..condor_out.<pid>β the output of the HTCondor job before it is output to the terminal..condor_error.<pid>β any error messages for the HTCondor job before they are output to the terminal.
condor_run removes these files when the job completes. π§Ή
β οΈ however β if condor_run fails, it is possible that these files will remain in the user's working directory, and the HTCondor job may remain in the queue. so like, if something goes sideways, go peek in your working directory. the evidence will be there. π΅οΈββοΈ
π GENERAL REMARKS π
condor_run is intended for submitting simple shell command lines to HTCondor. it does not provide the full functionality of condor_submit. therefore, some condor_submit errors and system failures may not be handled correctly. so like, don't come for it when it doesn't handle your extremely niche edge case β it never claimed to. π
All processes specified within the single shell command line will be executed on the single machine matched with the job. HTCondor will not distribute multiple processes of a command line pipe across multiple machines. one job, one machine, one moment. periodt. π
condor_run will use the shell specified in the SHELL environment variable, if one exists. otherwise, it will use /bin/sh to execute the shell command-line.
By default, condor_run expects Perl to be installed in /usr/bin/perl. if Perl is installed in another path, ask the Condor administrator to edit the path in the condor_run script, or just explicitly call Perl from the command line yourself:
$ perl path-to-condor/bin/condor_run "shell-cmd"
β¨ problem: solved β¨
π EXIT STATUS π
condor_run exits with a status value of 0 (zero) upon complete success. slay. π
the exit status of condor_run will be non-zero upon failure.
and here's the specific lore you need: in the case of a single error due to a system call, the exit status will be the error number (errno) of the failed call. so that number is not vibes, it's information. read it. π
π«Ά AUTHOR π«Ά
HTCondor Team β love them, truly.
π COPYRIGHT π
1990-2026, Center for High Throughput Computing, Computer Sciences Department, University of Wisconsin-Madison, Madison, WI, US. Licensed under the Apache License, Version 2.0.
and that's the whole page, bestie!! π this was the HTCondor Manual page for condor_run, dated Oct 16, 2026 β go submit something cute, and remember: quote your command, share your filesystem, and check your exit status. mwah. π
β¨π¦
π¦ where this page comes from
- fedora 43: condor 25.14.1-1.fc43 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms