jobs
The job system — every long-running operation.
List jobs
Every long-running operation is a job. Filterable by class and status so the UI's jobs page and `hoserva logs` can scope what they render without walking the whole history.
Get a job
A single job's current state, by id.
Cancel a job
Only meaningful where the underlying tool supports cancellation; a job that cannot be cancelled reports that in its `cancellable` field rather than accepting this call and doing nothing. A queued or running job is stopped; an interrupted, cancellable job is ended `cancelled`. For a data-disk upgrade this is the abort: refused with `job_not_cancellable` once its checkpoint is at releasing, whether queued, running or interrupted. A running upgrade is answered with the running job and records its outcome once it has unmounted everything. A queued or interrupted upgrade is unwound first; if that fails it stays interrupted and the call is refused with `disk_upgrade_cleanup_failed`, naming what is still mounted. `job_abort_in_progress` refuses a second cancel while one runs. `job_resume_in_progress` refuses a cancel while a resume of the same job is still repairing its log; retry in a moment.
Resume a checkpointed job
Only resumable job types (mover, rebalance, evacuation, share relocation, data- and parity-disk upgrade) persist a checkpoint to resume from. Jobs are never resumed automatically after a restart — this operation is always an explicit user action. A data-disk upgrade resumes only in maintenance mode; one resumed at its releasing checkpoint is not cancellable. Refused with `job_abort_in_progress` while a cancel of the same job is unwinding it, and with `job_resume_in_progress` while another resume of the same job is still repairing its log (retry in a moment). Resuming an interrupted mover job is refused with 409 `on_battery` while the on-battery hold is active.
Download a job's captured stdout/stderr
Kept for 90 days. With `follow` true on a job that has not finished, the response stays open and carries the gzip stream of the log as it grows (each write is flushed as it arrives, so a client decompressing on the fly prints every line at once), and ends when the job reaches a terminal state, when the client disconnects, or on a read error; a clean end carries the gzip trailer. `follow` on a finished job is the same as omitting it.