The various Tractor components communicate using HTTP requests. Most responses to queries are JSON-formatted data dictionaries.

Here is a summary of the query URLs and their replies:

Tractor Dashboard - User Interface

To start a Dashboard session, direct your web browswer to: 


Queue Controls

Login, creating an authenticated session necessary for some types of control operations:

(note: at sites using login passwords, an additional parameter "c=CCCCC" giving the site-specified password hash or encryption is also required.)

Retire a job, deleting it from the active assignment queue and dashboards:

(note: the tsid value is an authentication token returned from a prior q=login request).

Restore a previously deleted job, if the underlying job data is still present:


Retry all tasks with errors in a particular job:


Stop and Requeue all currently active tasks in a particular job:


Retry a specific task, e.g. tid=22, in a job:


Stop and Requeue all currently active tasks on a particular blade:


Skip a specific task in a job, allowing its parent to continue:

(note: use "tid=error" to skip all error tasks in that job, or "tid=active" to interrupt all active tasks and continue past them)

Completely restart (respool) an entire job:


Interrupt a running job, kill active commands and pause to prevent further dispatching:


Interrupt a specific task, leaving that task in error state while other tasks continue to run:

(note: the tid parameter can also specify a comma-separated list of task IDs)

Job Queue Information Queries

List the users who have previously spooled jobs:


List the jobs currently queued for a particular user:

(Note: the owner and filter restrictions are optional, but unfiltered
lists may be large. The tsid parameter is only needed when a filter is
specified. Add "&metadata=0" to also suppress metadata blocks.)

Get the task tree for a particular job:


List the commands associated with a task:


Get the URL for the logs from a particular task:


Editing Job Attributes

General job attribute editing - Attributes entries listed in a job's

jobinfo.json dictionary can be changed using an http URL of the form:


Similarly, attributes at the command-level can be changed using the "q=cattr&cid=..." variant (note: only set_service is supported at this time):


Note that crews.config can specify permissions that restrict editing of particular attributes to specific crews, i.e. Wranglers only.

Change the job-level Service Key requirements:


Reprioritize a job:


Suspend new dispatching in a job:

Use "&set_pause=0" to unpause the job. This type of "pause" suspends new task dispatching - the job will be skipped during blade assignment passes until unpaused. Any already running tasks from that job will continue to run.

Session Queries

There are several files of user specific information stored in the user area below the tractor spool folder. The following queries allow the UI to save and retrieve these files.

List all stored filters for user of specified type:


Retrieve a user's named filter:


Store a user's named filter:


Retrieve user's preference information:


Store a user's preference information:


Delete a user's preference information:


Retrieve user's session file:


Store a user's session file:


Delete a user's session file:


Retrieve a list of available file rule definitions:


Administrator Controls

Reload configuration files (blade, crews, limits):


Reload a single configuration file, for example: limits.config


Query basic engine state:


Query current active limit tallies:

NOTE: this query is relatively expensive, it locks all threads. Add &full=1 to also include zero-valued "transitory" limits not defined in limits.config:**

Query unrolled crew definitions:


Query the current Dispatching Tier definitions:


Query unrolled blade profile definitions:


List recently connected Dashboard users (session mailboxes):


Trace engine assignment decisions:
http://ENGINE/Tractor/ctrl?q=tracer&fmt=plain -- next assignment pass

add &t=bbbb -- for blade named bbbb add &t=jjjj -- for job with jid jjjj

Remove an old entry from the displayed list of active blades:

where hhhhh is the blade's hostname and aa.aa.aa.aa is the blade's current tcp/ip address.

Diagnostic: query engine internal message queue lengths:

NOTE: this query is relatively expensive, it locks all threads.

Engine log level: change the logging threshold level of the engine's own diagnostic logs:

Recognized level names are: severe, notice, info, debug, trace

Engine database contexts: bounce the engine's own internal client connections to the database server:


Blade Queries and Controls

List all of the currently connected blades, with a recent status snapshot:


Stop and Requeue all currently active tasks on a particular blade:


Query the engine for its information on a specific blade:


Query the engine for blade information, and include results from an (expensive) direct probe of the blade itself: http://ENGINE/Tractor/monitor?q=bdetails&b=NAME&probe=1

Use this query cautiously, especially in scripts, since it can cause processing delays on the engine as it waits for the blade response -- especially when probing blades that are slow to respond. In this form of the query, the NAME parameter can be "hostname" or "hostname/address". The address portion is historical and is ignored, the engine derives blade addresses from the last entry in the blade database.

Query the current state of a blade directly:


Change the NIMBY state of a blade, via the engine:

First, send a login request to receive a session ID (tsid), then:



SSS = the tsid from the login reply
BBB = identifies the blade, as "blade_hname/"
NNN = the desired new nimby state:
nimby=1 -- blade accepts only local Cmds from jobs spooled from that host
nimby=0 -- reset nimby state to unrestricted
nimby=jobOwner1,owner2,... -- blade only accepts jobs owned by the specified users

Change the NIMBY state of a blade via direct http connection to the blade:

Where NNN is the same as for the engine proxy case, above. Note that this direct type of connection may be disallowed by the NimbyConnectPolicy setting in blade.config.

Engine Metrics and Statistics

Get the most recent engine health statistics:

The query returns various tractor-engine performance and status metrics. The currently provided values are intended to give administrators a quick set of engine "vital signs" to check when looking at overall Tractor health or for engine hot spots.

The statistics report is organized as a JSON dictionary. Each key in the dictionary represents one type of metric. The value field in the dictionary for each key is an array of recent samples for that metric.

The current dictionary metrics names are listed here. The list may evolve over time.

Get a recent history of engine statistics:

This query is like q=statistics, above, but it returns several minutes worth of samples for each metric.

Note: for continuous monitoring add "&stats=1" to your recurring q=subscribe request; statistics will arrive as 's' mbox messages.

The last entry in each array is the most recent sample. The engine maintains a simple ring buffer of these samples, so on the next update the first array element is dropped and all of the other samples appear to "shift left" with a new value appearing at the end. The statslog query returns all of the samples in the buffer so that a UI can generate a complete graph from a single query.