The goal of this exercise is to run some jobs...[edit | edit source]
This is the fundamental goal for an HTCondor system, to be able to run jobs. Make sure you are able to successfully run jobs by the end of it, else other exercises won't make much sense. Ask questions!
Run a simple command using a submit file[edit | edit source]Here is a simple submit file for the
universe = vanilla executable = /bin/hostname output = simple.out error = simple.err log = simple.log request_cpus = 1 request_memory = 1MB request_disk = 1MB queue
Note: There is nothing magic about the name of an HTCondor submit file. It can be any filename you want. It's a good practice to always include the
.sub extension, but it is not required. Ultimately, a submit file is a text file
The lines of the submit file have the following meanings:
Note that we are not using the
arguments lines or
transfer_input_files because the
hostname program is all that needs to be transferred from the submit server, and we want to run it without any additional options.
$> condor_submit simple.sub Submitting job(s). 1 job(s) submitted to cluster NNNN.
If, instead of the text above, there are error messages, read them carefully and then try to correct your submit file.
condor_submit returns back to the shell prompt right away. It does not wait for your job to run. Instead, as soon as it has finished submitting your job into the queue, the submit command finishes.
condor_q -nobatch to watch for your job in the queue. You probably may not even catch the job in the
R running state, because the
hostnamecommand runs very quickly. When the job itself is finished, it will no longer be listed in the
The output from your job is written to the filename given in the
output line of your submit file. Thus, after the job finishes, you should be able to see the
simple.out, since this information is usually printed to the terminal by the
hostname program, and not to a special file of it's own.
Run this to see the output:
$ cat simple.out
simple.err file should be empty, unless there were issues running the
hostname executable after it was transferred to the slot. The
simple.log is more complex and will be the focus of a later exercise.
Running a job with arguments[edit | edit source]Very often, when you run a command on the command line, it includes arguments after the command name itself:
$> cat simple.out $> sleep 60 $> dc -e '6 7 * p'
executablestatement and all remaining arguments go into an
argumentsstatement. For example, if the full command is:
$> sleep 60
executable = /bin/sleep arguments = "60"
$> dc -e '6 7 * p'
executable = /usr/bin/dc arguments = "-e '6 7 * p'"
sleepcommand shown above, which simply does nothing for the specified number of seconds, then exits normally. It is convenient for simulating a job that takes a while to run. Create a new submit file (you name it this time!) and save the following text in it.
universe = vanilla executable = /bin/sleep arguments = "60" output = sleep.out error = sleep.err log = sleep.log request_cpus = 1 request_memory = 1MB request_disk = 1MB queue
Submit this new job. Again, watch for it to run using
condor_q -nobatch; check once every 15 seconds or so. Once the job starts running, it will take about 1 minute to run (because of the
sleep command, right?), so you should be able to see it running for a bit. When the job finishes, it will disappear from the queue, but there will be no output in the output or error files, because
sleep does not produce any output.
Running a script job from the submit directory[edit | edit source]
So far, we have been running programs (executables) that come with the standard Linux system. But you are not limited to standard programs. In this example, you will write a simple shell script (command line) executable in the submit directory, then write a submit file to run it.
- Put the following contents into a file named
#!/bin/sh echo 'Date: ' $(date) echo 'Host: ' $(hostname) echo 'System: ' $(uname -spo) echo "Program: $0" echo "Args: $*"
- Make the file itself executable:
$ chmod +x test-script.sh
- Test your script from the command line:This step is really important! If you cannot run your executable from the command-line, HTCondor probably cannot run it on another machine, either. And debugging simple problems like this one is surprisingly difficult. So, if possible, test your
$ ./foo.sh hello 42 Date: Mon Aug 28 13:36:22 CEST 2017 Host: aiadm28.cern.ch System: Linux x86_64 GNU/Linux Program: ./foo.sh Args: hello 42
argumentsas a command at the command-line first.
- Write the submit file (this should be getting easier now):Note: As this example shows, blank lines and spaces around the = sign do not matter to HTCondor. Use whitespace to make things clear to you. What format do you prefer to read?
universe = vanilla executable = test-script.sh arguments = "foo bar baz" output = script.out error = script.err log = script.log request_cpus = 1 request_memory = 1 request_disk = 1 queue
- Submit the job, wait for it to finish, check the output. (Are you surprised by the
Program:line in the output? Why is it like that? Google for it, or ask an instructor if you are curious, although the answer is not that exciting.)
In this example, the
executable that was named in the submit file did not start with a
/, so the location of the file is relative to the submit directory itself. In other words, in this format the executable must be in the same directory as the submit file