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

MGS5002: service op detaches

A service op returned a Service whose process command detaches - docker run -d / --detach (or a combined short-flag block like -itd). magus rejects it at resolution, before anything forks.

[MGS5002] service op "db" detaches with "-d": magus forks a service in the foreground and supervises it, so detaching breaks stdout capture, readiness, and stop. Drop the detach flag, or make this a command op if you really want it detached.
  see: .../MGS5002.md

Why

magus runs a service in the foreground and supervises it: it blocks on the process, captures its stdout and stderr, polls the readiness probe against it, and sends the stop command to shut it down. A detached process forks away from magus immediately, so all four of those become meaningless - magus is left blocking on a launcher that already exited, supervising nothing.

This is not a style preference; it is a self-contradiction between the op's kind (a long-running, supervised service) and its argv (fire-and-forget). So it is an error with no flag-level suppression: the resolution is to change the shape, not to silence the check.

The check is scoped to container runtimes (docker, podman, nerdctl) because -d is tool-specific: dnsmasq -d, for example, means the opposite (stay in the foreground) and is never flagged.

Fix

  • Drop the detach flag. docker run (no -d) stays in the foreground and streams logs, which is exactly what a supervised service wants.
  • If you genuinely want a fire-and-forget process that magus does not supervise, model it as a command op (which runs to completion) rather than a service op. But prefer a supervised service: magus deliberately discourages spawning a process it can no longer see or cleanly tear down.
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. ServicesHow magus runs long-running service ops, shares one instance across dependents and invocations, and guards against the sprawl and misuse foot-guns. magus DocumentationThe magus documentation hub covering install, targets, spells, charms, operations, engines, remote caching, MCP, telemetry, and the interactive playground. SpellsA spell is a library of tool-native ops (go-build, cargo-clippy, eslint) plus cache metadata that your magusfile composes into runnable targets.
MGS5002servicesservice opdockerdetachsupervisionward
Last updated (b022d75e)
Glossary

Operation

A single tool-native command a target composes; the middle of the work hierarchy (Spell to Operation 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.

Service

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

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.

Conventions

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