seamm_jobserver package

Submodules

seamm_jobserver.jobserver module

The JobServer for the SEAMM environment.

class seamm_jobserver.jobserver.JobServer(logger=<Logger seamm_jobserver.jobserver (WARNING)>)

Bases: MutableMapping

check_for_finished_jobs()

Check whether jobs have finished.

Both locally-run and SLURM-submitted jobs may be tracked simultaneously now that a single JobServer instance can serve multiple queues of different types (a type = local section and one or more type = slurm sections at once) – so both passes always run, each filtering self._jobs down to its own mode.

check_for_new_jobs()

Check the database for new jobs that are runnable.

If this instance has no configured queues at all (self._sections empty, i.e. no <root>/<jobserver-name>.ini), behavior is exactly what it was before the multi-queue feature existed: every submitted job runs immediately as an uncapped local subprocess, regardless of any queue a job’s parameters might happen to carry. Otherwise, each submitted job is routed to the queue it requested (parameters["queue"]), falling back to this instance’s default queue if it didn’t request one – an unknown or missing-with-no-default queue fails the job immediately rather than silently running it somewhere unintended. Each queue has its own max_concurrent_jobs, checked independently, so one full queue never blocks another from accepting new jobs.

check_for_stopped_jobs()

Look for jobs that should be actively stopped: either their datastore row vanished entirely (deleted, e.g. via the dashboard), or their status was explicitly set to kill (stop the run but leave the job’s files/row alone, unlike delete).

Before SLURM, a deleted job’s files disappeared but nothing told the local subprocess to stop – it just ran on until it crashed on the missing files. On a scheduler that is not good enough: an orphaned SLURM job can sit running (or queued) for hours. So every poll cycle, before check_for_finished_jobs gets a chance to treat a just-killed job as merely lost and try to resubmit it, this checks every job actually being tracked and every kill-status row, and issues the real scancel/process-kill.

property db

property db_path

gui_about()

Provide information about the JobServer.

gui_create()

Create the tkinter GUI.

gui_event_loop()

The callback for the main loop when using Tk

gui_on_closing()

Check that the user wants to stop the JobServer, and do so

gui_preferences()

Provide access to the preferences for the JobServer.

gui_status(status)

Display the current load and jobs.

gui_status_loop()

The callback for the the status.

initialize()

Parse the command-line and setup the JobServer

setup_parser()

Setup the command-line parser.

start()

Start the main event loop.

start_job(job_id, wdir, cmdline='', queue=None, slurm_overrides=None)

Run the given job, locally or via SLURM depending on the type of the queue it’s routed to.

Parameters:

• job_id (integer) – The id of the job to run.

• queue (str or None) – Which configured section (cluster/queue) to route this job to. None falls back to this instance’s default queue – see _resolve_queue. If this instance has no queues configured at all, the job always runs as a local subprocess regardless.

• slurm_overrides (dict or None) – A job’s requested per-directive SLURM overrides (its parameters["slurm"]), e.g. {"ntasks": 4, "mem": "40G"}. Ignored for a local-mode job. Validated against the queue’s limits before use – see SlurmSection.merge_overrides.

Returns:

The local pid, if run locally. None if run via SLURM – _start_job_slurm updates the datastore itself in that case, since it also needs to record the SLURM job id.

Return type:

int or None

status()

Get the current load, etc.

class seamm_jobserver.jobserver.TkTextHandler(widget)

Bases: StreamHandler

emit(record)

Emit a record.

If a formatter is specified, it is used to format the record. The record is then written to the stream with a trailing newline. If exception information is present, it is formatted using traceback.print_exception and appended to the stream. If the stream has an ‘encoding’ attribute, it is used to determine how to do the output to the stream.

seamm_jobserver.jobserver.humanize(memory, suffix='B', kilo=1024)

Scale memory to its proper format e.g:

1253656 => ‘1.20 MiB’ 1253656678 => ‘1.17 GiB’

seamm_jobserver.jobserver.run()

Helper routine to run the JobServer from the command-line

Module contents

seamm_jobserver JobServer for the SEAMM environment.