Skip to main content

The Job Manager is python wrapper around SGE utilities like qsub, qstat and qdel. It interacts with these tools to submit and manage grid jobs making up a complete workflow ecosystem.

Everytime you interact with the Job Manager, a local database file (normally named submitted.db) is read or written so it preserves its state during decoupled calls. The database contains all informations about jobs that is required for the Job Manager to:

  • submit jobs (includes wrapped python jobs or Torch5spro specific jobs)

  • probe for submitted jobs

  • query SGE for submitted jobs

  • identify problems with submitted jobs

  • cleanup logs from submitted jobs

  • easily re-submit jobs if problems occur

  • support for parametric (array) jobs

Many of these features are also achieveable using the stock SGE utilities, the Job Manager only makes it dead simple.

Submitting a job

To interact with the Job Manager we use the jman utility. Make sure to have your shell environment setup to reach it w/o requiring to type-in the full path. The first task you may need to pursue is to submit jobs. Here is how:

$ jman submit myscript.py --help
Submitted 6151645 @all.q (0 seconds ago) -S /usr/bin/python myscript.py --help

Submitting a parametric job

Parametric or array jobs are jobs that execute the same way, except for the environment variable SGE_TASK_ID, which changes for every job. This way, your program controls which bit of the full job has to be executed in each (parallel) instance. It is great for forking thousands of jobs into the grid.

The next example sends 10 copies of the myscript.py job to the grid with the same parameters. Only the variable SGE_TASK_ID changes between them:

$ jman submit -t 10 myscript.py --help
Submitted 6151645 @all.q (0 seconds ago) -S /usr/bin/python myscript.py --help

The -t option in jman accepts different kinds of job array descriptions. Have a look at the help documentation for details with jman --help.

Probing for jobs

Once the job has been submitted you will noticed a database file (by default called submitted.db) has been created in the current working directory. It contains the information for the job you just submitted:

$ jman list
job-id   queue  age                         arguments
========  =====  ===  =======================================================
6151645  all.q   2m  -S /usr/bin/python myscript.py --help

From this dump you can see the SGE job identifier, the queue the job has been submitted to and the command that was given to qsub. The list command from jman only lists the contents of the database, it does not update it.

Refreshing the list

You may instruct the job manager to probe SGE and update the status of the jobs it is monitoring. Finished jobs will be reported to the screen and removed from the job manager database and placed on a second database (actually two) containing jobs that failed and jobs that succeeded:

$ jman refresh
These jobs require attention:
6151645 @all.q (30 minutes ago) -S /usr/bin/python myscript.py --help

Inspecting log files

As can be seen the job we submitted just failed. The job manager says it requires attention. If jobs fail, they are moved to a database named failure.db in the current directory. Otherwise, they are moved to success.db. You can inspect the job log files like this:

$ jman explain failure.db
Job 6151645 @all.q (34 minutes ago) -S /usr/bin/python myscript.py --help
Command line: (['-S', '/usr/bin/python', '--', 'myscript.py', '--help'],) {'deps': [], 'stderr': 'logs', 'stdout': 'logs', 'queue': 'all.q', 'cwd': True, 'name': None}

6151645 stdout (/remote/filer.gx/user.active/aanjos/work/spoofing/idiap-gridtk/logs/shell.py.o6151645)


6151645 stderr (/remote/filer.gx/user.active/aanjos/work/spoofing/idiap-gridtk/logs/shell.py.e6151645)
Traceback (most recent call last):
   ...

Hopefully, that helps in debugging the problem!

Re-submitting the job

If you are convinced the job did not work because of external conditions (e.g. temporary network outage), you may re-submit it, exactly like it was submitted the first time:

$ jman resubmit --clean failure.db
Re-submitted job 6151663 @all.q (1 second ago) -S /usr/bin/python myscript.py --help
  removed `logs/myscript.py.o6151645'
  removed `logs/myscript.py.e6151645'
  deleted job 6151645 from database

The --clean flag tells the job manager to clean-up the old failure and the log files as it re-submits the new job. Notice the new job identifier has changed as expected.

Cleaning-up

If the job in question will not work no matter how many times we re-submit it, you may just want to clean it up and do something else. The job manager is here for you again:

$ jman cleanup --remove-job failure.db
Cleaning-up logs for job 6151663 @all.q (5 minutes ago) -S /usr/bin/python myscript.py --help
  removed `logs/myscript.py.o6151663'
  removed `logs/myscript.py.e6151663'
  deleted job 6151663 from database

Inspection on the current directory will now show you everything concerning the said job is gone.

Metadata

Release files for gridtk 0.3.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distributions (sdists)

Source distribution for gridtk 0.3.0
File Size Uploaded
gridtk-0.3.0.zip 30.4 kB Details
gridtk-0.3.0.tar.gz 20.1 kB Details

Release files / gridtk-0.3.0.zip

Download URL gridtk-0.3.0.zip
Size 30.4 kB
Tags Source
SHA-256 checksum
How to use checksums
bc88f91c6ec090e4bed9c24047313b09bf5ae5fb5b348774ddd0683384c39e23
BLAKE2b-256 checksum
How to use checksums
91ea429277f05436ffbac427056abdaa97da39248cc2d567a8beb72104027671
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No

Release files / gridtk-0.3.0.tar.gz

Download URL gridtk-0.3.0.tar.gz
Size 20.1 kB
Tags Source
SHA-256 checksum
How to use checksums
21e323884ccd3896727c817a68de98e079b22dc08bde9d16c6d8568827a96f68
BLAKE2b-256 checksum
How to use checksums
611ce07ee70c69226310a87e6fc0c05549b35f7795ba7accda4922fd62076037
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No

Release history Release notifications | RSS feed

4.0.0

2 release files

3.2.1

2 release files

3.2.0

2 release files

3.1.0

2 release files

3.0.1

2 release files

3.0.0

2 release files

2.1.0

2 release files

2.0.1

2 release files

2.0.0

2 release files

1.8.4

1 release file

1.8.3

1 release file

1.8.2

1 release file

1.8.1

1 release file

1.8.0

1 release file

1.7.0

1 release file

1.6.5

1 release file

1.6.4

1 release file

1.6.3

1 release file

1.6.2

1 release file

1.6.1

1 release file

1.5.0

1 release file

1.4.4

1 release file

1.4.3

1 release file

1.4.2

1 release file

1.4.1

1 release file

1.4.0

1 release file

1.3.0

1 release file

1.2.4

1 release file

1.2.3

1 release file

1.2.2

1 release file

1.2.1

1 release file

1.2.0

1 release file

1.1.6

1 release file

1.1.5

1 release file

1.1.4

1 release file

1.1.3

1 release file

1.1.2

1 release file

1.1.1

1 release file

1.1.0

1 release file

1.0.3

1 release file

1.0.2

1 release file

1.0.1

1 release file

1.0.0

1 release file

0.3.7

1 release file

0.3.6

1 release file

0.3.5

1 release file

0.3.4

1 release file

0.3.3

1 release file

0.3.2

1 release file

0.3.1

1 release file

This release

0.3.0 This release

2 release files

0.2.1

1 release file

0.2

1 release file

0.1

1 release file

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page