magus v0.4.3 is out. See what's new
¶ View markdown source · ✎ Suggest an edit
1 min read

MGS5004: this needs the persistent server

A command that HANDS OFF work - today magus run --detach and magus affected --detach - was asked to do so with no persistent server to hand it to.

[MGS5004] --detach hands the work to the server, and none is running; start one with `magus server start`
  see: .../MGS5004.md

Why

--detach does not fork a background copy of magus. It submits the run to the server and returns the job id, so the work outlives your shell and you can watch it instead of blocking on it.

That only holds for the server magus server start creates. magus also stands up a short-lived proc server for ordinary commands, and that one exits when the command that started it exits - so work submitted there is queued and then silently dropped. You would be told the run detached, and nothing would ever run it.

Refusing is the only honest answer available. magus cannot promise the work will happen when the thing meant to do it is about to exit.

Fix

Start the server, then detach:

magus server start
magus run ci --detach

Watch the queued work with:

magus status --watch 15s

When you do not want a server

Drop --detach and run in the foreground. Every other magus command works with no server at all; only handing work off requires one, because only handing work off needs something still running afterwards to accept it.

services diagnosticsLanding page for MGS5xxx diagnostics that flag problems with long-running service ops, such as near-duplicate services that should be shared instead of run as separate processes. StatusServiceStatusService serves the snapshot, and streams it for a live dashboard. ChangelogEvery change to magus, newest first, in Keep a Changelog format, starting with the unreleased entries. Generated from changes/unreleased/ and releases/*.yaml. ConcurrencyHow magus coordinates parallel work - the intra-process scheduler that parallelizes a single run, the cross-process workspace lock that keeps two separate magus invocations from clobbering each other's outputs and cache, and the broker-held machine budget that keeps every magus on the host from oversubscribing it.
MGS5004servicesserverdetachbackground
Last updated (95680f58)
Earlier changes on this page (1)

Full history ↗ · Blame source ↗

Glossary

Op

A single tool-native command a target composes (long form: operation); the middle of the work hierarchy (Spell to Op to Target). See operations.

Ward

A coded diagnostic that inspects a resolved op and nudges or blocks an anti-pattern before it runs. See wards.

Affected

The set of projects touched by a change; magus affected <target> runs a target only over them. See affected.

Service

A long-running or shared process magus manages across runs, distinct from a one-shot target. See services.

Server

The background process a person starts with magus server start. It serves MCP, the console, background jobs and the warm knowledge graph, and adopts nested magus calls into one pool. See server.

CI

An ordinary magusfile-defined target you compose yourself with magus\needs - magus does not hardcode its stages. Magus.RunCI treats it specially only in that it strips the rw charm, it is the anchor magus affected ci keys off, and a selected scope with no project declaring it is a load error rather than a silent no-op. See targets.

Queued

A target that wants a slot while the pool is full; it blocks first-in-first-out until a slot frees. The dashboard colors a sample with queued > 0 accordingly. See server.

Job

The unit of delegated work, and one row of the job store: what an orchestrating agent handed out, with its goal, the checkpoint it was cut against, the paths it may write or must not touch, and the one check it runs. A job's holder is either a session, for work an orchestrator handed out, or the server, for its own maintenance. The store records; the agent guard is what reads those facts back when grading a write. See doctrine.

A job is not a run. magus run build web is a run, and no job exists for it. A job causes runs: its check executes as one, and a server job records the invocation of its last one. Jobs are listed with magus ls jobs and in the console's Jobs view; runs are listed in the Runs view.

Run

One target executing under one magus invocation, such as magus run test web or magus affected ci. A run keeps its captured output behind an output reference. Every magus run is a run whether or not any job asked for it; see Job for how the two relate.

Conventions

This page uses none of the site's convention markers. The full set is on the conventions page.