systemg 0.66.6

An agent-friendly general-purpose program orchestrator for busy people.
Documentation
1
[{"id":"/docs","route":"/docs","section":"docs","group":null,"title":"systemg","description":"An agent-friendly general-purpose program orchestrator for busy people.","headings":"What systemg does · Built for production","text":"systemg runs your service graph from a single YAML file. Launch your first service graph in minutes. Start from working examples for real-world service layouts. What systemg does Suppose you're building an API that needs PostgreSQL, Redis, and a background worker. Instead of starting each service manually in different terminals, you define them once in a YAML file. systemg starts everything in the right order, restarts crashed services, and provides unified logging. Built for production - Start services in dependency order. - Restart failed processes with configurable backoff. - Keep service logs isolated and predictable. - Run everything from a single binary."},{"id":"/docs/intro","route":"/docs/intro","section":"docs","group":null,"title":"Introduction","description":"","headings":"What systemg does · Built for production · Next steps","text":"systemg An agent-friendly general-purpose program orchestrator for busy people. What systemg does Suppose you're building an API that needs PostgreSQL, Redis, and a background worker. Instead of starting each service manually in different terminals, you define them once in a YAML file. systemg starts everything in the right order, restarts crashed services, and provides unified logging. Run sysg start to attach in the foreground and stream every service with a per-service prefix. Ctrl-C stops that project and returns the terminal. Add --daemonize when you want the command to return immediately. This example is a single loose bundle — services with no project. To run several independent stacks under one resident supervisor, group them under a projects: map; see Projects. Built for production systemg handles the complexity of process management so you don't have to. Services that depend on databases wait for them to start. Crashed processes restart automatically with configurable backoff. Each service gets isolated logging. Zero external dependencies—just a single binary. Next steps Install systemg and have your first service running in under a minute."},{"id":"/docs/installation","route":"/docs/installation","section":"docs","group":"Installation","title":"Installation","description":"","headings":"Install · Linux / macOS · Homebrew · Verify · Specific version · Switch versions · Next steps","text":"Installation Install Linux / macOS Homebrew Homebrew owns the binary it installs, so brew upgrade sysg swaps it without the live re-execution the installer performs. A supervisor that is already resident keeps serving the build it booted from until it is stopped; sysg version reports both. Verify Specific version Install a specific version: Switch versions Switch to an already installed version, or download it: The installer validates the downloaded binary before changing the active version. A newer release can upgrade a running supervisor without restarting its services when both binaries advertise the same live-reexec protocol and handoff schema; major and minor version boundaries do not decide compatibility. Residents from 0.56.0 through 0.57.0 still enforce the original same-major/minor rule; earlier residents do not support live re-execution. See Upgrading sysg for compatibility and SG0502 recovery. Next steps Create your first configuration and start running services."},{"id":"/docs/installation/upgrading","route":"/docs/installation/upgrading","section":"docs","group":"Installation","title":"Upgrading sysg","description":"","headings":"Live re-execution · Compatibility · Homebrew installs · Safe handoff requirements · Failure and rollback","text":"Upgrading sysg Run the normal installer again to upgrade to the latest release: A Homebrew install upgrades through Homebrew instead: Live re-execution Starting with 0.56.0 , compatible releases use live re-execution : the running supervisor replaces its process image in the same PID while retaining its service processes, process groups, control socket, log pipes, project modes, and lifecycle state. The installer performs the upgrade in this order: 1. Download the release into its versioned slot. 2. Verify its version, executable metadata, protocol, and handoff schema. 3. Ask the resident supervisor whether its runtime is safe to transfer. 4. Re-execute the supervisor and verify that the same PID reports the target version. 5. Update the sysg symlink and active-version file. The PATH target is not changed if any step fails. A foreground log attachment may reconnect while the supervisor image changes, but its project and service processes continue running. Compatibility Live re-execution requires a strictly newer release with the same live-reexec protocol and handoff schema. Version boundaries do not determine compatibility: 0.57.1 can live-upgrade to 0.58.0 while both advertise the same contract. A downgrade or a protocol/schema change requires a stopped supervisor. Contract-based compatibility begins with 0.57.1 . Residents from 0.56.0 through 0.57.0 enforce the original same-major/minor rule, while earlier residents do not support live re-execution. Upgrading from 0.56.x to 0.57.x therefore requires one stopped-supervisor transition: sysg stop --supervisor stops every registered project. After installation, restart each required project from its manifest. The installer reports SG0502 and leaves the existing PATH target unchanged when the resident and target cannot hand off safely. The target remains installed, so stopping the supervisor and rerunning the same installer activates it. Homebrew installs brew upgrade sysg replaces the binary on disk and stops there: it does not run the installer, so none of the live re-execution steps above happen. A supervisor that is already resident keeps serving the build it booted from. That reports the binary and the resident supervisor separately, so drift is visible. To adopt the new build, stop the supervisor and start each project again. sysg stop --supervisor stops every registered project. After stopping, restart each required project from its manifest. Safe handoff requirements The supervisor waits for a stable ownership boundary. It refuses the upgrade while a project is booting, a restart or deployment is active, a cron command is running, or dynamic child processes cannot be transferred. It also verifies that loaded manifests have not changed and that every managed output pipe can be inherited. The refusal is non-destructive. Let the reported operation finish, then rerun the installer. Failure and rollback The previous versioned binary remains installed until the replacement has restored supervision"},{"id":"/docs/quickstart","route":"/docs/quickstart","section":"docs","group":null,"title":"Quickstart","description":"","headings":"Install · Create a configuration · Start your service · Check status · View logs · Stop the project · What's next","text":"Quickstart Get systemg running in 60 seconds. Install Create a configuration Save as systemg.yaml . Start your service Your web server is now running at http://localhost:8080. Check status status opens the project-aware unit table. Use --format json for scripts. View logs Stop the project This stops the project while leaving the resident supervisor ready for another start. Use sysg stop --supervisor to shut down the supervisor itself. What's next - Configure multiple services with dependencies - Run services in the background with --daemonize - Set up automatic restarts for production"},{"id":"/docs/how-it-works","route":"/docs/how-it-works","section":"docs","group":"How It Works","title":"How It Works","description":"","headings":"Architecture · Process lifecycle · State location · Daemon vs foreground · Topics","text":"How It Works systemg is a single binary that manages processes as a supervisor. Architecture When you run sysg start , systemg starts or joins one resident supervisor. The supervisor launches and monitors the selected project; subsequent commands use its Unix socket. Process lifecycle 1. Start : Services launch as soon as their depends on entries resolve 2. Monitor : Supervisor tracks PIDs and health 3. Restart : Unsuccessful services restart per policy; clean exits stay done 4. Stop : Services terminate in reverse order State location All runtime data lives under one root, with each project's PID/state/cron files nested in its own projects/{project.id}/ subdirectory: User mode (default): - ~/.local/share/systemg/ - Supervisor + per-project state (under projects/ ) - ~/.local/share/systemg/logs/ - Service logs System mode ( sudo sysg --sys ): - /var/lib/systemg/ - Supervisor + per-project state (under projects/ ) - /var/log/systemg/ - Service logs See State for the full layout. Daemon vs foreground Foreground (default): - The terminal attaches to one project and streams service line - Slow boot progress updates in place - Ctrl+C stops that project; the supervisor and sibling projects stay up Daemon ( --daemonize ): - The command returns after the project reaches its target state - The same resident supervisor owns the project without a terminal attachment - Good for production The resident supervisor stays warm even when it has no projects. Stop it only with sysg stop --supervisor . Topics - Commands - CLI reference - Configuration - Service definitions - Cron - Scheduled tasks - Hooks - Commands triggered by service outcomes - State - Runtime files - Logs - Supervisor logs - Kernel Mode - system mode, container-init, sandboxing"},{"id":"/docs/how-it-works/configuration","route":"/docs/how-it-works/configuration","section":"docs","group":"How It Works","title":"Configuration","description":"","headings":"Complete example · Supervisor configuration · Registered manifests · Configuration sections · version · projects · env · logs · status · metrics · services · !include · Service configuration · command · exec · workingdir · dependson · env · restartpolicy · Service logs · hooks · cron · deployment · Field reference · Service fields · Environment object · Hooks object · Health check object · Durations · Deployment object · Blue/green deployment object","text":"Configuration systemg uses YAML files to define services and their relationships. Complete example A single file can declare many projects under the projects: map, keyed by project id. The example below shows one project's full set of sections. Project entries may override env and logs ; top-level metrics and status settings apply across the loaded projects. Supervisor configuration Project manifests describe workloads. Supervisor-wide defaults live separately in ~/.local/share/systemg/supervisor.xml , or /var/lib/systemg/supervisor.xml with --sys : - pre start secs : default execution budget for deployment pre start commands. - startup stability ms : survival window for services without a health check. - stop verify secs : time allowed to confirm that a terminated process is gone. - start settle secs : maximum wait for an unresolved queued project start. - command wait secs : how long a CLI command waits for the supervisor's reply before reporting SG0111. 0 waits indefinitely. Raise it when a project is large enough that a restart runs longer than the default; the command is never cancelled by the wait ending. - max concurrent : how many services a bulk start runs at once. -1 (the default) starts every service whose dependencies have resolved, 1 starts one service at a time, and any other positive number is a cap. Applies to sysg start and to project boot; restart remains one service at a time. The file is created on first supervisor start. Existing compact XML remains compatible and is rewritten in the indented form after it parses successfully. SYSG PRE START TIMEOUT SECS remains a higher-precedence compatibility override. Health-check attempt timeout and total timeout remain in the project manifest because readiness is workload-specific. The IPC poll slice, liveness probe window, unresponsive grace and live-upgrade deadlines are protocol invariants and are not operator settings. Registered manifests When you run a command with -c , the resident supervisor remembers that manifest's resolved path for each project it registers. Later commands can omit -c and target the registered project from any working directory. Ad-hoc units use the same manifest pipeline. sysg start -- first stages the command as a generated version 2 manifest. If a supervisor is already running, that file is not registered or started until you run the explicit sysg start --config ... command systemg prints. See Units. sysg restart treats the files at those paths as the source of truth. It reads and validates every registered manifest before touching a process, then re-registers added, changed, and removed projects and services. An invalid manifest returns SG0301 and leaves the running workloads unchanged. Configuration sections version Required . Specifies the configuration schema version. The current schema is 2 . Older version: \"1\" manifests are no longer accepted. For a legacy singular- project: manifest, run sysg migrate , which converts the shape and emits version: \"2\""},{"id":"/docs/how-it-works/projects","route":"/docs/how-it-works/projects","section":"docs","group":"How It Works","title":"Projects","description":"","headings":"Declaring a project · -p/--project vs -c/--config · How -p relates to sysg restart · Qualified service selectors · -p per command","text":"Projects A project is a durable namespace that groups a set of services. Its identity is its id — the key under the projects: map in your manifest. Because a single resident supervisor can host many projects at once — and a single config file can declare many projects — projects are how systemg keeps unrelated (or related) workloads cleanly separated inside one running daemon. One supervisor, many projects. You can run a database stack, a web API, and a batch of cron units as three independent projects under the same systemg process. They share the runtime but keep separate state, logs, and status — and you target each one by id with -p/--project . Declaring a project Projects live under the projects: map, keyed by id. One file can declare many: Each key is the project id. Start the whole file and all its projects boot; the first project becomes the primary and the rest register behind it. See Configuration for the full schema. Treat the project id as durable runtime identity. Changing it does not rename a project — it creates a new namespace, and the old one's running services become orphaned state (visible under sysg status --all ). Rename freely with name ; never rename by editing the id. Top-level services: with no project form a loose bundle — they still run, and their state persists under projects/ loose / . The older singular project: block still parses (with a deprecation warning) for existing single-project manifests; convert them with sysg migrate . Prefer the projects: map once more than one project shares a supervisor. -p/--project vs -c/--config These two flags answer different questions, and knowing which to reach for is the single most useful thing about projects. Flag What it does ------ -------------- -c / --config Loads and registers the config file on disk — every project it declares , plus any loose bundle. Use it the first time you start, or when you want to reload the manifest from a specific path. -p / --project Targets a single project already registered with the running supervisor, by its id. No file path required. The mental model: -c is bring this file's projects into the supervisor from disk ; -p is act on one project the supervisor already knows about . -c operates on the file as a whole. sysg status -c stack.yaml shows every project the file declares, not just the first — the file identifies \"everything here,\" and -p narrows to one. Every registered project stores the config path it was started from. That's why -p alone is enough for later commands — systemg looks up the project's recorded manifest for you. This is what makes multi-project workflows ergonomic: you register once with -c , then drive everything by -p . How -p relates to sysg restart restart -p is where the stored config path pays off: When --config is omitted, restart --project reuses the config path the supervisor already recorded for that project and reloads it from disk. Manifest changes are applied on reload: - services added since the last load st"},{"id":"/docs/how-it-works/cron","route":"/docs/how-it-works/cron","section":"docs","group":"How It Works","title":"Cron","description":"","headings":"Configuration · Format · Notes · Examples · Status","text":"Cron Schedule recurring tasks with cron expressions. Configuration Format 6-field cron: second minute hour day month weekday Notes - Cron jobs are short-lived (run and exit) - restart policy is ignored for cron units; each run is scheduled, not supervised - Overlap detection prevents duplicate runs - Cron units are scheduled by the supervisor, not run as persistent services. Unlike services, they cannot be started or restarted directly with sysg start -s or sysg restart -s — both return SG0101 . To (re)schedule a cron unit, reload or restart its project so the supervisor re-reads the manifest. A project restart does not run the unit immediately. A cron row marked Failed or Failing means its most recent run failed . The scheduler remains active and will run it again at the next scheduled time. A later successful run replaces that health verdict; use sysg inspect -s for run history and sysg logs -s for output. Examples Status"},{"id":"/docs/how-it-works/hooks","route":"/docs/how-it-works/hooks","section":"docs","group":"How It Works","title":"Hooks","description":"","headings":"Events · Configuration · Execution · Behavior · Tips","text":"Hooks Run any shell command after a successful service start or unsuccessful service exit. Events Hook When ------ ------ onstart Service reaches readiness or a one-shot completes successfully onerr Service exits unsuccessfully before or after readiness Configuration Hooks inherit service environment variables. Execution - Run via sh -c - Fire-and-forget (no retries) - Timeout kills with SIGKILL - Failures logged but don't affect service Behavior Scenario Hooks ---------- ------- Start and readiness success onstart Successful one-shot completion onstart Spawn or readiness failure while running None Clean exit None Manual stop None Unsuccessful exit before or after readiness onerr Successful automatic restart onstart Tips - Keep commands short - Use env vars for secrets - Make repeated actions idempotent"},{"id":"/docs/how-it-works/state","route":"/docs/how-it-works/state","section":"docs","group":"How It Works","title":"State","description":"","headings":"Location · Structure · Key files · pid.xml · confighint · state.xml · cronstate.xml · Persistence · See also","text":"State Runtime files systemg uses to track services. Location ~/.local/share/systemg/ (user mode) /var/lib/systemg/ (system mode with --sys ) Structure Supervisor-wide files live at the root. Everything a project persists — its PID map, service state, and cron history — is nested under its own directory, keyed by project.id : All XML artifacts are written as nested, two-space-indented documents. Compact XML written by older releases remains readable. Each project owns its directory. A project's monitor, PID map, and state file only ever touch projects/{project.id}/ — so two projects that both declare a service named worker keep entirely separate records, and one project's status can never leak into another's. Isolation is structural, not a convention we remember to honour. Services declared at the top level of a manifest — with no project — persist under projects/ loose / . See Projects for how loose services and named projects coexist in one supervisor. Key files pid.xml Maps a project's services to process IDs: config hint Stores the last config path for commands that need a config-backed project context. sysg status does not require this hint when a supervisor is running; it asks the supervisor for the aggregate status view. state.xml Tracks service status, restart counts, and exit codes — keyed by service configuration hash, scoped to the project directory. cron state.xml Per-project cron run history. Each project's scheduled jobs persist here; a shared scheduler loop routes every run to its own project's file. Persistence State survives supervisor restarts. A supervisor crash may leave service processes alive, but they are unsupervised until systemg recovers ownership; they cannot restart or enforce dependencies while no supervisor is running. Clean shutdown removes sysg.pid , control.sock , and config hint . Stale files after crash? Run sysg purge . Upgrading from v0.54.x or older requires sysg purge first. The per-project projects/{project.id}/ layout replaces the older flat pid.xml / state.xml / cron state.xml that lived directly under the state directory. There is no automatic migration of the old flat files — stop your services, run sysg purge , then start on the new release. See also - purge - Clear all state - Projects - How one supervisor hosts many projects - How It Works - Architecture overview"},{"id":"/docs/how-it-works/logs","route":"/docs/how-it-works/logs","section":"docs","group":"How It Works","title":"Logs","description":"","headings":"What's logged · Location · Service output configuration · View logs · Log levels · Log format · Common messages · Service events · Cron events · Supervisor events · Supervisor log rotation · Troubleshooting · See also","text":"Logs systemg writes internal operational logs and captures service stdout/stderr by default. What's logged - Service lifecycle (start, stop, restart, crash) - Cron job execution - Configuration changes - Supervisor events Location ~/.local/share/systemg/logs/supervisor.log (user mode) /var/log/systemg/supervisor.log (system mode) Service output is isolated by project: - ~/.local/share/systemg/logs/{project}/{service}.log (user mode) - /var/log/systemg/{project}/{service}.log (system mode) By default, systemg pipes each managed service's stdout and stderr into reader threads, then writes both streams through one per-service writer into {service}.log . sysg logs reads that stored file; it does not attach to the original process streams. Info: The default service log is stacked in capture order. Each line gets a systemg UTC capture timestamp plus a stream label, such as stdout or stderr , so sysg logs --kind stderr can filter lines without needing a second stderr file. Service output configuration Default log size cap. Each service's active log file rotates at 10 MB ( max bytes , 10485760 bytes), and systemg keeps 5 rotated files ( max files ) per log. So a single service's captured output is bounded to roughly 60 MB on disk (1 active + 5 rotated) before the oldest is dropped. Raise or lower these with a logs block; set sink: none to capture nothing. Use the top-level logs block to set defaults for all services: Use a service-level logs block to override the global defaults: Supported sinks: - file - Capture stdout/stderr and write systemg-managed log files. - none - Discard stdout/stderr without creating log-writer threads or files. max bytes controls active file rotation for the file sink. max files controls how many numbered rotated files are retained. Set sink: none for high-output services when another logging pipeline is already responsible for collection. View logs Log levels Set verbosity when starting: Levels: trace (5), debug (4), info (3), warn (2), error (1), off (0) Log format Format: [TIMESTAMP] [LEVEL] [MODULE]: [MESSAGE] Common messages Service events Cron events Supervisor events Supervisor log rotation The supervisor log uses the supervisor.xml log defaults: a 10 MB active-file limit and five rotated files unless changed by the operator. Services can override those defaults in their project manifest. No external rotator is required. The system installer also writes /etc/logrotate.d/systemg with copytruncate . Do not rename an active supervisor log by hand: an open writer can continue writing to the renamed file. Troubleshooting Log file missing - Check systemg has started - Verify directory exists Empty logs - Try --log-level debug - Check services are running Large log files - Configure service log rotation with logs.max bytes and logs.max files - Prune rotated backups with sysg logs --prune --max-size or --max-age - Reduce log level See also - logs - View service output - status - Check service health"},{"id":"/docs/kernel-mode","route":"/docs/kernel-mode","section":"docs","group":"Kernel Mode","title":"Kernel Mode","description":"","headings":"The capability family · Mode parity contract · Security","text":"Kernel Mode Kernel mode is systemg operating below the user session: as the machine's service supervisor, as a container's init process, and against kernel enforcement and observation interfaces. The sysg supervisor is a userspace program. No systemg code executes in ring 0. \"Kernel mode\" names the family of capabilities where the kernel — not the user session — is the counterparty. The capability family Capability What executes where Status --- --- --- System mode Userspace, root; drops privileges per service Linux and macOS ( --sys ) Container-init Userspace, PID 1 duties Linux ( sysg init ) Kernel-enforced sandboxing Kernel enforces; sysg configures Linux, schema v3 Kernel-assisted observation pidfd Linux 5.3+ Mode parity contract User mode and system mode are peers: identical commands, identical output shapes, identical diagnostics wherever a capability is supported — and a refusal, never a warning that proceeds, where it is not. The parity contract is enforced by the parity- use-case lanes, which run every scenario as a real non-root user and as root --sys on both glibc and Alpine/musl runtimes. Security See Security & audits for the threat model and the per-milestone audit records in the repository."},{"id":"/docs/kernel-mode/how-sysg-meets-the-kernel","route":"/docs/kernel-mode/how-sysg-meets-the-kernel","section":"docs","group":"Kernel Mode","title":"How sysg Meets the Kernel","description":"","headings":"Reading the diagram","text":"How sysg Meets the Kernel The sysg supervisor is a userspace program. Kernel mode is the set of kernel interfaces it calls — no sysg code runs in ring 0. This diagram shows which interface each capability uses to cross the userspace→kernel boundary, and how the same manifest is enforced on Linux versus refused on macOS. One manifest · two platforms Linux (system mode, --sys) macOS (system mode, --sys) USERSPACE sysg supervisor (root) parses manifest · builds plan in parent sysg supervisor (root) parses manifest · builds plan in parent forked child (pre-exec) no new privs → Landlock → seccomp → exec launchd RunAtLoad bootstraps sysg (KeepAlive off) boots fork KERNEL syscall boundary cgroups v2 limits · post-spawn pidfd instant exit wake Landlock LSM filesystem confine seccomp-bpf syscall allowlist configures / installs no Linux LSM / cgroup / pidfd container-init, seccomp, Landlock: refused (see SG codes below) refused above the boundary On Linux, the supervisor builds each policy in the parent and the forked child installs it in a fixed order ( no new privs → Landlock → seccomp) before exec ; cgroups attach post-spawn and pidfd wakes the monitor on exit. On macOS the same manifest keys have no kernel mechanism to call, so they are refused with a diagnostic rather than silently ignored, and launchd only bootstraps the supervisor. Reading the diagram - Green paths (Linux) are the kernel interfaces sysg actually calls: cgroup v2 for limits, pidfd for instant exit detection, Landlock for filesystem confinement, and seccomp-bpf for syscall filtering. The child installs the confinement steps in a fixed order immediately before exec . - Red paths (macOS) stop at the syscall boundary: those Linux mechanisms do not exist, so requesting them is a refusal (SG0711, SG0721, SG0722, SG0724) — the mode-parity contract: identical behavior where a capability exists, a refusal where it does not. - The supervisor never enters the kernel itself. It configures kernel mechanisms; the kernel enforces."},{"id":"/docs/kernel-mode/system-mode","route":"/docs/kernel-mode/system-mode","section":"docs","group":"Kernel Mode","title":"System Mode","description":"","headings":"Runtimes · Running services as other users · Boot integration (systemd) · Boot integration (macOS launchd) · Operator access","text":"System Mode System mode ( --sys ) runs one root-owned supervisor for the machine's services, with per-service privilege drops. It is the same sysg with the same commands — only the runtime it targets changes. Runtimes User mode System mode — Linux System mode — macOS --- --- --- --- State ~/.local/share/systemg/ /var/lib/systemg/ /Library/Application Support/systemg/ Logs ~/.local/share/systemg/logs/ /var/log/systemg/ /Library/Logs/systemg/ Config search ~/.config/systemg/ /etc/systemg/ /Library/Application Support/systemg/etc/ Boot integration — systemd unit launchd daemon Owner invoking user root root System mode uses each platform's native locations: the FHS on Linux, the /Library hierarchy on macOS where launchd — not systemd — owns system daemons. --sys is always explicit. sysg never guesses the runtime from your EUID or from what exists on disk — it tells you when the modes cross: - SG0701 — running as root without --sys : warns that state will land in root's user-mode paths. - SG0702 — system-mode state exists but the command targets the user runtime: refuses rather than touch the wrong supervisor. - SG0704 — --sys without root: refused. Running services as other users The identity drop is strictly ordered — rlimits, capability trimming, setgroups → setgid → setuid , ambient caps — with supplementary groups always reset before the UID switch and the environment cleared and rebuilt for the target account. Namespace unshare failures can warn and proceed (EPERM under nested containers), and cgroup attach happens post-spawn; see Sandboxing for what is and is not enforced. Boot integration (systemd) scripts/install-systemg.sh installs /etc/systemd/system/sysg.service . Every sysg invocation in a unit must carry --sys — including ExecStop : Every sysg self-exec (supervisor boot, live upgrade, recycle) forwards the mode across the exec boundary; the parity-supervisor-recycle lane guards this invariant. Boot integration (macOS launchd) scripts/install-systemg.sh on macOS installs a launchd daemon at /Library/LaunchDaemons/dev.sysg.supervisor.plist : launchd bootstraps; sysg supervises. The plist sets KeepAlive: false . launchd starts sysg once at boot ( RunAtLoad ); sysg then owns every service's lifecycle, restarts, and health, exactly as on Linux. Letting launchd also restart sysg would be double supervision with conflicting restart policies. macOS system mode is boot integration plus native paths. The Linux-only kernel mechanisms — container-init, seccomp, Landlock, cgroups, namespaces — are refused with a diagnostic rather than silently ignored. Operator access The control socket is owned by root with 0600 permissions and kernel peer credentials checked on every connection. In system mode this means all control — including status and logs — requires root ( sudo ). Finer-grained read-only access is not currently offered."},{"id":"/docs/kernel-mode/container-init","route":"/docs/kernel-mode/container-init","section":"docs","group":"Kernel Mode","title":"Container-Init (PID 1)","description":"","headings":"What PID 1 changes · Diagnostics · Known constraint","text":"Container-Init (PID 1) sysg init runs systemg as a container's PID 1 on linux-gnu and linux-musl (Alpine is a first-class target), replacing tini/s6/supervisord combinations with one supervisor that already owns lifecycle, logs, and diagnostics. sysg init requires that the process actually is PID 1 and implies system mode. It boots the manifest, reaps adopted orphans, handles shutdown signals, and exits with the teardown verdict. What PID 1 changes PID 1 inherits every orphaned process in the container and must reap them; default signal dispositions differ; shutdown means tearing down every service in reverse dependency order and exiting with a meaningful status. All wait statuses route through a centralized broker, so an adopted orphan's exit is never mistaken for a managed service's. Diagnostics - SG0711 — container-init unsupported on this platform (e.g. macOS) - SG0712 — PID 1 prerequisites missing (e.g. /proc not mounted) - SG0713 — shutdown incomplete: services survived reverse-order teardown - SG0714 — live supervisor upgrade refused in container-init mode Known constraint Live supervisor upgrade is forbidden in container-init mode: a failed exec in PID 1 kills the container and everything in it. Upgrade the image instead."},{"id":"/docs/kernel-mode/sandboxing","route":"/docs/kernel-mode/sandboxing","section":"docs","group":"Kernel Mode","title":"Kernel-Enforced Sandboxing","description":"","headings":"Limits, capabilities, and namespaces · Syscall and filesystem confinement (schema v3) · Keys that do not enforce · Diagnostics","text":"Kernel-Enforced Sandboxing sysg configures kernel enforcement mechanisms per service: rlimits, capabilities, namespaces, cgroups, seccomp, no new privs , and Landlock. All of them are Linux, root, and enforced by the kernel — sysg only configures them. Limits, capabilities, and namespaces Syscall and filesystem confinement (schema v3) Under version: \"3\" : - isolation.landlock: { ro paths, rw paths } — a Landlock filesystem sandbox (Linux 5.13+). Paths not listed become inaccessible. - isolation.seccomp: \"baseline-v1\" — a frozen, deny-by-default syscall allowlist; unlisted syscalls return EPERM . no new privs is set alongside. An unsupported kernel or a malformed policy refuses the service (SG0722/SG0724) rather than running it unprotected. baseline-v1 is frozen; a different or stricter policy will ship as baseline-v2 , never as a silent edit. Keys that do not enforce isolation.apparmor profile , isolation.selinux context , isolation.private devices , and isolation.private tmp are accepted by the schema but run the service unenforced . Treat them as documentation, not protection. Deprecation window. Each of these keys emits SG0721 at service start. A future release refuses them instead of running unprotected, behind a manifest schema bump. Remove the keys or plan for the refusal. Diagnostics - SG0721 — a security key was accepted but cannot be enforced; the service runs unprotected - SG0722 — seccomp filter could not be built, compiled, or applied; service refused - SG0723 — no new privs could not be set; service refused - SG0724 — Landlock requested but the kernel ABI is unavailable or insufficient; service refused - SG0725 — unknown seccomp profile; the only built-in is baseline-v1 - SG0726 — seccomp is unsupported on this CPU architecture"},{"id":"/docs/kernel-mode/kernel-assisted","route":"/docs/kernel-mode/kernel-assisted","section":"docs","group":"Kernel Mode","title":"Kernel-Assisted Observation","description":"","headings":"Why pidfd and not eBPF · Known limitation","text":"Kernel-Assisted Observation sysg observes service lifecycle with pidfd on Linux: at spawn it opens a pidfd for the service, and the monitor poll() s those descriptors, so a process exit wakes supervision instantly rather than at the next poll tick. waitpid remains authoritative for reaping; the pidfd only supplies readiness. This needs Linux 5.3+, no elevated capabilities, no kernel BTF, and adds no dependencies to the supervisor. Why pidfd and not eBPF sysg does not ship eBPF process-event observation. It buys nothing over pidfd here: - Exit detection is already instant. pidfd wakes the monitor the moment a managed service exits; the sched process exit tracepoint adds nothing. - Descendants are already tracked. Service process trees are owned via their private session (SID), the generational provenance ledger, and — when sysg is PID 1 — the wait broker. eBPF's fork/exec lineage is redundant for the processes sysg manages. - The one residual gap is not reliably closable by eBPF. A service that fork() s, calls setsid() , and re-parents into a new session leaves sysg's tree. Tracepoint events are advisory and lossy: after a dropped fork event, /proc cannot reconstruct ownership. cgroup v2 is the authoritative boundary for containing escaped descendants, not tracepoint lineage. - The cost is real. eBPF adds the Aya dependency tree to the root supervisor's trust base, requires CAP BPF / CAP PERFMON and kernel BTF at /sys/kernel/btf/vmlinux , and fails to load on minimal musl-static containers — a larger root attack surface for a narrow, unreliable gain. Known limitation sysg supervises the process it spawns and the private session that process retains. A service that deliberately escapes into a new session (double-fork + setsid ) and outlives its launcher is not tracked. Run services in the foreground and let sysg own the process rather than self-daemonizing."},{"id":"/docs/kernel-mode/security","route":"/docs/kernel-mode/security","section":"docs","group":"Kernel Mode","title":"Security & Audits","description":"","headings":"Trust boundary · Standing mitigations · Audit records","text":"Security & Audits A root supervisor is worth attacking. Kernel mode's security posture is recorded in the repository, where you can check it: a threat model, a generated unsafe inventory, and a per-milestone audit trail. Trust boundary Trusted: the manifest (operator-controlled — its commands are intended execution) and a same-UID or root socket peer. Untrusted: everything else — socket frame contents, service names, IPC-supplied config paths, filesystem state in service-writable directories, and, in system mode, every non-root local user. The full model is audits/threat-model.md . Standing mitigations - Control socket: 0700 runtime dir, 0600 socket, kernel peer credentials ( SO PEERCRED / getpeereid ) verified on every accept, before any read - IPC frames: 1 MiB cap, typed decode, fuzzed on a weekly CI schedule ( fuzz/fuzz targets/ipc frame.rs ) - Config: O NOFOLLOW open + same-fd fstat + parse (no TOCTOU window) - Privilege drops: ordered transaction; supplementary groups always reset; environment cleared and rebuilt - Descriptors: FD CLOEXEC by default; handoff FDs cleared briefly and restored - Identity: PID + start time + session; no signal is ever sent on the basis of command-string matching Audit records Record What it is --- --- audits/README.md Audit policy and index audits/threat-model.md Living threat model audits/unsafe-inventory.md Generated unsafe inventory reports/ Historical security reviews No formal release-candidate audit has been published yet. reports/ holds the security reviews done so far, and audits/ holds the threat model and the generated unsafe inventory that any future audit starts from. Supply-chain gates do run in CI on every change: cargo audit , cargo deny , and cargo vet , whose exemption baseline is frozen so new dependencies must be vetted. The canonical trust model for all of systemg remains Security; this page covers what kernel mode adds."},{"id":"/docs/security","route":"/docs/security","section":"docs","group":null,"title":"Security","description":"","headings":"Trust model · Guarantees at the boundary · Confining a service · Deployment guidance · On the roadmap · Reporting and audits · See also","text":"Security systemg spawns and supervises arbitrary processes, often as root in system mode. That makes it a high-value target for local privilege escalation, so we treat it like one. This page states the trust model explicitly, documents the guarantees at each privilege boundary, and lists the knobs you use to confine services. Trust model Two things are trusted by design: - The config file. Commands, users, and health-check URLs in it are intended execution. If you can write the config, you can already run code as whoever runs the supervisor — that's the point of a supervisor, not a vulnerability. - A same-UID caller of the control socket. The socket is owner-only ( 0600 ) inside an owner-only ( 0700 ) directory, and every connection is authenticated with SO PEERCRED / getpeereid . Only the supervisor's own user (and root, which can bypass any check anyway) may issue commands. Everything else is untrusted and is where we spend our effort: the control socket and its IPC protocol, filesystem permissions, and every cross-privilege boundary — privilege dropping, capabilities, namespaces, cgroups, inherited file descriptors, signal delivery, and environment handling. Guarantees at the boundary These hold with no configuration on your part. Authenticated control channel. The control.sock peer UID is checked on every accept; connections from other local users are rejected before any command is read. A single framed command is capped (1 MiB) so one connection can't exhaust supervisor memory. Owner-only runtime state. State and log directories are created 0700 ; the socket, PID file, and config hint are 0600 . Service topology, PIDs, and config paths are not readable by other local users. Race-free config loads. Configs supplied over the socket ( restart --config , project add) are opened once with O NOFOLLOW and validated on the open descriptor ( fstat ) — the file that passes the ownership/permission check is the exact file that's parsed and executed. No stat-then-reopen window, no symlink swap. Group/other-writable or foreign-owned configs are refused. Correct privilege drop. Before exec , a dropped service goes through: namespace unshare → rlimits → nice/affinity → capability trim → setgroups / setgid / setuid → ambient caps. Supplementary groups are always reset on a UID switch, so a service dropped to nobody does not retain root's docker / wheel / sudo membership. Clean environment across the boundary. A service that switches user or group starts from a cleared environment by default — the supervisor's variables (secrets, LD , PATH ) do not leak into a lower-privileged child. Opt back into inheritance per service with inherit env: true . Confined dynamic spawns. Children created through the socket's spawn path inherit their parent service's privilege context — same user, caps, limits, and cgroup — so a spawn can never be more privileged than the service that authorized it. No descriptor leaks. Socket-activation FDs inherited via LISTEN FDS are marked"},{"id":"/docs/philosophy","route":"/docs/philosophy","section":"docs","group":null,"title":"Philosophy","description":"","headings":"What we optimize for · What we're not · See also","text":"Philosophy systemg exists to run a handful of related processes as one unit — with dependency ordering, restarts, and privilege dropping — without asking you to become a systemd expert or hand your app to a container runtime. What we optimize for Legible configuration. One YAML file describes your services, their order, and how they're confined. It reads like what it does. No unit-file dialect, no generated indirection, no \"where is this actually configured.\" One binary, no runtime. systemg is a single self-contained binary. There's nothing to install alongside it, nothing to keep in sync, and the same binary and config run on a laptop and in production. Dev/prod parity is the default, not a project. Correct process lifecycle. Services start in dependency order and are supervised for real: unsuccessful exits restart with backoff, process-group teardown does not orphan children, and persisted state makes ownership recoverable after a supervisor restart. Secure because it's the default, not because you configured it. A service that drops to another user starts from a clean environment with reset supplementary groups and trimmed capabilities — you don't have to remember to ask. The control socket is authenticated and owner-only. Least privilege is the path of least resistance. Honest about its boundaries. When a feature isn't implemented, systemg says so and warns — it never silently pretends a seccomp profile or namespace is in effect. The trust model is written down, and the code is audited against it. What we're not systemg is not a container runtime, an orchestrator, or a replacement for PID 1 on a full OS. It's the layer between \"a shell script with & \" and \"stand up Kubernetes\" — the right tool when you have a few services that belong together and you want them supervised, ordered, and confined, on one machine. See also - Introduction — what systemg does - Security — trust model and hardening - Configuration — define your system"},{"id":"/docs/examples","route":"/docs/examples","section":"docs","group":"Examples","title":"Examples","description":"","headings":"[Hello World](/docs/examples/hello-world) · [CRUD Application](/docs/examples/crud) · [Units](/docs/examples/units) · [Orchestrator](/docs/examples/orchestrator) · Running examples · See also","text":"Examples Working examples demonstrating systemg features. Hello World Minimal service configuration. CRUD Application Simple FastAPI CRUD service for testing systemg service management. Units Practical command-based unit examples, staged under ~/.local/share/systemg/units/ . Orchestrator Multi-agent task execution with Redis coordination and DAG scheduling. Running examples Each example includes: - Complete configuration file - Working application code - Setup instructions - Expected behavior See also - Quickstart - Quick introduction - Configuration - Full reference"},{"id":"/docs/examples/hello-world","route":"/docs/examples/hello-world","section":"docs","group":"Examples","title":"Hello World","description":"","headings":"Configuration · Script · Run it · Next steps","text":"Hello World Minimal systemg service. Configuration Script Run it You'll see: The example keeps logs.sink: file explicit so sysg logs works immediately. For high-volume services, use logs.sink: none and rely on your normal logging pipeline. status.snapshot mode: summary keeps status and inspect reads inexpensive by reading current persisted state without detailed runtime process collection. Next steps Add a restart policy to handle crashes:"},{"id":"/docs/examples/crud","route":"/docs/examples/crud","section":"docs","group":"Examples","title":"CRUD Application","description":"","headings":"Features demonstrated · Configuration · Application code · main.py · Dependencies · Run it · API endpoints · Testing · Operations · Stop the service · View logs · Check status · Example usage · Create a Todo · List Todos · Update a Todo · Test chaos endpoint · What happens · Interactive API docs · See also","text":"CRUD Application A simple FastAPI CRUD service for testing systemg service management capabilities. Features demonstrated - Service management with sysg start and sysg stop - Automatic recovery from failures - Controlled service restarts - Modern Python with FastAPI and uvicorn - Package management with uv Configuration File logging is enabled here so sysg logs --service fastapi server works out of the box. For production services whose output is already collected elsewhere, set logs.sink: none . Summary status snapshots keep sysg status and sysg inspect responsive by reading current persisted state while avoiding detailed runtime process collection per command. Application code main.py Dependencies Create pyproject.toml : Run it API endpoints - GET / - Health check - POST /todos - Create a new todo - GET /todos - List all todos - GET /todos/{id} - Get a specific todo - PUT /todos/{id} - Update a todo - DELETE /todos/{id} - Delete a todo - GET /chaos - Random failure endpoint (70% failure rate) Testing Run the test script to verify all endpoints: The test script will: 1. Create a new todo 2. Read all todos 3. Update the todo 4. Get a specific todo 5. Test the chaos endpoint (demonstrates recovery) 6. Delete the todo Operations Stop the service View logs Check status Example usage Create a Todo List Todos Update a Todo Test chaos endpoint What happens 1. Service starts with sysg start and serves the API on port 8888 2. In-memory storage using Python dict for simplicity 3. Chaos endpoint randomly fails to demonstrate recovery capabilities 4. Automatic restarts when service crashes (up to 10 restarts with 5s backoff) 5. Restarts replace the fixed-port instance; use blue-green slots when an application requires zero-downtime updates Interactive API docs FastAPI provides automatic interactive documentation at: - Swagger UI: http://localhost:8888/docs - ReDoc: http://localhost:8888/redoc See also - Configuration - Service definitions - Hello World - Simple example to get started - Orchestrator - Multi-agent task execution"},{"id":"/docs/examples/units","route":"/docs/examples/units","section":"docs","group":"Examples","title":"Units","description":"","headings":"From command to running unit · Common examples · Where staged units are stored","text":"Units A unit is the shortest path from an ad-hoc command to systemg supervision. Use one when you want systemg to manage a database tunnel, development server, watcher, script, or other command without writing a project manifest first. When --name is omitted, systemg generates a unit name from the command. Staging is translation. systemg writes your command as a generated version 2 manifest—the format its central supervisor understands for every service and project. The generated unit is project-less, so the supervisor manages it in the loose bundle. Its command runs from the directory where it was staged, even though the generated manifest lives elsewhere. From command to running unit sysg start -- always stages the command first. What happens next depends on whether a supervisor already exists: - No supervisor is running: the staged manifest starts a new supervisor and the unit runs immediately. - A supervisor is already running: systemg writes the manifest but leaves the live supervisor unchanged. The unit has been staged, but it is not yet registered and no process has started for it. The explicit apply step protects the supervisor's live topology. An ad-hoc command cannot silently add work while the supervisor is managing other services and projects. Applying the staged manifest gives systemg a clear point to validate it and reconcile it into the live state. For a resident supervisor, systemg prints the exact command required to apply the unit: Run that printed command, then inspect the unit normally: Common examples Run a shell script under supervision. Keep a lightweight HTTP server alive. Tail application logs under supervision. Run a frontend development server. Run a backend API in reload mode. Run a worker with explicit queue and concurrency settings. Run a live TypeScript watcher and build loop. Run a periodic heartbeat loop. Run a composed multi-step local pipeline. Where staged units are stored Generated unit manifests are saved under: systemg prunes manifests older than 30 days and retains the newest 200 files when it stages new units. Treat this directory as staging space. For a long-lived unit, copy its generated manifest to a durable path before applying it, then pass that path to sysg start --config . The registered path becomes the supervisor's source of truth for later restarts. Once applied, a unit's runtime state—PIDs and service lifecycle state—persists under ~/.local/share/systemg/projects/ loose / . See State."},{"id":"/docs/examples/orchestrator","route":"/docs/examples/orchestrator","section":"docs","group":"Examples","title":"Orchestrator","description":"","headings":"Overview · Architecture · Features · Files · Configuration · Agents · researchagent · DAG Format · Usage · Validation · Links","text":"Orchestrator Multi-agent task execution with cache coordination. Overview Orchestrator supervises agents that claim and execute tasks from a shared cache. Architecture Cache keys: Features - Tasks : LLM generates DAG from instructions - Locking : Time-limited task leases - States : BLOCKED → READY → RUNNING → DONE/FAILED - Control : Heartbeat files accept PAUSE , RESUME , DROP-TASK , etc. - Spawning : Each agent gets instruction file, heartbeat, goal ID Files Configuration systemg.yaml: The orchestrator example disables systemg-managed service output capture because agent workloads can be noisy. Use your regular logging pipeline for production agent output, and reserve sysg logs for services that opt into logs.sink: file . Summary status mode avoids expensive process tree discovery across many dynamic children while status and inspect still read current persisted state. PORKI LLM MAX CONCURRENCY raises the number of global LLM leases available across agents, and PORKI LLM CONCURRENCY WAIT SECONDS controls how long agents wait for a lease before timing out. instructions/INSTRUCTIONS.md: DAG Format Usage Validation Use sysg status and Redis keys to validate runtime behavior. Package-level runtime tests execute in the porki repository. Links - Configuration - How It Works"},{"id":"/docs/integrations/claude-code","route":"/docs/integrations/claude-code","section":"docs","group":"Integrations","title":"Claude Code","description":"","headings":"What you get · Install · Updating · Using the skill · See also","text":"Claude Code systemg ships an official Claude Code plugin and skill so coding agents can drive sysg correctly — writing valid manifests, starting and inspecting stacks, and reading logs — without you pasting docs into every session. The plugin is distributed from a self-hosted marketplace in the systemg repository, so you install it straight from GitHub. What you get - A plugin ( systemg ) that registers the systemg skill with Claude Code. - A skill that teaches Claude the sysg CLI, the YAML config schema, deployments, cron units, and log inspection — including the agent-friendly --plain conventions. Install Add the marketplace, then install the plugin: /plugin marketplace add ra0x3/systemg points Claude Code at the .claude-plugin/marketplace.json at the repository root; /plugin install systemg installs the plugin from it. You can also browse and install interactively from the /plugin menu once the marketplace is added. Updating The plugin version is kept in lockstep with the systemg release. CI stamps .claude-plugin/plugin.json with the crate version from Cargo.toml on every release, so the marketplace always advertises the current version. Refresh the marketplace to pick up new releases: Claude Code surfaces available updates for installed plugins, so in practice you are prompted to update rather than having to check by hand. Using the skill Once installed, the skill activates automatically whenever you ask Claude to work with systemg — for example: - \"Write a sysg.yaml for a Postgres + API stack with a health check.\" - \"Start this stack and show me the status as JSON.\" - \"Tail the api service logs and grep for errors in the last hour.\" Under the hood the skill instructs Claude to use --plain in non-interactive contexts, to prefer --format json for parsing, and to run sysg validate before starting a stack so config mistakes are caught early with precise, fixable diagnostics. See also - Commands - Full CLI reference - validate - Check a manifest before running it - Configuration - Manifest schema - Plugin source on GitHub"},{"id":"/reference/configuration","route":"/reference/configuration","section":"reference","group":"Configuration","title":"Configuration","description":"","headings":"Complete example · Supervisor configuration · Registered manifests · Configuration sections · version · projects · env · logs · status · metrics · services · !include · Service configuration · command · exec · workingdir · dependson · env · restartpolicy · Service logs · hooks · cron · deployment · Field reference · Service fields · Environment object · Hooks object · Health check object · Durations · Deployment object · Blue/green deployment object","text":"Configuration systemg uses YAML files to define services and their relationships. Complete example A single file can declare many projects under the projects: map, keyed by project id. The example below shows one project's full set of sections. Project entries may override env and logs ; top-level metrics and status settings apply across the loaded projects. Supervisor configuration Project manifests describe workloads. Supervisor-wide defaults live separately in ~/.local/share/systemg/supervisor.xml , or /var/lib/systemg/supervisor.xml with --sys : - pre start secs : default execution budget for deployment pre start commands. - startup stability ms : survival window for services without a health check. - stop verify secs : time allowed to confirm that a terminated process is gone. - start settle secs : maximum wait for an unresolved queued project start. - command wait secs : how long a CLI command waits for the supervisor's reply before reporting SG0111. 0 waits indefinitely. Raise it when a project is large enough that a restart runs longer than the default; the command is never cancelled by the wait ending. - max concurrent : how many services a bulk start runs at once. -1 (the default) starts every service whose dependencies have resolved, 1 starts one service at a time, and any other positive number is a cap. Applies to sysg start and to project boot; restart remains one service at a time. The file is created on first supervisor start. Existing compact XML remains compatible and is rewritten in the indented form after it parses successfully. SYSG PRE START TIMEOUT SECS remains a higher-precedence compatibility override. Health-check attempt timeout and total timeout remain in the project manifest because readiness is workload-specific. The IPC poll slice, liveness probe window, unresponsive grace and live-upgrade deadlines are protocol invariants and are not operator settings. Registered manifests When you run a command with -c , the resident supervisor remembers that manifest's resolved path for each project it registers. Later commands can omit -c and target the registered project from any working directory. Ad-hoc units use the same manifest pipeline. sysg start -- first stages the command as a generated version 2 manifest. If a supervisor is already running, that file is not registered or started until you run the explicit sysg start --config ... command systemg prints. See Units. sysg restart treats the files at those paths as the source of truth. It reads and validates every registered manifest before touching a process, then re-registers added, changed, and removed projects and services. An invalid manifest returns SG0301 and leaves the running workloads unchanged. Configuration sections version Required . Specifies the configuration schema version. The current schema is 2 . Older version: \"1\" manifests are no longer accepted. For a legacy singular- project: manifest, run sysg migrate , which converts the shape and emits version: \"2\""},{"id":"/reference/commands","route":"/reference/commands","section":"reference","group":"Commands","title":"Commands","description":"","headings":"Quick reference · Global flags · Supervisor status · Daemon mode · Service-specific operations · See also","text":"Commands Quick reference Deprecated sysg spawn is deprecated. Use sysg start --parent-pid ... for child-process workflows. ::: Global flags Every command accepts: Flag Description ------ ------------- --log-level Set verbosity for this invocation ( trace , debug , info , warn , error , off , or 5-0) -v , --verbose Print live operation progress --plain Agent-friendly output: disable color, banners, paging, and implicit log following --sys Opt into privileged system mode (requires root) --drop-privileges Drop child privileges during start / restart ; accepted but ignored by commands that do not spawn services --plain is equivalent to setting SYSTEMG AGENT=1 , and is also implied when SYSTEMG AGENT or NO COLOR is set in the environment. Use it for scripts, pipes, SSH commands, and coding agents so status , inspect , and logs emit plain, un-truncated, non-blocking output. Supervisor status sysg status talks to the running supervisor and shows all registered projects. Use filters to narrow the view: Daemon mode Run supervisor in background: Service-specific operations Most commands accept a service name: See also - Configuration - Define services - Quickstart - First steps"},{"id":"/reference/commands/start","route":"/reference/commands/start","section":"reference","group":"Commands","title":"start","description":"","headings":"Options · Examples · Start with default configuration · Start with specific configuration · Foreground mode · Daemon mode · Debug mode · Capture stderr in foreground · Unit mode (no config file) · Child mode for orchestrators (replacement for spawn) · What happens · Startup order · See also","text":"start Launch managed processes in one of three modes: - manifest services ( sysg start ) - units ( sysg start ) - child units ( sysg start --child --parent-pid -- ) Options Short Long Description ------- ------ ------------- -c --config Path to the configuration file. If not specified, systemg looks for systemg.yaml or sysg.yaml in the current directory -s --service Optionally start only the named service instead of all services -p --project Target a stable project id when a supervisor manages multiple projects - --name Optional name for units or child-start units - --daemonize Run the supervisor as a background daemon - --parent-pid Run start in child mode by attaching the process to a parent service PID - --ttl Optional time-to-live in seconds for child mode - --child Explicit child-mode marker. Requires --parent-pid - --sys Opt into privileged system mode. Requires running as root - --drop-privileges Drop child service privileges during spawn. In root/system mode, services without an explicit user run as nobody - --stderr Pipe stderr output from supervised processes to stdout in foreground mode -v --verbose Print per-service boot progress - --plain Disable terminal decoration and accidental log following for automation - --log-level Set logging verbosity for this invocation. Accepts named levels ( trace , debug , info , warn , error , off ) or numeric values (5-0) The --stderr flag is particularly useful for: - Development : See error output immediately while debugging - CI/CD Pipelines : Capture all output in a single stream - Real-time Monitoring : Watch for errors as they happen Note: This flag only affects foreground mode. In daemonized mode, stderr is written to log files when the service uses logs.sink: file . ::: Examples Start with default configuration Looks for systemg.yaml or sysg.yaml in the current directory. Start with specific configuration Foreground mode Without --daemonize , the terminal attaches to the selected project. Boot progress updates in place, and output from every running service is multiplexed with a per-service prefix. Ctrl-C stops only that project and returns the terminal; the resident supervisor and other projects remain running. Daemon mode Start without retaining a terminal attachment. The command returns after the project reaches its target state; subsequent commands use the same resident supervisor. Check if the daemon is running: Debug mode See detailed output during startup: Capture stderr in foreground Useful for development and debugging: Output identifies the service and captured stream: Unit mode (no config file) Unit mode is for ad-hoc commands you want systemg to manage without writing a project manifest first: systemg stages the command by translating it into a generated version 2 manifest—the common format the central supervisor understands for services and projects. With no supervisor, the staged manifest starts a supervisor and the unit runs immediately. With a resident supervisor, staging does "},{"id":"/reference/commands/stop","route":"/reference/commands/stop","section":"reference","group":"Commands","title":"stop","description":"","headings":"Options · Examples · Stop the current project · Stop a project from a config · Stop a registered project · Stop a specific service · Shut down the supervisor · What happens · Reloading a manifest after stop · See also","text":"stop Stop services for a project, service, or the entire supervisor. Options Short Long Description ------- ------ ------------- -c --config Path to the configuration file. When a supervisor is running, systemg uses it to resolve the target project. Without a supervisor, systemg uses it to locate persisted service state -s --service Name of a specific service to stop. If not specified, all services are stopped -p --project Target a stable project id when stopping services - --supervisor Shut down the resident supervisor and all registered projects -v --verbose Print per-service operation progress - --sys Opt into privileged system mode. Requires running as root - --drop-privileges Accepted globally but ignored; stop does not spawn services - --plain Disable terminal decoration for automation - --log-level Set logging verbosity for this invocation. Accepts named levels ( trace , debug , info , warn , error , off ) or numeric values (5-0) Examples Stop the current project By default, stop is project-scoped. It resolves the current config context and stops the services for that project. Stop a project from a config Stop a registered project Stop a specific service Leaves other services running. For multi-project supervisors, combine project and service selectors: Shut down the supervisor This stops every registered project and exits the resident supervisor. After this, plain sysg status reports No running supervisor . What happens 1. Services stop in reverse dependency order 2. Each service receives SIGTERM 3. After a short grace period (about 1 second), SIGKILL is sent if needed 4. The supervisor remains available unless you used --supervisor When stopping a single service manually, its dependents keep running. A dependency crash temporarily stops its dependents; after the dependency recovers, the supervisor starts eligible dependents again. Reloading a manifest after stop Stopping a project does not freeze its old unit definitions. Running sysg stop --project followed by sysg start --config reloads the project from the supplied config, so manifest changes (added or removed services, changed commands) are applied on the next start. To reload in place without a stop, use restart --project , which reuses the project's stored config path. See also - start - Launch services - restart - Restart services"},{"id":"/reference/commands/restart","route":"/reference/commands/restart","section":"reference","group":"Commands","title":"restart","description":"","headings":"Options · Examples · Restart all services · Restart specific service · Restart with new configuration · Restart a project and reload its stored manifest · Cron units · Deployment strategies · See also","text":"restart Restart services or reconcile manifest changes without disturbing unrelated workloads. Do not use restart to apply a sysg upgrade. Run the installer again; on compatible releases it performs a same-PID live re-execution without restarting services. Incompatible releases are refused until the supervisor is stopped. A manually replaced PATH binary can still leave version drift. A full sysg restart --daemonize retains the legacy stop-and-rebuild recovery path; scoped restarts ( -s / -p ) only report the drift. The recycle transfers supervision, not just the processes. After a version-drift restart, your services stop being managed by the old supervisor and start being managed by the new one: the old daemon is stopped, a fresh daemon boots on the installed binary, and it actively supervises the re-spawned services — a crash after the upgrade is respawned by the new supervisor, exactly as before. If the replacement config fails to validate, the recycle is refused ( SG0303 ) and the working stack is left untouched. Options Short Long Description ------- ------ ------------- -c --config Path to the configuration file. When specified, reloads the configuration and restarts all services with the new settings -s --service Name of a specific service to restart. If not specified, all services are restarted -p --project Target a stable project id when restarting services - --daemonize Start the supervisor first if none is running. No effect on supervision when one already is -v --verbose Print per-service operation progress - --sys Opt into privileged system mode. Requires running as root - --drop-privileges Drop child service privileges during spawn. In root/system mode, services without an explicit user run as nobody - --plain Disable terminal decoration for automation - --log-level Set logging verbosity for this invocation. Accepts named levels ( trace , debug , info , warn , error , off ) or numeric values (5-0) --daemonize only matters when no supervisor is running. It decides how a restart recovers from a missing daemon, not how services are supervised afterward. - No supervisor running. Without the flag, the restart runs as a local one-shot and leaves the box unsupervised. With it, systemg starts a supervisor and restarts under it. - Supervisor already running. Both forms send the identical restart to the resident supervisor. Services stay daemonized either way, so passing --daemonize to an already-daemonized stack changes nothing about the result. A version-drift recycle is also decided before the flag is read, so it behaves the same with or without it. The flag is not free, though. A plain restart watches the operation, prints the progress tree, and waits for the real outcome. --daemonize sends fire-and-forget on a 250 ms acknowledgement and treats \"accepted\" as success — so it can exit 0 on a restart that fails moments later, and it prints no progress tree. Examples Restart all services Restart specific service Restart with new configuration"},{"id":"/reference/commands/logs","route":"/reference/commands/logs","section":"reference","group":"Commands","title":"logs","description":"","headings":"Options · Scoping · Modes · Examples · View one project's service logs · View logs from specific service · Follow mode and non-interactive callers · Purge logs for a specific service · Purge logs for all services · View stderr logs · View supervisor logs · Show more history · Filter by pattern · Filter by time window · Read the full rotated history · Machine-readable output · Project-wide filtering and aggregation · Raw application output · ANSI handling · Stream snapshots · Prune rotated backups · Log files · Locate log files · Rotation and retention · Performance model · See also","text":"logs View stored output from managed services. Info: From the interactive sysg status table, select a UNIT with Tab/arrow navigation and press L to jump straight into that unit's logs. The status shortcut runs sysg logs -s -l 100 --stream 2 , which shows the latest 100 lines and refreshes the snapshot every 2 seconds. Options Short Long Description ------- ------ ------------- -c --config Path to configuration file - --purge Reset log files instead of displaying them - --prune Delete rotated log backups instead of displaying logs (requires --max-size and/or --max-age ) - --max-size When pruning, cap total rotated-backup size (e.g. 500MB , 2g ) - --max-age When pruning, remove rotated backups older than this (e.g. 7d , 12h ) -s --service The service whose logs to show. With no -p , resolves to the loose ( loose ) bundle only -p --project The project whose logs to show (all its services, or one with -s ) - --supervisor Show the supervisor's own log instead of a service's. Cannot be combined with -s / -p -l --lines Trailing lines to show. Defaults to the latest 100; pass -l N to choose another limit -k --kind Kind of logs to show: stdout or stderr . Omit to show stdout+stderr together -f --follow Follow the log stream until interrupted (like tail -F ) - --no-follow Force a one-shot snapshot even on an interactive terminal - --since Only show lines captured at or after this time (RFC3339, YYYY-MM-DD , or a relative age like 30m / 2h / 7d ) - --until Only show lines captured at or before this time (same formats as --since ) -g --grep Only show lines matching this regular expression -a --all Read the full active-plus-rotated history instead of the last --lines - --path Print the on-disk log path(s) instead of the logs, then exit - --format Machine-readable output. json prints one {ts, stream, service, line} object per line - --raw Print only the application's original line, dropping systemg's timestamp/stream prefix - --strip-ansi Strip ANSI color/escape sequences (default on for --format json , --raw , and non-interactive output) - --no-strip-ansi Keep ANSI escape sequences even when they would be stripped by default - --stream Continuously refresh the latest log snapshot at the provided interval (e.g., 5 , 1s , 2m ) -v --verbose Print operation progress - --sys Opt into privileged system mode. Requires running as root - --drop-privileges Accepted globally but ignored; logs does not spawn services - --plain Disable color, banners, paging, and implicit log following - --log-level Set logging verbosity for this invocation ( trace through off , or 5-0) Scoping Logs are always scoped — a bare sysg logs is refused ( SG0019 ) so you never get the wrong project's output. Each project's logs live in their own place ( {project}/{service} ), so two projects can share a service name without their logs colliding. You run You get --- --- logs -p all of that project's services logs -p -s that one service logs -s (no -p ) the loose ( loose ) service of that name onl"},{"id":"/reference/commands/status","route":"/reference/commands/status","section":"reference","group":"Commands","title":"status","description":"","headings":"Interactive Mode · Why is it Warn or Failing? · Description · Recommended Fix · Options · Examples · View all registered projects · View specific service · View a project · View the project from a config · Stream status updates · Force live runtime collection · Performance · Output fields · State values · Intent values · Health values · See also","text":"status Check the health of services known to the running supervisor. When a supervisor is running, sysg status asks that supervisor for an aggregate view of every registered project. It reads current persisted state such as cron history and uses each project's configured status.snapshot mode for runtime detail. Use --live when you need systemg to force immediate runtime collection for that request. sysg status does not require a config file. If no supervisor is running and you do not provide --config , it reports No running supervisor . Use --config only when you want to scope status to a specific config/project or when you explicitly want the no-supervisor disk fallback for that config. No units being supervised means the resident supervisor is healthy but has no loaded projects. No running supervisor means no resident supervisor is available. No matching units found is reserved for a selector or filter that matched nothing. Interactive Mode By default, sysg status displays an interactive table where you can: - ↓ / Tab (Down) - Move to the next service - ↑ / Shift+Tab (Up) - Move to the previous service - → / ← (Right / Left) - Move the focused cell across columns in the selected row - I or Enter - Open the inspect view for the selected service - H - Open the health report explaining why the selected unit is Warn or Failing (see below) - L - Open a live log snapshot stream for the selected service - R - Restart the selected service - q , ESC , or Ctrl+C - Exit the status view Cron units The R restart control applies to service units only. Cron units are scheduler entries, not persistent services, so pressing R on a cron row is a no-op: systemg shows SG0101 and explains that the owning project can reload the schedule without triggering an immediate run. ::: The focused cell in the selected row is drawn in reverse video, so it stands out as lighter on a dark terminal and darker on a light terminal. This makes it obvious which cell you are on as you tab across the row. Why is it Warn or Failing ? The HEALTH column is a verdict, not an explanation. To see why a unit holds its health, select it and press H . systemg opens a full-screen, README-style health report in the same window: The report wraps to at most 80 columns, narrowing to 80% of the terminal width on smaller terminals. Press any key to return to the status table. Info: Press L while a UNIT row is selected to open that unit's logs without leaving the status workflow. The shortcut runs sysg logs -s -l 100 --stream 2 , giving you the latest 100 log lines and refreshing the snapshot every 2 seconds. Info: Press R while a UNIT row is selected to run sysg restart -s for that unit. When the row belongs to a project, the shortcut also passes --project so only that project's unit is restarted. Options Short Long Description ------- ------ ------------- -c --config Scope output to the project represented by this configuration file -s --service Show a specific service/unit -p --project Filter by st"},{"id":"/reference/commands/inspect","route":"/reference/commands/inspect","section":"reference","group":"Commands","title":"inspect","description":"","headings":"Options · Stream Mode Controls · Examples · View service metrics · Stream with a longer rolling window · Force fresh inspect data · Metrics shown · Cron run history · Snapshot detail · See also","text":"inspect View detailed metrics for a specific service. When a supervisor is running, sysg inspect reads current persisted state such as cron history and attaches recent metric samples from the supervisor's metrics store. It does not rebuild the full process tree on every invocation unless status.snapshot mode is configured as detailed . Use --live to force immediate runtime collection for a specific inspect request. Options Short Long Description ------- ------ ------------- -s --service Name of the service to inspect -p --project Select the stable project id containing the service - --stream Continuously refresh output and render a rolling metrics window of the provided duration (e.g., 5 , 1s , 2m ) -c --config Path to configuration file - --format Emit machine-readable output ( json or xml ) instead of a report; defaults to json when no value is provided -v --verbose Print operation progress - --sys Opt into privileged system mode. Requires running as root - --drop-privileges Accepted globally but ignored; inspect does not spawn services - --no-color Disable ANSI colors in output - --plain Disable terminal decoration for automation - --live Force immediate runtime collection instead of the configured snapshot mode - --log-level Set logging verbosity for this invocation ( trace through off , or 5-0) Stream Mode Controls When --stream is attached to a TTY, inspect stays open and accepts keyboard shortcuts for the inspected unit: Key Action ----- -------- S Run sysg start -s X Run sysg stop -s R Run sysg restart -s ESC / Ctrl+C Exit stream mode If the inspected unit belongs to a project, these shortcuts also pass --project so only that project's unit is controlled. Cron units The S , X , and R controls apply to service units only. Cron units are scheduler entries, not persistent services, so these shortcuts are no-ops on a cron unit: inspect shows a notice that cron units cannot be controlled directly and that you should reload the project to reschedule them. ::: Examples View service metrics For multi-project supervisors, disambiguate duplicate service names with the stable project id: --project may name any project the supervisor has loaded, not just the first one a multi-project config declares. Inspect refuses rather than guesses: - a service name that does not exist → SG0202 , - a bare -s that matches a service in more than one project → SG0006 (pass -p to choose), - a -p that disagrees with a project/service prefix → SG0201 . Shows CPU and memory usage chart: Stream with a longer rolling window Stream mode refreshes inspect output using the configured snapshot mode and recent metric samples. The rolling window controls the charted sample range, not how much runtime detail systemg collects. Force fresh inspect data --live forces immediate runtime collection before selecting the inspected unit and loading recent metric samples. Regular inspect requests still read current persisted state such as cron history, while status.snapshot mode controls "},{"id":"/reference/commands/validate","route":"/reference/commands/validate","section":"reference","group":"Commands","title":"validate","description":"","headings":"Options · What it checks · Exit codes · JSON output · Example · See also","text":"validate Check a configuration file before you run it. validate parses the manifest, resolves the dependency graph, and — when something is wrong — tells you the exact line, why it's an error, and how to fix it. A clean file reports success and exits 0 : Options Short Long Description ------- ------ ------------- -c --config Path to the configuration file (defaults to systemg.yaml ) - --format Emit machine-readable output ( json or xml ) -v --verbose Print operation progress - --no-color Disable ANSI colors - --sys Validate against the system runtime (see below). Unlike every other command, validate with --sys does not require root - --drop-privileges Accepted globally but ignored; validate does not spawn services - --plain Agent-friendly output (also disables color) - --log-level Set logging verbosity for this invocation ( trace through off , or 5-0) What it checks - Schema — version 2 , services in each declared project or loose bundle, and a command per service. - Syntax — YAML that parses, with a caret pointing at the offending token. - Health checks — every deployment.health check has a url or a command . - Dependencies — depends on references exist and form no cycle. - Project id — every named project has a valid, non-empty id. - Environment — ${VAR} interpolations resolve from the environment or env file. - Mode enforceability — whether the mode you validated against could actually start this manifest (see below). Validation is mode-aware. sysg validate judges the manifest against user mode : root-only keys ( user , group , capabilities , limits.cgroup , isolation , non-empty supplementary groups ) produce an error finding (SG0705) — the file is well-formed ( valid: true ) but not startable in that mode ( startable: false , exit 1). sysg validate --sys judges against system (kernel) mode , where those keys pass; accounts missing on the validating host surface as warnings (your deploy target may differ), and Linux-only keys on a non-Linux host remain errors. --sys here needs no root — validating reads, it never exercises privilege. Exit codes Code Meaning ------ --------- 0 Configuration is valid and startable in the validated mode 1 Configuration has problems, or is not startable in the validated mode JSON output Use --format json for CI gates and tooling. Each diagnostic carries its location, category, message, and remediation: Example Gate a deploy on a valid manifest: See also - Configuration - Full manifest reference - start - Launch a validated manifest - status - Check services once they're running"},{"id":"/reference/commands/migrate","route":"/reference/commands/migrate","section":"reference","group":"Commands","title":"migrate","description":"","headings":"Options · Usage · See also","text":"migrate Convert a legacy singular- project: manifest into the canonical projects: map. migrate reads a manifest and prints the converted YAML to stdout — it never touches the source file unless you ask it to. Given an old-shape manifest: it emits the equivalent projects: form, bumped to the current schema version: migrate converts the shape and bumps the schema version to the current one ( 2 ): the project: block becomes a projects: entry keyed by its id, and the services and settings are otherwise unchanged. A manifest already in projects: form at the current version passes through unchanged. Options Short Long Description ------- ------ ------------- - Path to the manifest to convert (positional, required) - --in-place Rewrite the file in place, keeping a .bak copy, instead of printing to stdout -v --verbose Print operation progress - --sys Opt into privileged system mode. Requires running as root - --drop-privileges Accepted globally but ignored; migrate does not spawn services - --plain Disable terminal decoration for automation - --log-level Set logging verbosity for this invocation Usage The default prints to stdout, so you can review the diff before committing to it: Or convert the file in place once you're happy — the original is preserved as systemg.yaml.bak : The singular project: block still parses (with a deprecation warning), so migrating is not urgent for the manifest to keep working. It is, however, the clean path off the deprecated shape before it is eventually removed. See also - Configuration - The projects: schema - Projects - How one supervisor hosts many projects - validate - Check the converted manifest"},{"id":"/reference/commands/migrate-state","route":"/reference/commands/migrate-state","section":"reference","group":"Commands","title":"migrate-state","description":"","headings":"Why it is a command and not automatic · What it will not do · Options · Usage · Safety · See also","text":"migrate-state Move legacy loose state into per-manifest project directories. A manifest that declares no project: is a loose manifest. Loose manifests used to share a single project called loose — one directory, one slot. So starting a second loose manifest looked to the supervisor like an edit of the first: it reconciled the difference by stopping the service already running there. Every loose manifest now owns a project derived from its own path, and they coexist. migrate-state places the state the old shared layout left behind. Why it is a command and not automatic The migration moves state and logs you cannot reconstruct, and the supervisor loads state before it takes its lock — so a migration running at boot could be observed half-finished by a second sysg invocation. Running it explicitly means it happens once, with no supervisor alive, with the report in front of you. It refuses with SG0602 while a supervisor is running. --dry-run is always allowed. What it will not do Legacy state records a service name . The new layout keys by project . When several manifests declare the same service name, nothing in the old state says which one owned it: Those artifacts are archived and reported rather than assigned to a guess. The archive is a faithful, checksum-verified copy, so nothing is lost — place them by hand if you want them, or leave them. Options Short Long Description ------- ------ ------------- - --units Directory of manifests to attribute state to (defaults to the state root's units/ ) - --dry-run Report what would move without changing anything -v --verbose Print operation progress - --sys Opt into privileged system mode. Requires running as root - --plain Disable terminal decoration for automation - --log-level Set logging verbosity for this invocation Usage Review first — this is the recommended path, since the report tells you exactly what can and cannot be attributed: Then stop the supervisor and run it: Safety Nothing is deleted. Every source is copied into a timestamped archive beside the state root and checksum-verified before the migration proceeds, and the legacy projects/ loose / tree is left in place. A run records its progress in a journal, so an interrupted migration resumes where it stopped rather than leaving a layout that is part old and part new ( SG0604 ). The journal and archive live outside the state root, so purge cannot destroy the record of a migration still in progress. See also - migrate - Convert a manifest's shape - Projects - How one supervisor hosts many projects - Diagnostics - SG0601 , SG0602 , SG0603 , SG0604 , SG0605"},{"id":"/reference/commands/purge","route":"/reference/commands/purge","section":"reference","group":"Commands","title":"purge","description":"","headings":"Options · Scope · What gets removed · When to use · Examples · Wipe everything · Purge one project · Force a purge while services are running · See also","text":"purge Remove systemg state and start fresh. purge permanently deletes service history, logs, and runtime files. With no selector it wipes the entire state root. There is no undo. purge refuses to run while a live supervisor is still managing processes — wiping its state out from under it would strand those processes and corrupt the supervisor's view of the world. Stop the supervisor first, or pass --force . {\"error[\"} SG0401 {\"]: refused to purge: a supervisor is still managing processes\\n\\n 2 unit(s) are live under the running supervisor; purging its state now would strand them\\n\\n help:\\n stop the supervisor first sysg stop --supervisor\\n then purge sysg purge\\n or force it (stops + wipes) sysg purge --force\\n\"} Options Short Long Description ------- ------ ------------- -c --config Purge only the projects this config declares (or loose if it is project-less). Omit to wipe the whole state root -p --project Purge only this project's state - --force Purge even while a supervisor is managing processes — stops it first, then wipes -v --verbose Print operation progress - --sys Opt into privileged system mode. Requires running as root - --drop-privileges Accepted globally but ignored; purge does not spawn services - --plain Disable terminal decoration for automation - --log-level Set logging verbosity for this invocation ( trace through off , or 5-0) Scope Purge is deliberately explicit about what it deletes: - sysg purge — the whole state root: every project, the loose bundle, logs, and the supervisor runtime files (socket, pid, config hint). - sysg purge -c — only the projects that config declares. An unrelated project registered separately is left untouched. - sysg purge -p — only that one project's state directory. What gets removed - Service status history - Cron execution history - Log files (including system-mode logs at /var/log/systemg ) - PID tracking files - Supervisor state - Socket and runtime files When to use - After ungraceful shutdowns - To clear corrupted state - Before uninstalling systemg - To free disk space Examples Wipe everything Purge one project A -p naming a project with no state on disk refuses with SG0403 and deletes nothing. A project id is one path segment. A -p that is empty, traversing, or absolute refuses with SG0404 ; a -c purge resolves every project the config declares before deleting any, so one bad target refuses the whole purge rather than leaving it half-done. Force a purge while services are running --force is the explicit \"I accept the teardown\" signal: it stops the live supervisor, kills its services, and removes the state. See also - stop - Stop services without removing state - start - Start fresh after purging - Diagnostics - SG0401 , SG0402 , SG0403 , SG0404"},{"id":"/reference/commands/version","route":"/reference/commands/version","section":"reference","group":"Commands","title":"version","description":"","headings":"Why the two differ · Options","text":"version Report the version of the binary you just ran and the version the resident supervisor is actually serving. These are not the same thing. Why the two differ Installing sysg replaces the binary on disk and then asks the resident supervisor to re-exec into it. If that activation step is skipped or fails, the supervisor keeps serving the build it booted with — from the same PID, with the same start time. sysg --version reads the binary on disk and will happily report the new number while the old code is still running every service on the box. sysg version asks the supervisor directly over the control socket, so the answer describes what is running, not what is installed. Options Short Long Description ------- ------ ------------- - --format Emit machine-readable output ( json ) supervisor is null when no supervisor answers the socket. supervisor binary is resolved from /proc/ /exe and is null where the kernel does not expose it. sysg doctor prints the same report above its invariant findings."},{"id":"/reference/commands/spawn","route":"/reference/commands/spawn","section":"reference","group":"Commands","title":"spawn","description":"","headings":"Options · Examples · Preferred replacement with start · Spawn a worker process · Spawn with time limit · Spawn with parent PID tracking · Requirements · See also","text":"spawn Dynamically create child processes from parent services. Deprecated sysg spawn is deprecated. Use sysg start --parent-pid --name -- . ::: Options Short Long Description ------- ------ ------------- - --name Required. Unique identifier for spawned process - --ttl Time-to-live in seconds (optional) - --parent-pid Parent process ID (defaults to caller's parent PID if not specified) -v --verbose Print operation progress - --sys Opt into privileged system mode. Requires running as root - --drop-privileges Accepted globally but ignored by deprecated spawn ; use child-mode start - --plain Disable terminal decoration for automation - --log-level Set logging verbosity for this invocation Examples Preferred replacement with start Spawn a worker process Spawn with time limit Process automatically terminates after 1 hour: Spawn with parent PID tracking Requirements The parent service must opt into dynamic spawning before it can create children. Without spawn: mode: dynamic , spawn requests from that process are rejected because SystemG has no authorized spawn tree for the parent. ::: Parent service must be configured with: The parent can then spawn child processes dynamically within those limits. See also - Spawn configuration - status - View spawned processes"},{"id":"/reference/commands/start-vs-spawn","route":"/reference/commands/start-vs-spawn","section":"reference","group":"Commands","title":"Start vs Spawn","description":"","headings":"Quick comparison · start - Unified command · Legacy spawn mapping · Recommended naming · Example: Job queue with child mode · See also","text":"Start vs Spawn start is now the primary process-creation command. Deprecated sysg spawn is deprecated. Use sysg start --parent-pid ... for child-process workflows. ::: Quick comparison start (manifest/ad-hoc) start (child mode) spawn (deprecated) --- --- --- --- Flags sysg start [--config ...] [-- command...] sysg start --parent-pid [--ttl ...] -- sysg spawn ... Lifecycle Top-level managed unit(s) Parent-attached child unit Parent-attached child unit Use case Core services and ad-hoc units Dynamic child workers Legacy compatibility start - Unified command Manifest services: Run with: Ad-hoc single command: Child-mode replacement for spawn : Legacy spawn mapping Existing invocations: Equivalent start command: Recommended naming Use the term child mode for the former spawn workflow: - start in child mode ( --parent-pid ) - start in ad-hoc mode (command without --parent-pid ) - start in manifest mode (no command) Example: Job queue with child mode The scheduler reads from queue and spawns workers: See also - start - Launch services - spawn - Deprecated command reference - Configuration - Service definitions"},{"id":"/reference/dialog","route":"/reference/dialog","section":"reference","group":"Dialog","title":"Dialog","description":"","headings":"Anatomy · Colors · Error codes · Where evidence comes from","text":"Dialog When something fails, sysg answers like a compiler: what happened, the evidence it captured while it happened, and the exact next commands to run. Every user-facing failure is a structured diagnostic with a stable error code. {\"error[\"} SG0104 {\"]: service gamecast api failed to become healthy\\n\\n the health check against http://127.0.0.1:8080/api/v1/health ran but reported\\n the service is not healthy after 10 attempts over 45s (configured total\\n readiness budget: 45s)\\n the process is not running — it exited before it could become healthy\\n\\n last output from gamecast api :\\n │ Error: error returned from database: password authentication failed for user \\\"postgres\\\"\\n\\n help:\\n view logs sysg logs -s gamecast api -p gamecast-api-dev\\n check status sysg status -p gamecast-api-dev\\n docs https://sysg.dev/reference/dialog/codes sg0104\\n\"} Anatomy Every diagnostic has the same shape: Part What it tells you --- --- error[ SG0104 ] Severity and a stable code you can search or look up Title One sentence stating what happened -- location The config file and key the problem originates from, when known Notes Plain-sentence facts sysg observed (exit codes, timing, liveness) Evidence Output sysg captured — usually your service's own last log lines help: Runnable commands and a docs link for this exact code Colors On a terminal, diagnostics are colored: red for errors, yellow for warnings, cyan for notes and locations, green for the help section, bold for runnable commands, and underlined blue for docs links. Piped or redirected output is plain text with no escape codes, and NO COLOR is respected. gamecast — zsh ➜ gamecast sysg start -c sysg.api.yaml --daemonize {\"\\n\"} error[ SG0104 ] : service gamecast api failed to become healthy {\"\\n\\n\"}{\" the health check against http://127.0.0.1:8080/api/v1/health ran but reported\\n\"}{\" the service is not healthy after 10 attempts over 45s (configured total\\n\"}{\" readiness budget: 45s)\\n\"}{\" the process is not running — it exited before it could become healthy\\n\\n\"} {\" last output from gamecast api :\"} {\"\\n\"} │ {' Error: error returned from database: password authentication failed for user \"postgres\"\\n'} │ {\" Caused by:\\n\"} │ {' password authentication failed for user \"postgres\"\\n\\n'} {\" help:\"} {\"\\n\"}{\" view logs \"} sysg logs -s gamecast api -p gamecast-api-dev {\"\\n\"}{\" check status \"} sysg status -p gamecast-api-dev {\"\\n\"}{\" docs \"} https://sysg.dev/reference/dialog/codes sg0104 This is the real SG0104 renderer output — the same bytes diag.rs writes to a tty, shown here with its colors. Error codes Every diagnostic carries a stable SGXXXX code you can search, script against, or look up. The full list, with a description of each, lives on the Codes page — every code has its own anchor (e.g. SG0104 ) that the diagnostic's docs link points at. Where evidence comes from sysg already captures every service's stdout and stderr (see Logs). Diagnostics quote the last lines of that capture at the moment of failure, so"},{"id":"/reference/dialog/codes","route":"/reference/dialog/codes","section":"reference","group":"Dialog","title":"Codes","description":"","headings":"General · [SG0001](/reference/dialog/codes#sg0001) · [SG0002](/reference/dialog/codes#sg0002) · [SG0003](/reference/dialog/codes#sg0003) · [SG0004](/reference/dialog/codes#sg0004) · [SG0005](/reference/dialog/codes#sg0005) · [SG0007](/reference/dialog/codes#sg0007) · [SG0008](/reference/dialog/codes#sg0008) · [SG0009](/reference/dialog/codes#sg0009) · [SG0010](/reference/dialog/codes#sg0010) · [SG0011](/reference/dialog/codes#sg0011) · [SG0012](/reference/dialog/codes#sg0012) · [SG0013](/reference/dialog/codes#sg0013) · [SG0014](/reference/dialog/codes#sg0014) · [SG0015](/reference/dialog/codes#sg0015) · [SG0016](/reference/dialog/codes#sg0016) · [SG0017](/reference/dialog/codes#sg0017) · [SG0019](/reference/dialog/codes#sg0019) · [SG0020](/reference/dialog/codes#sg0020) · [SG0021](/reference/dialog/codes#sg0021) · Start · [SG0101](/reference/dialog/codes#sg0101) · [SG0102](/reference/dialog/codes#sg0102) · [SG0103](/reference/dialog/codes#sg0103) · [SG0022](/reference/dialog/codes#sg0022) · [SG0023](/reference/dialog/codes#sg0023) · [SG0104](/reference/dialog/codes#sg0104) · [SG0105](/reference/dialog/codes#sg0105) · [SG0106](/reference/dialog/codes#sg0106) · [SG0107](/reference/dialog/codes#sg0107) · [SG0108](/reference/dialog/codes#sg0108) · [SG0109](/reference/dialog/codes#sg0109) · [SG0110](/reference/dialog/codes#sg0110) · [SG0111](/reference/dialog/codes#sg0111) · Selectors, status &amp; stop · [SG0006](/reference/dialog/codes#sg0006) · [SG0201](/reference/dialog/codes#sg0201) · [SG0202](/reference/dialog/codes#sg0202) · [SG0203](/reference/dialog/codes#sg0203) · [SG0204](/reference/dialog/codes#sg0204) · [SG0205](/reference/dialog/codes#sg0205) · [SG0206](/reference/dialog/codes#sg0206) · [SG0207](/reference/dialog/codes#sg0207) · [SG0208](/reference/dialog/codes#sg0208) · [SG0209](/reference/dialog/codes#sg0209) · [SG0210](/reference/dialog/codes#sg0210) · Restart · [SG0301](/reference/dialog/codes#sg0301) · [SG0302](/reference/dialog/codes#sg0302) · [SG0303](/reference/dialog/codes#sg0303) · Purge · [SG0401](/reference/dialog/codes#sg0401) · [SG0402](/reference/dialog/codes#sg0402) · [SG0403](/reference/dialog/codes#sg0403) · [SG0404](/reference/dialog/codes#sg0404) · [SG0405](/reference/dialog/codes#sg0405) · Upgrade · [SG0501](/reference/dialog/codes#sg0501) · [SG0502](/reference/dialog/codes#sg0502) · [SG0503](/reference/dialog/codes#sg0503) · [SG0504](/reference/dialog/codes#sg0504) · [SG0505](/reference/dialog/codes#sg0505) · Migration · [SG0601](/reference/dialog/codes#sg0601) · [SG0602](/reference/dialog/codes#sg0602) · [SG0603](/reference/dialog/codes#sg0603) · [SG0604](/reference/dialog/codes#sg0604) · [SG0605](/reference/dialog/codes#sg0605) · System mode · [SG0701](/reference/dialog/codes#sg0701) · [SG0702](/reference/dialog/codes#sg0702) · [SG0703](/reference/dialog/codes#sg0703) · [SG0704](/reference/dialog/codes#sg0704) · Container-init and sandboxing · [SG0711](/reference/dialog/codes#sg0711) · [SG0712](/reference/dialog/codes#sg0712) · [SG0713](/reference/dialog/codes#sg0713) · [SG0714](/reference/dialog/codes#sg0714) · [SG0721](/reference/dialog/codes#sg0721) · [SG0722](/reference/dialog/codes#sg0722) · [SG0723](/reference/dialog/codes#sg0723) · [SG0724](/reference/dialog/codes#sg0724) · [SG0725](/reference/dialog/codes#sg0725) · [SG0726](/reference/dialog/codes#sg0726) · [SG0727](/reference/dialog/codes#sg0727) · Privilege drop · [SG0741](/reference/dialog/codes#sg0741) · [SG0742](/reference/dialog/codes#sg0742) · [SG0743](/reference/dialog/codes#sg0743) · [SG0744](/reference/dialog/codes#sg0744) · [SG0745](/reference/dialog/codes#sg0745) · [SG0746](/reference/dialog/codes#sg0746) · [SG0747](/reference/dialog/codes#sg0747) · [SG0748](/reference/dialog/codes#sg0748) · [SG0731](/reference/dialog/codes#sg0731) · [SG0732](/reference/dialog/codes#sg0732) · [SG0733](/reference/dialog/codes#sg0733) · [SG0705](/reference/dialog/codes#sg0705)","text":"Error codes Every user-facing failure carries a stable SGXXXX code. Codes never change meaning, so a script can match on them and each has a permanent anchor on this page. A diagnostic's docs link points straight at its code here. General SG0001 Catchall — a failure that has no more specific diagnosis yet. SG0002 Persisted cron history or active-run state could not be restored. The scheduler may continue without reliable history; inspect the supervisor log and the project's cron state.xml before deleting anything. SG0003 A cron unit could not be registered without conflicting with existing scheduler state. Reload the owning project after the active mutation finishes. SG0004 A finite unit that exited successfully was recorded as failed or stopped. The process completed its work; the persisted lifecycle state is inconsistent. SG0005 The supervisor is using an outdated or different project manifest. Resubmit the intended file with -c before mutating the project. SG0007 The supervisor cannot safely restart or transfer ownership while another operation controls its runtime. Let the named operation settle, then retry. SG0008 A service failed to start without a more specific diagnosis. Read the attached reason and service logs; specific failures use SG0102 – SG0110 instead. SG0009 Persisted service state disagrees with the live process table. Use sysg status --live to refresh runtime evidence before taking action. SG0010 The requested service log source is unavailable or points at the wrong runtime scope. Confirm the project selector and configured log sink. SG0011 A live log-follow stream became stale or could not reconnect to its project. The workload may still be running; check sysg status before stopping it. SG0012 Log output exceeded a safe storage or display bound. Narrow the query with --lines , --since , or --grep , or adjust configured rotation limits. SG0013 A daemonized service inherited an environment that systemg cannot safely reproduce. Review its env , privilege, and session-variable settings. SG0014 The installer could not obtain or verify the expected release artifact. The active version remains unchanged. SG0015 Supervisor IPC, PID files, or tracked process ownership disagree. Avoid manual PID-file edits; inspect live status and the supervisor log before recovery. SG0016 A rolling deployment failed without a more specific health, switch, or process diagnostic. The previous instance is retained when systemg can do so safely. SG0017 logs --prune was run with no --max-size or --max-age bound, so there is nothing to prune against. Pass at least one bound. SG0019 sysg logs ran with no -s , -p , or --supervisor , so there is no target to read. Logs are always scoped: pass -p (a whole project), -s (a loose service, or -p -s ), or --supervisor . SG0020 logs --supervisor was combined with a -s / -p selector. The supervisor's own log is a single stream; drop the selector, or drop --supervisor to read a service's logs. SG0021 logs -s (with no -p "},{"id":"/blog/0.66.5","route":"/blog/0.66.5","section":"blog","group":"Release","title":"v0.66.5","description":"fix(web): correct the teardown tie, the Blocks legend, and an SVG title hydration mismatch (0ab6a55)","headings":"","text":" Changes fix(web): correct the teardown tie, the Blocks legend, and an SVG title hydration mismatch ( 0ab6a55 ) chore(plugin): sync claude plugin version to v0.66.4 ( 487ea77 ) docs(blog): publish release post for v0.66.4 ( 922c6ca ) Full changelog on GitHub "},{"id":"/blog/0.66.4","route":"/blog/0.66.4","section":"blog","group":"Release","title":"v0.66.4","description":"test(cron): sample the cron failure case while no run is in flight (b20fe5f)","headings":"","text":" Changes test(cron): sample the cron failure case while no run is in flight ( b20fe5f ) docs(github): add issue and pull request templates ( b871795 ) ci: make the commit-message scope optiona ( aba9cd3 ) ci: drop the mintlify docs check and canonicalize SG code links ( e49fc09 ) fix(docs): prefix internal doc links with /docs and pin the mintlify link check ( 681e509 ) chore(plugin): sync claude plugin version to v0.66.3 ( 0b2da7b ) docs(blog): publish release post for v0.66.3 ( a95efcd ) Full changelog on GitHub "},{"id":"/blog/0.66.3","route":"/blog/0.66.3","section":"blog","group":"Release","title":"v0.66.3","description":"fix(ci): run mintlify against the real docs root and update the README logos (869aa4c)","headings":"","text":" Changes fix(ci): run mintlify against the real docs root and update the README logos ( 869aa4c ) feat(brew): install sysg from a homebrew tap and publish it on release ( 2c91a13 ) docs(bench): rewrite the comparative harness README for readability ( 7fa558e ) feat(web): publish release posts from CI and fix every broken sysg.dev link ( 46287e6 ) fix(cron): address routed statuses by state key and let the owner judge the run ( 718b468 ) fix(cron): route cron exit status to its owner and refuse unknown config keys ( 6933c61 ) enhancement(blog): ensure posts are mobile friendly ( eaf20d0 ) Full changelog on GitHub "},{"id":"/blog/0.66.1","route":"/blog/0.66.1","section":"blog","group":"Release","title":"v0.66.1","description":"chore: retagline systemg as a general-purpose program orchestrator (1d8835f)","headings":"","text":" Changes chore: retagline systemg as a general-purpose program orchestrator ( 1d8835f ) enhancement(blog): add sysg intro blog post ( 4ebe315 ) chore(plugin): sync claude plugin version to v0.66.0 ( 9fde2ca ) Full changelog on GitHub "},{"id":"/blog/0.66.0","route":"/blog/0.66.0","section":"blog","group":"Release","title":"v0.66.0","description":"perf(supervisor): bound live-log and metrics memory, add argv exec form (ffcfabd)","headings":"","text":" Changes perf(supervisor): bound live-log and metrics memory, add argv exec form ( ffcfabd ) fix(sysg.dev): sanitize release HTML before rendering it ( 4e09e26 ) feat(sysg.dev): rebuild sysg.dev on the systemg design system ( ed52a83 ) feat(cli): color the --help doc links ( 5234511 ) chore(plugin): sync claude plugin version to v0.65.0 ( ec7c877 ) Full changelog on GitHub "},{"id":"/blog/0.65.0","route":"/blog/0.65.0","section":"blog","group":"Release","title":"v0.65.0","description":"feat(start): run every dependency-ready service concurrently (1c6dc42)","headings":"","text":" Changes feat(start): run every dependency-ready service concurrently ( 1c6dc42 ) fix(config): parse durations at load time and type them SG0210 ( 5ed8da2 ) chore(plugin): sync claude plugin version to v0.64.5 ( 672952a ) Full changelog on GitHub "},{"id":"/blog/0.64.5","route":"/blog/0.64.5","section":"blog","group":"Release","title":"v0.64.5","description":"fix(kernel): type child-side refusals as SG0721-SG0748 and drop RFC 0001 (6af8d4c)","headings":"","text":" Changes fix(kernel): type child-side refusals as SG0721-SG0748 and drop RFC 0001 ( 6af8d4c ) docs(kernel): replace stale roadmap copy with shipped behavior ( 228ce57 ) chore(docs): add GTM container GTM-TZ59MZS2 for LinkedIn Insight Tag ( 9cc44b6 ) chore(plugin): sync claude plugin version to v0.64.4 ( e1b95f0 ) Full changelog on GitHub "},{"id":"/blog/0.64.4","route":"/blog/0.64.4","section":"blog","group":"Release","title":"v0.64.4","description":"fix(daemon): stop reconciliation clobbering a completed cron run (7c84dd7)","headings":"","text":" Changes fix(daemon): stop reconciliation clobbering a completed cron run ( 7c84dd7 ) chore(plugin): sync claude plugin version to v0.64.3 ( 7de4890 ) Full changelog on GitHub "},{"id":"/blog/0.64.3","route":"/blog/0.64.3","section":"blog","group":"Release","title":"v0.64.3","description":"fix(ci): patch RUSTSEC-2026-0258 and let the audit job write checks (21770d8)","headings":"","text":" Changes fix(ci): patch RUSTSEC-2026-0258 and let the audit job write checks ( 21770d8 ) fix(daemon): delete the per-launch lifetime thread and surface the resident supervisor version ( 65ddfc4 ) chore(plugin): sync claude plugin version to v0.64.1 ( e8549af ) Full changelog on GitHub "},{"id":"/blog/0.64.1","route":"/blog/0.64.1","section":"blog","group":"Release","title":"v0.64.1","description":"fix(state): keep a skipped record when the monitor reaps the process (03dfa03)","headings":"","text":" Changes fix(state): keep a skipped record when the monitor reaps the process ( 03dfa03 ) feat(config): move the command wait budget into supervisor.xml ( 6e4f077 ) chore(plugin): sync claude plugin version to v0.63.3 ( 1e5ccfd ) Full changelog on GitHub "},{"id":"/blog/0.63.3","route":"/blog/0.63.3","section":"blog","group":"Release","title":"v0.63.3","description":"fix(ipc): wait on supervisor liveness, not a 120s clock (0a99e1a)","headings":"","text":" Changes fix(ipc): wait on supervisor liveness, not a 120s clock ( 0a99e1a ) chore(plugin): sync claude plugin version to v0.63.2 ( 70c97ee ) Full changelog on GitHub "},{"id":"/blog/0.63.2","route":"/blog/0.63.2","section":"blog","group":"Release","title":"v0.63.2","description":"fix(daemon): trip a restart breaker when a unit never stays up (1a3794d)","headings":"","text":" Changes fix(daemon): trip a restart breaker when a unit never stays up ( 1a3794d ) chore(plugin): sync claude plugin version to v0.63.1 ( 7117f12 ) Full changelog on GitHub "},{"id":"/blog/0.63.1","route":"/blog/0.63.1","section":"blog","group":"Release","title":"v0.63.1","description":"fix(ci): drop conflicting musl-tools from musl cross Dockerfiles (base image already ships musl toolchain) (1d3df97)","headings":"","text":" Changes fix(ci): drop conflicting musl-tools from musl cross Dockerfiles (base image already ships musl toolchain) ( 1d3df97 ) Full changelog on GitHub "},{"id":"/blog/0.63.0","route":"/blog/0.63.0","section":"blog","group":"Release","title":"v0.63.0","description":"ci(release): publish claude plugin only after crate is published to crates.io (cb2bcff)","headings":"","text":" Changes ci(release): publish claude plugin only after crate is published to crates.io ( cb2bcff ) fix(supply-chain): treat systemg root crate as first-party in cargo-vet (audit-as-crates-io = false) ( 8897dcf ) ci(commit-check): run cancel-previous before the commit-message check ( 6548c69 ) chore(plugin): sync claude plugin version to v0.63.0 ( 890feea ) fix(ci, test): deflake auto-restart test; replace broken virtme kernel-matrix with native-kernel Landlock lane ( 05a8974 ) ci(commit-check): enforce type(scope) commit format, gate audit/deny/vet on it ( 4b1a322 ) fix(ci): v2 test manifests, re-disable legacy uat suites, update purge/sys-root tests for SG0405/SG0704; sandbox lane seccomp+landlock flags ( fa87ba2 ) test(model): model-based sequence harness — random lifecycle ops, oracle+model checked every step; CI matrix ( 68b581b ) feat(doctor): pid-reuse + empty-teardown invariants; wire teardown oracle into parity ( f39076c ) feat(doctor): invariant oracle check_world() + sysg doctor; wire into parity UAT ( 82e8c4d ) fix(ci): clippy clean on linux both arches — io::Error::other, arch-conditional mut/return; SG links out of SVG text ( 47b2976 ) docs(kernel-mode): add per-platfo"},{"id":"/blog/0.62.3","route":"/blog/0.62.3","section":"blog","group":"Release","title":"v0.62.3","description":"fix(diag): include SG0404 and SG0601-0605 in SgCode::ALL (d9d5b0d)","headings":"","text":" Changes fix(diag): include SG0404 and SG0601-0605 in SgCode::ALL ( d9d5b0d ) docs(lib): match crate-root tagline to README ( f2f6789 ) test(usecase): dump state files and supervisor log on a RED run ( c3753f8 ) chore(plugin): sync claude plugin version to v0.62.2 ( 03474a9 ) Full changelog on GitHub "},{"id":"/blog/0.62.2","route":"/blog/0.62.2","section":"blog","group":"Release","title":"v0.62.2","description":"fix(restart): scope restart -s to its target and seal queued op journals (fc2fed1)","headings":"","text":" Changes fix(restart): scope restart -s to its target and seal queued op journals ( fc2fed1 ) docs(restart): clarify --daemonize is a no-op against a running supervisor ( 01670d8 ) chore(plugin): sync claude plugin version to v0.62.1 ( 2d7c78d ) Full changelog on GitHub "},{"id":"/blog/0.62.1","route":"/blog/0.62.1","section":"blog","group":"Release","title":"v0.62.1","description":"test(daemon): ignore the flaky automatic-restart test pending a wider deadline (c06d369)","headings":"","text":" Changes test(daemon): ignore the flaky automatic-restart test pending a wider deadline ( c06d369 ) fix(restart): keep the fixed-port rolling→immediate transition after the reconcile deletion ( 5ec2c40 ) chore(plugin): sync claude plugin version to v0.62.0 ( 6859b3b ) feat(status): probe declared health on a timer and stop reporting live pids as healthy ( 33fbe67 ) feat(daemon): reap orphaned generations by provenance and drop port-based ghost detection ( 508eba3 ) fix(daemon): terminate and verify service teardown by session, not just group ( 8722bcb ) feat(daemon): retain retired process generations so orphans stay attributable ( c1a38f5 ) docs: swap the installation gif for the rebuilt sysg lifecycle recording ( 15fa304 ) chore(plugin): sync claude plugin version to v0.61.4 ( ef38c6d ) Full changelog on GitHub "},{"id":"/blog/0.61.4","route":"/blog/0.61.4","section":"blog","group":"Release","title":"v0.61.4","description":"fix(status): report a unit's recorded exit instead of inferring it should still be running (c562fd1)","headings":"","text":" Changes fix(status): report a unit's recorded exit instead of inferring it should still be running ( c562fd1 ) fix(start): settle a boot verdict for the primary project and stop blaming transiently Lost units ( 316ee8c ) chore(plugin): sync claude plugin version to v0.61.3 ( 6f64789 ) Full changelog on GitHub "},{"id":"/blog/0.61.3","route":"/blog/0.61.3","section":"blog","group":"Release","title":"v0.61.3","description":"fix(restart): emit unit frames on the single-service cascade and stop paths (67e0135)","headings":"","text":" Changes fix(restart): emit unit frames on the single-service cascade and stop paths ( 67e0135 ) chore(plugin): sync claude plugin version to v0.61.2 ( 305ce15 ) Full changelog on GitHub "},{"id":"/blog/0.61.2","route":"/blog/0.61.2","section":"blog","group":"Release","title":"v0.61.2","description":"feat(start): render the progress tree for queued project boots too (9136fe5)","headings":"","text":" Changes feat(start): render the progress tree for queued project boots too ( 9136fe5 ) fix(start): key progress-tree journals on a client nonce, not the command target ( ad90a81 ) Full changelog on GitHub "},{"id":"/blog/0.60.0","route":"/blog/0.60.0","section":"blog","group":"Release","title":"v0.60.0","description":"fix(tests): assert the absent-supervisor condition by code, not by prose (8e8c809)","headings":"","text":" Changes fix(tests): assert the absent-supervisor condition by code, not by prose ( 8e8c809 ) fix(ci): key release detection on the published tag, not the previous commit ( 999323e ) chore(plugin): sync claude plugin version to v0.60.0 ( 4cd6f41 ) fix(status): type the no-supervisor failure as SG0206 instead of the catch-all ( 9655b50 ) fix(skip): make skip mean skipped for cron units and dependents ( ce6c1eb ) fix(status): publish boot snapshot before announcing start complete ( 06d0614 ) feat(config): (bang)include manifest fragments with chain-attributed errors and lifecycle-safe handling ( ca8c7ca ) chore(plugin): sync claude plugin version to v0.59.3 ( b363b82 ) Full changelog on GitHub "},{"id":"/blog/0.59.3","route":"/blog/0.59.3","section":"blog","group":"Release","title":"v0.59.3","description":"fix(upgrade): resume pre-0.59 loose handoffs under their derived identity (1321553)","headings":"","text":" Changes fix(upgrade): resume pre-0.59 loose handoffs under their derived identity ( 1321553 ) chore(plugin): sync claude plugin version to v0.59.2 ( 3a40c21 ) Full changelog on GitHub "},{"id":"/blog/0.59.2","route":"/blog/0.59.2","section":"blog","group":"Release","title":"v0.59.2","description":"fix(tests): read loose logs from the derived project, not loose (1affbdd)","headings":"","text":" Changes fix(tests): read loose logs from the derived project, not loose ( 1affbdd ) chore: update version-bump ( f762e4e ) fix(loose): give every project-less config its own project ( c8a5ff5 ) chore(plugin): sync claude plugin version to v0.58.3 ( 65cfa63 ) Full changelog on GitHub "},{"id":"/blog/0.58.3","route":"/blog/0.58.3","section":"blog","group":"Release","title":"v0.58.3","description":"fix(opslot): match progress details by project id, not label substring (33b4449)","headings":"","text":" Changes fix(opslot): match progress details by project id, not label substring ( 33b4449 ) feat(cli): nest restart progress into indented rows ( 72111af ) chore(plugin): sync claude plugin version to v0.58.2 ( d19685f ) Full changelog on GitHub "},{"id":"/blog/0.58.2","route":"/blog/0.58.2","section":"blog","group":"Release","title":"v0.58.2","description":"fix: stop inferring listening ports from command text (9494b5a)","headings":"","text":" Changes fix: stop inferring listening ports from command text ( 9494b5a ) chore(plugin): sync claude plugin version to v0.58.1 ( 5e993cf ) Full changelog on GitHub "},{"id":"/blog/0.58.1","route":"/blog/0.58.1","section":"blog","group":"Release","title":"v0.58.1","description":"fix: avoid false port conflicts during restart (144983c)","headings":"","text":" Changes fix: avoid false port conflicts during restart ( 144983c ) docs: recommend zero-backlog log streaming ( b8fc7fd ) fix(logs): hide single-service headers ( d6de34c ) feat(hooks): simplify service hook events ( 087ecb7 ) chore(plugin): sync claude plugin version to v0.57.4 ( a8162c6 ) Full changelog on GitHub "},{"id":"/blog/0.57.4","route":"/blog/0.57.4","section":"blog","group":"Release","title":"v0.57.4","description":"fix(logs): restore fresh bounded and aligned output (3b202f4)","headings":"","text":" Changes fix(logs): restore fresh bounded and aligned output ( 3b202f4 ) fix(start): verify inferred port ownership before readiness ( 28ef00c ) fix(reconcile): restore inactive projects and completed dependencies ( a490a6e ) chore(plugin): sync claude plugin version to v0.57.3 ( a33529b ) Full changelog on GitHub "},{"id":"/blog/0.57.3","route":"/blog/0.57.3","section":"blog","group":"Release","title":"v0.57.3","description":"fix(supervisor): eliminate shutdown verification flake (339a184)","headings":"","text":" Changes fix(supervisor): eliminate shutdown verification flake ( 339a184 ) fix(units): correct staged unit startup and settling ( e2c6098 ) feat(inspect): separate unit config path from command details ( 23963b4 ) chore(plugin): sync claude plugin version to v0.57.1 ( b814afe ) Full changelog on GitHub "},{"id":"/blog/0.57.1","route":"/blog/0.57.1","section":"blog","group":"Release","title":"v0.57.1","description":"fix(usecase): remove contention races from upgrade and port diagnostics (331b2be)","headings":"","text":" Changes fix(usecase): remove contention races from upgrade and port diagnostics ( 331b2be ) fix(upgrade): negotiate compatibility by handoff contract ( f7db9f3 ) chore(plugin): sync claude plugin version to v0.57.0 ( 2ca06c9 ) Full changelog on GitHub "},{"id":"/blog/0.57.0","route":"/blog/0.57.0","section":"blog","group":"Release","title":"v0.57.0","description":"docs: explain the staged unit lifecycle (0ddb8c9)","headings":"","text":" Changes docs: explain the staged unit lifecycle ( 0ddb8c9 ) fix(start): recover when supervisor exits during queued boot ( 69caa7e ) test(usecase): align manifest and race cases with current lifecycle ( ed5adc5 ) docs: link every diagnostic code reference ( a2df394 ) feat(restart): automatically adopt registered manifest changes ( b4daccb ) fix(deploy): make replacement transitions generation-safe ( 05093d8 ) test: remove log finalization race from supervisor config use case ( 26ec95b ) chore(plugin): sync claude plugin version to v0.56.3 ( 5d6a252 ) Full changelog on GitHub "},{"id":"/blog/0.56.3","route":"/blog/0.56.3","section":"blog","group":"Release","title":"v0.56.3","description":"feat/v0.55.0 (#46) (e401f77)","headings":"","text":" Changes feat/v0.55.0 (#46) ( e401f77 ) chore(plugin): sync claude plugin version to v0.54.2 ( cdb3672 ) Full changelog on GitHub "},{"id":"/blog/0.54.2","route":"/blog/0.54.2","section":"blog","group":"Release","title":"v0.54.2","description":"fix(cli): recycle the supervisor on version drift during full restart (720c2d0)","headings":"","text":" Changes fix(cli): recycle the supervisor on version drift during full restart ( 720c2d0 ) chore(plugin): sync claude plugin version to v0.54.1 ( a7e5792 ) Full changelog on GitHub "},{"id":"/blog/0.54.1","route":"/blog/0.54.1","section":"blog","group":"Release","title":"v0.54.1","description":"fix(supervisor): survive per-unit failures on resident project load/restart (3e048b0)","headings":"","text":" Changes fix(supervisor): survive per-unit failures on resident project load/restart ( 3e048b0 ) chore(plugin): sync claude plugin version to v0.54.0 ( fbb92ab ) Full changelog on GitHub "},{"id":"/blog/0.54.0","route":"/blog/0.54.0","section":"blog","group":"Release","title":"v0.54.0","description":"feat(diag): SG0102 early-exit, SG0103 prestart failure, SG0001 catchall + docs (bde51bb)","headings":"","text":" Changes feat(diag): SG0102 early-exit, SG0103 pre_start failure, SG0001 catchall + docs ( bde51bb ) feat(diag): rustc-style diagnostics with evidence, next steps, and docs links ( 689e625 ) Full changelog on GitHub "},{"id":"/blog/0.53.4","route":"/blog/0.53.4","section":"blog","group":"Release","title":"v0.53.4","description":"fix(ci): set Cache-Control on release assets and harden CDN verification + v0.53.3 (2e4618a)","headings":"","text":" Changes fix(ci): set Cache-Control on release assets and harden CDN verification + v0.53.3 ( 2e4618a ) Full changelog on GitHub "},{"id":"/blog/0.53.2","route":"/blog/0.53.2","section":"blog","group":"Release","title":"v0.53.2","description":"test: update test + v0.53.2 (a726cb7)","headings":"","text":" Changes test: update test + v0.53.2 ( a726cb7 ) fix(daemon): survive per-service boot failures and auto-restart reaped units ( ca79691 ) Full changelog on GitHub "},{"id":"/blog/0.53.0","route":"/blog/0.53.0","section":"blog","group":"Release","title":"v0.53.0","description":"feat(daemon): dependson condition gating with completed semantics (530f0dc)","headings":"","text":" Changes feat(daemon): depends_on condition gating with completed semantics ( 530f0dc ) docs: add dedicated Projects page for -p/--project ( 3658a9d ) fix(install): cache-control on VERSION + installer, warn on skipped invalidation ( c4cabf3 ) Full changelog on GitHub "},{"id":"/blog/0.52.2","route":"/blog/0.52.2","section":"blog","group":"Release","title":"v0.52.2","description":"fix+release: update test + 0.52.2 (bdac364)","headings":"","text":" Changes fix+release: update test + 0.52.2 ( bdac364 ) fix: rustfmt ( 61618f1 ) feat(daemon): gate depends_on on the dependency's health check ( 0785f27 ) feat(cli): add with rich, colored config diagnostics ( 73a3c8d ) feat(claude): ship claude code plugin + skill, self-hosted marketplace, CI version sync ( cb6da83 ) docs: fix inaccuracies across docs, examples, and llms guides + rewrite README ( 443f889 ) docs: update taglines to indicate agent-friendly ( c899b06 ) Full changelog on GitHub "},{"id":"/blog/0.51.0","route":"/blog/0.51.0","section":"blog","group":"Release","title":"v0.51.0","description":"fix(logs): honor filters and populate service in project-wide log queries (1401b9c)","headings":"","text":" Changes fix(logs): honor filters and populate service in project-wide log queries ( 1401b9c ) docs: make reports/2026-07-13.md more concise ( c4966f4 ) infra: update release/ci for cloudfront distribution ( 7d3133d ) test: update docker harness for correctness/parity/hardening ( af703c5 ) docs: update philosophy/security docs ( dd40b66 ) 2026-07-13 security audit ( 1b75d91 ) docs: update llms txt ( 85d763b ) cve: bump crossbeam-epoch to 0.9.20 ( d863e73 ) feat(cli): add global --plain agent mode and discovery ( d42d433 ) feat(logs): add --format json, --raw, and ANSI stripping ( 3fbceb3 ) feat(logs): add --since/--until/--grep/--all filtering and rotated history ( af40f50 ) feat(logs): default to one-shot when non-interactive, add --follow/--no-follow ( fe91f4b ) ci: bump libclang ( d058cdd ) cve: patch cve issues ( f09ea5a ) fix: recover cron history across config drift, surface pre_start failures, show cron tz in inspect ( 920a7d4 ) fix: reconcile stale service config on restart/start with -c ( c119bb3 ) fix: patch transitive dependency CVEs ( c7ce520 ) ci: add cargo-audit cve check ( c5c86e3 ) feat: allow different output formats xml|json ( f22b777 ) fix: reject direct control "},{"id":"/blog/0.50.0","route":"/blog/0.50.0","section":"blog","group":"Release","title":"v0.50.0","description":"cve: bump crossbeam-epoch to 0.9.20 (2559223)","headings":"","text":" Changes cve: bump crossbeam-epoch to 0.9.20 ( 2559223 ) feat(cli): add global --plain agent mode and discovery ( 4636cee ) feat(logs): add --format json, --raw, and ANSI stripping ( 07a96a3 ) feat(logs): add --since/--until/--grep/--all filtering and rotated history ( 80476c3 ) feat(logs): default to one-shot when non-interactive, add --follow/--no-follow ( 675f671 ) Full changelog on GitHub "},{"id":"/blog/0.49.1","route":"/blog/0.49.1","section":"blog","group":"Release","title":"v0.49.1","description":"ci: bump libclang (b1a640d)","headings":"","text":" Changes ci: bump libclang ( b1a640d ) Full changelog on GitHub "},{"id":"/blog/0.49.0","route":"/blog/0.49.0","section":"blog","group":"Release","title":"v0.49.0","description":"cve: patch cve issues (d1a752a)","headings":"","text":" Changes cve: patch cve issues ( d1a752a ) fix: recover cron history across config drift, surface pre_start failures, show cron tz in inspect ( 421c438 ) fix: reconcile stale service config on restart/start with -c ( 13d82b6 ) Full changelog on GitHub "},{"id":"/blog/0.48.0","route":"/blog/0.48.0","section":"blog","group":"Release","title":"v0.48.0","description":"fix: patch transitive dependency CVEs (dbe5192)","headings":"","text":" Changes fix: patch transitive dependency CVEs ( dbe5192 ) ci: add cargo-audit cve check ( 9810752 ) feat: allow different output formats xml|json ( b57f468 ) Full changelog on GitHub "},{"id":"/blog/0.47.1","route":"/blog/0.47.1","section":"blog","group":"Release","title":"v0.47.1","description":"fix: reject direct control of cron units (71486ad)","headings":"","text":" Changes fix: reject direct control of cron units ( 71486ad ) Full changelog on GitHub "},{"id":"/blog/0.47.0","route":"/blog/0.47.0","section":"blog","group":"Release","title":"v0.47.0","description":"fix: strip caller session env vars from daemonized services (305b93b)","headings":"","text":" Changes fix: strip caller session env vars from daemonized services ( 305b93b ) docs: unify tagline, fill crate metadata, fix cron schema in examples ( 4f095d6 ) fix: reload stored manifest on project-scoped restart and re-add ( a37ffa4 ) fix: report process RSS in bytes, not 1024x inflated ( e4c303a ) Full changelog on GitHub "},{"id":"/blog/0.46.0","route":"/blog/0.46.0","section":"blog","group":"Release","title":"v0.46.0","description":"fix: only treat process-group survivors as healthy when the zombie is the group leader (8a2a75b)","headings":"","text":" Changes fix: only treat process-group survivors as healthy when the zombie is the group leader ( 8a2a75b ) fix: run service restarts detached so backoff doesn't serialize the monitor loop ( dc640b4 ) fix: supervise process group, not wrapper shell, to stop restart leaks and zombie status ( 80c927e ) Full changelog on GitHub "},{"id":"/blog/0.45.1","route":"/blog/0.45.1","section":"blog","group":"Release","title":"v0.45.1","description":"fix: don't show completed cron/one-shot units as Lost after their PID exits (687226b)","headings":"","text":" Changes fix: don't show completed cron/one-shot units as Lost after their PID exits ( 687226b ) Full changelog on GitHub "},{"id":"/blog/0.45.0","route":"/blog/0.45.0","section":"blog","group":"Release","title":"v0.45.0","description":"fix: don't flag completed cron/one-shot units as unhealthy (eabf1c1)","headings":"","text":" Changes fix: don't flag completed cron/one-shot units as unhealthy ( eabf1c1 ) enhancement: remove INTENT column from sysg status table ( baa8ebd ) Full changelog on GitHub "},{"id":"/blog/0.44.1","route":"/blog/0.44.1","section":"blog","group":"Release","title":"v0.44.1","description":"fix: allow successful one-shot services during restart (98ae639)","headings":"","text":" Changes fix: allow successful one-shot services during restart ( 98ae639 ) Full changelog on GitHub "},{"id":"/blog/0.44.0","route":"/blog/0.44.0","section":"blog","group":"Release","title":"v0.44.0","description":"test: update sysg status health output test (072b32b)","headings":"","text":" Changes test: update sysg status health output test ( 072b32b ) fix: bound supervisor.log growth with rotation, truncation, and prune ( 7c498bf ) enhancement: make srvc units show healthy status with exit 0 ( 836a5a6 ) Full changelog on GitHub "},{"id":"/blog/0.43.0","route":"/blog/0.43.0","section":"blog","group":"Release","title":"v0.43.0","description":"enhancement: explain unit health and color inspect cron status (5d91680)","headings":"","text":" Changes enhancement: explain unit health and color inspect cron status ( 5d91680 ) enhancement: show progress spinners for start and restart ( 6f19125 ) test: isolate build_snapshot summary test runtime state ( 86e72b9 ) 2026-06-11 audit ( 28f389e ) Full changelog on GitHub "},{"id":"/blog/0.42.2","route":"/blog/0.42.2","section":"blog","group":"Release","title":"v0.42.2","description":"","headings":"","text":" Full Changelog : https://github.com/ra0x3/systemg/compare/v0.42.1...v0.42.2 "},{"id":"/blog/0.42.1","route":"/blog/0.42.1","section":"blog","group":"Release","title":"v0.42.1","description":"fix: reload project config on scoped restart (c08920f)","headings":"","text":" Changes fix: reload project config on scoped restart ( c08920f ) docs: update status and stop semantics ( 94a045c ) Full changelog on GitHub "},{"id":"/blog/0.42.0","route":"/blog/0.42.0","section":"blog","group":"Release","title":"v0.42.0","description":"enhancement: add darkmode logos (8f6d741)","headings":"","text":" Changes enhancement: add darkmode logos ( 8f6d741 ) fix: make status supervisor-scoped ( 271d806 ) Full changelog on GitHub "},{"id":"/blog/0.41.0","route":"/blog/0.41.0","section":"blog","group":"Release","title":"v0.41.0","description":"fix: tighten project-scoped service targeting (da59155)","headings":"","text":" Changes fix: tighten project-scoped service targeting ( da59155 ) fix: ensure supervisor distinguishes start for service vs project ( 65364f4 ) fix: ensure sysg restart 'l' key respects abspath of relevant project/service config ( 57b835d ) enhancement: clarify unit status health model ( 41ecc8b ) Full changelog on GitHub "},{"id":"/blog/0.40.0","route":"/blog/0.40.0","section":"blog","group":"Release","title":"v0.40.0","description":"fix: harden restart IPC upgrades and cron timeout cleanup (ef4304e)","headings":"","text":" Changes fix: harden restart IPC upgrades and cron timeout cleanup ( ef4304e ) docs: bring sysg status docs up-to-date + add kind to sysg inspect ( 3338f7b ) Full changelog on GitHub "},{"id":"/blog/0.39.5","route":"/blog/0.39.5","section":"blog","group":"Release","title":"v0.39.5","description":"fix: read current cron history for status and inspect + v0.39.5 (492af0f)","headings":"","text":" Changes fix: read current cron history for status and inspect + v0.39.5 ( 492af0f ) Full changelog on GitHub "},{"id":"/blog/0.39.4","route":"/blog/0.39.4","section":"blog","group":"Release","title":"v0.39.4","description":"fix: preserve cron history across project reloads + v0.39.4 (d7eccfe)","headings":"","text":" Changes fix: preserve cron history across project reloads + v0.39.4 ( d7eccfe ) Full changelog on GitHub "},{"id":"/blog/0.39.3","route":"/blog/0.39.3","section":"blog","group":"Release","title":"v0.39.3","description":"fix: preserve running cron state after daemon restart + v0.39.2 (a8fa759)","headings":"","text":" Changes fix: preserve running cron state after daemon restart + v0.39.2 ( a8fa759 ) Full changelog on GitHub "},{"id":"/blog/0.39.2","route":"/blog/0.39.2","section":"blog","group":"Release","title":"v0.39.2","description":"fix: preserve cron history across multi-project inspect + v0.39.2 (13814fa)","headings":"","text":" Changes fix: preserve cron history across multi-project inspect + v0.39.2 ( 13814fa ) Full changelog on GitHub "},{"id":"/blog/0.39.1","route":"/blog/0.39.1","section":"blog","group":"Release","title":"v0.39.1","description":"fix: remove stopped projects from supervisor status + v0.39.1 (3cdea2b)","headings":"","text":" Changes fix: remove stopped projects from supervisor status + v0.39.1 ( 3cdea2b ) Full changelog on GitHub "},{"id":"/blog/0.39.0","route":"/blog/0.39.0","section":"blog","group":"Release","title":"v0.39.0","description":"fix: register extra project cron jobs with supervisor (9a41a89)","headings":"","text":" Changes fix: register extra project cron jobs with supervisor ( 9a41a89 ) enhancement: add keyboard flags to restart services via sysg status ( c215810 ) Full changelog on GitHub "},{"id":"/blog/0.38.0","route":"/blog/0.38.0","section":"blog","group":"Release","title":"v0.38.0","description":"fix: scope foreground lifetime and service restarts by project (67553b3)","headings":"","text":" Changes fix: scope foreground lifetime and service restarts by project ( 67553b3 ) enhancement: track foreground project mode in supervisor status ( fc71b74 ) Full changelog on GitHub "},{"id":"/blog/0.37.1","route":"/blog/0.37.1","section":"blog","group":"Release","title":"v0.37.1","description":"fix: admit additional project configs into running supervisor (26e1f4a)","headings":"","text":" Changes fix: admit additional project configs into running supervisor ( 26e1f4a ) Full changelog on GitHub "},{"id":"/blog/0.37.0","route":"/blog/0.37.0","section":"blog","group":"Release","title":"v0.37.0","description":"enhancement: add project-scoped status and command targeting (94018ab)","headings":"","text":" Changes enhancement: add project-scoped status and command targeting ( 94018ab ) enhancement: add project metadata to status grouping ( 8ab49ec ) Full changelog on GitHub "},{"id":"/blog/0.36.4","route":"/blog/0.36.4","section":"blog","group":"Release","title":"v0.36.4","description":"fix: honor supervisor dependency order + v0.36.4 (071dc79)","headings":"","text":" Changes fix: honor supervisor dependency order + v0.36.4 ( 071dc79 ) Full changelog on GitHub "},{"id":"/blog/0.36.3","route":"/blog/0.36.3","section":"blog","group":"Release","title":"v0.36.3","description":"fix: keep linux restart parent alive + v0.36.3 (7174dd5)","headings":"","text":" Changes fix: keep linux restart parent alive + v0.36.3 ( 7174dd5 ) Full changelog on GitHub "},{"id":"/blog/0.36.2","route":"/blog/0.36.2","section":"blog","group":"Release","title":"v0.36.2","description":"fix: prevent daemonized restart from spawning duplicate supervisor (4b0b929)","headings":"","text":" Changes fix: prevent daemonized restart from spawning duplicate supervisor ( 4b0b929 ) Full changelog on GitHub "},{"id":"/blog/0.36.1","route":"/blog/0.36.1","section":"blog","group":"Release","title":"v0.36.1","description":"fix: clean up logs stream rendering (d5d09e6)","headings":"","text":" Changes fix: clean up logs stream rendering ( d5d09e6 ) Full changelog on GitHub "},{"id":"/blog/0.36.0","route":"/blog/0.36.0","section":"blog","group":"Release","title":"v0.36.0","description":"enhancement: add esc functionality to sysg logs + fix dupe stale supervisor (6bd1166)","headings":"","text":" Changes enhancement: add esc functionality to sysg logs + fix dupe stale supervisor ( 6bd1166 ) fix: stop stale config-owned service instances ( ab33b8c ) enhancement: add L key to sysg status usgae ( ae63760 ) enhancement: update rustc to 1.96.0 ( c13a85a ) Full changelog on GitHub "},{"id":"/blog/0.35.0","route":"/blog/0.35.0","section":"blog","group":"Release","title":"v0.35.0","description":"enhancement: stack stderr+stdout in logs by default (f338be5)","headings":"","text":" Changes enhancement: stack stderr+stdout in logs by default ( f338be5 ) enhancement: allow manifest migrations up + down ( ac80410 ) fix: update loading indicator copy ( c9ef86e ) Full changelog on GitHub "},{"id":"/blog/0.34.0","route":"/blog/0.34.0","section":"blog","group":"Release","title":"v0.34.0","description":"enhancement: add live status and inspect refresh flag (061bb4b)","headings":"","text":" Changes enhancement: add live status and inspect refresh flag ( 061bb4b ) enhancement: cache status and inspect snapshots ( 6955f34 ) enhancement: add configurable service log capture ( c9061ba ) enhancement: don't rebuild logs index per-service ( 1a25625 ) ci: remove docker tests from ci for now ( a74c039 ) fix: tail latest log lines efficiently ( 7084479 ) test: update docker tests ( 372a49d ) fix: ensure tint with sysg status output ( a913850 ) Full changelog on GitHub "},{"id":"/blog/0.33.1","route":"/blog/0.33.1","section":"blog","group":"Release","title":"v0.33.1","description":"fix: ensure cron history table is in sysg inspect output (5bed136)","headings":"","text":" Changes fix: ensure cron history table is in sysg inspect output ( 5bed136 ) Full changelog on GitHub "},{"id":"/blog/0.33.0","route":"/blog/0.33.0","section":"blog","group":"Release","title":"v0.33.0","description":"ci: gate ci runs according to project (93687dc)","headings":"","text":" Changes ci: gate ci runs according to project ( 93687dc ) enhancement: add indicator for computing sysg inspect/status state ( dd38768 ) docs: update sysg logs --clear to --purge ( f848b91 ) docs: add short opts to commands docs ( 81fa360 ) enhancement: make blue_green deployments more generic ( 088d48d ) Full changelog on GitHub "},{"id":"/blog/0.32.0","route":"/blog/0.32.0","section":"blog","group":"Release","title":"v0.32.0","description":"enhancement: update sysg logs formatting (47691e0)","headings":"","text":" Changes enhancement: update sysg logs formatting ( 47691e0 ) fix: restart with --daemonize not being detached ( ab3dcea ) fix: clear sysg --stream with esc ( b3fa402 ) docs: fix favicon path ( 2ac2ccb ) Full changelog on GitHub "},{"id":"/blog/0.31.0","route":"/blog/0.31.0","section":"blog","group":"Release","title":"v0.31.0","description":"v0.31.0 (10fa2cf)","headings":"","text":" Changes v0.31.0 ( 10fa2cf ) docs: add official systemg logo ( 5e151d9 ) fix: let repeated sysg logs follow sessions reconnect cleanly ( 639ce06 ) fix: parse direct env blocks so supervised services emit logs ( 81fbf99 ) chore: code cleanup ( d84b07b ) fix: remove sysg status chart after ESC ( 5fafe0b ) fix: align sysg logs with live supervisor state ( 2fa27d7 ) docs: simplify readme ( 938d0ac ) chore: add commit-check.sh ( c2eebdf ) fix: remove duplicate docs links ( db518b0 ) Full changelog on GitHub "},{"id":"/blog/0.30.0","route":"/blog/0.30.0","section":"blog","group":"Release","title":"v0.30.0","description":"v0.30.0 (8376a14)","headings":"","text":" Changes v0.30.0 ( 8376a14 ) fix: pin mintlify version + fix broken links ( d3a3900 ) refactor: migrate docs to mintlify ( 26ef48c ) fix: allow sysg logs to fwd logs from monitored procs ( 040f98f ) enhancement: add --clear to sysg logs ( 17b8455 ) chore: cleanup comments ( 952eca8 ) Full changelog on GitHub "},{"id":"/blog/0.29.0","route":"/blog/0.29.0","section":"blog","group":"Release","title":"v0.29.0","description":"enhancement: add --stderr to sysg start + update docs (8b764b6)","headings":"","text":" Changes enhancement: add --stderr to sysg start + update docs ( 8b764b6 ) enhancement: tighten sysg status header ( 85eebf6 ) enhancement: shade sysg status by process level + merge sysg inspect tables ( 02b0b4f ) Full changelog on GitHub "},{"id":"/blog/0.28.0","route":"/blog/0.28.0","section":"blog","group":"Release","title":"v0.28.0","description":"enhancement: allow sysg status to be interactive (9149e14)","headings":"","text":" Changes enhancement: allow sysg status to be interactive ( 9149e14 ) docs: minor docs ux updates ( 01b120c ) docs: update unit examples ( 126ce9e ) Full changelog on GitHub "},{"id":"/blog/0.27.0","route":"/blog/0.27.0","section":"blog","group":"Release","title":"v0.27.0","description":"docs: add unit examples (2f26701)","headings":"","text":" Changes docs: add unit examples ( 2f26701 ) fix: update unit health status calculation ( 7145ad0 ) refactor: merge swap to start and deprecate swap ( a77d93a ) enhancement: impl ad-hoc supervision of arbitrary commands ( 3be41af ) Full changelog on GitHub "},{"id":"/blog/0.26.3","route":"/blog/0.26.3","section":"blog","group":"Release","title":"v0.26.3","description":"fix+release: fix sysg inspect table width + v0.26.3 (8739a98)","headings":"","text":" Changes fix+release: fix sysg inspect table width + v0.26.3 ( 8739a98 ) Full changelog on GitHub "},{"id":"/blog/0.26.2","route":"/blog/0.26.2","section":"blog","group":"Release","title":"v0.26.2","description":"fix: address sysg chart sizing (6eb39b8)","headings":"","text":" Changes fix: address sysg chart sizing ( 6eb39b8 ) Full changelog on GitHub "},{"id":"/blog/0.26.1","route":"/blog/0.26.1","section":"blog","group":"Release","title":"v0.26.1","description":"fix: adjust sysg inspect formatting (ee9156b)","headings":"","text":" Changes fix: adjust sysg inspect formatting ( ee9156b ) fix: ensure status/inspect dont read from stale cache ( b3948e2 ) fix: recolor sysg inspect for clarity + improve formatting ( ef94a7e ) fix: adjust unit type color ( 80c0c45 ) Full changelog on GitHub "},{"id":"/blog/0.26.0","route":"/blog/0.26.0","section":"blog","group":"Release","title":"v0.26.0","description":"fix: simplify crud example + prettify sysg inspect (dc52f64)","headings":"","text":" Changes fix: simplify crud example + prettify sysg inspect ( dc52f64 ) fix: add htop bars to sysg inspect ( 2ac11aa ) fix+enhancement: enable sysg status table size dynamically + add -s --service opt to sysg inspect ( 9ada092 ) fix: update tests per new xml artifacts ( 6d12a95 ) refactor: use xml for state artifacts instead of json ( 28bb977 ) test: rewrite restart orphan regression with unix baseline and linux edge case ( a178ca0 ) fix: use blue_green for rolling deployments ( 800210f ) fix: ensure that sysg restart does not create process leaks ( 026724a ) fix: address sysg status formatting ( 4e3b365 ) enhancement: make sysg inspect output for htop-like ( 3ff4830 ) fix: address inconcsistencies with --sys and --drop-privileges + update docs ( b451fcf ) fix: prettify sysg inspect output ( 9b22d0c ) fix: capitalize health labels from sysg status ( 995156f ) Full changelog on GitHub "},{"id":"/blog/0.24.1","route":"/blog/0.24.1","section":"blog","group":"Release","title":"v0.24.1","description":"fix: upload binaries on auto-release (8f58ffd)","headings":"","text":" Changes fix: upload binaries on auto-release ( 8f58ffd ) Full changelog on GitHub "},{"id":"/blog/0.25.0","route":"/blog/0.25.0","section":"blog","group":"Release","title":"v0.25.0","description":"fix+release: upload binaries on auto-release (7a16fcd)","headings":"","text":" Changes fix+release: upload binaries on auto-release ( 7a16fcd ) Full changelog on GitHub "},{"id":"/blog/0.24.0","route":"/blog/0.24.0","section":"blog","group":"Release","title":"v0.24.0","description":"enhancement: refactor 'status' 'logs' 'inspect' to use --stream opt (efc9af3)","headings":"","text":" Changes enhancement: refactor 'status' 'logs' 'inspect' to use --stream opt ( efc9af3 ) fix: update orchestrator instructions ( 2944c69 ) fix: default sysg logs to stderr + update orchestrator instructions ( 2526b36 ) fix: flush out orchestrator instructions ( 399d5d4 ) fix: small ux updates to sysg status ( 22b00c7 ) chore: update sysg config for orchestrator ( e1647e5 ) ci: fix bad release logic ( d641480 ) docs: update readme ( fc43d60 ) ci: impl auto release creation ( cd7c712 ) Full changelog on GitHub "},{"id":"/blog/0.23.0","route":"/blog/0.23.0","section":"blog","group":"Release","title":"v0.23.0","description":"enhancement: colorize and label peripherally spawned procs (01972ac)","headings":"","text":" Changes enhancement: colorize and label peripherally spawned procs ( 01972ac ) fix: update orchestrator example instructions ( 44cab76 ) enhancement: allow sysg status to track non-supervisor launched procs ( fc7a7ee ) Full changelog on GitHub "},{"id":"/blog/0.22.0","route":"/blog/0.22.0","section":"blog","group":"Release","title":"v0.22.0","description":"enhancement: migrate orchestrator agents to porki package (96beaa8)","headings":"","text":" Changes enhancement: migrate orchestrator agents to porki package ( 96beaa8 ) fix: flushout orchestrator example more ( 0db8760 ) docs: add install gif ( 8ff56fd ) fix: add USER to sysg status for spwn services ( 9477ca2 ) fix: update orchestrator example ( e3d794f ) docs: update readme ( 14afa88 ) Full changelog on GitHub "},{"id":"/blog/0.21.0","route":"/blog/0.21.0","section":"blog","group":"Release","title":"v0.21.0","description":"fix: simplify logging + update orchestrator instructions (53fc8af)","headings":"","text":" Changes fix: simplify logging + update orchestrator instructions ( 53fc8af ) fix: update orchestrator example ( a63850b ) fix: add -s --service to sysg logs ( 94692bb ) docs: ensure commands are up-to-date ( 566b64b ) fix: make default log stream stderr ( b7b3de5 ) docs: refactor/update all docs ( c2c64e0 ) enhancement: add user to sysg status ( 91b3126 ) docs: simplify docs ( 70929ca ) chore: refactor gen-ui example to orchestrator example ( 7e4e030 ) Full changelog on GitHub "},{"id":"/blog/0.20.4","route":"/blog/0.20.4","section":"blog","group":"Release","title":"v0.20.4","description":"fix: default install to local/bin (233b4d6)","headings":"","text":" Changes fix: default install to local/bin ( 233b4d6 ) fix: update flaky system_mode_uses_var_directories ( 7be2a0e ) fix: add --log-level to sysg spawn ( f5d0b0c ) fix: allow sysg to track full process tree ( 262e295 ) spike: sysg ui (#43) ( ab74986 ) Full changelog on GitHub "},{"id":"/blog/0.20.3","route":"/blog/0.20.3","section":"blog","group":"Release","title":"v0.20.3","description":"fix+release: ensure sysg status nesting (9b59c14)","headings":"","text":" Changes fix+release: ensure sysg status nesting ( 9b59c14 ) Full changelog on GitHub "},{"id":"/blog/0.20.2","route":"/blog/0.20.2","section":"blog","group":"Release","title":"v0.20.2","description":"fix+release: redirect subproc stderr + address cascade termination + updates tests (1768038)","headings":"","text":" Changes fix+release: redirect subproc stderr + address cascade termination + updates tests ( 1768038 ) Full changelog on GitHub "},{"id":"/blog/0.20.1","route":"/blog/0.20.1","section":"blog","group":"Release","title":"v0.20.1","description":"fix+release: ensure sysg status reports on sub-processes + v0.20.1 (8c218cd)","headings":"","text":" Changes fix+release: ensure sysg status reports on sub-processes + v0.20.1 ( 8c218cd ) fix: update install logo + reenable console logging on sysg start + fix example ( db476ba ) Full changelog on GitHub "},{"id":"/blog/0.20.0","route":"/blog/0.20.0","section":"blog","group":"Release","title":"v0.20.0","description":"enhancement: impl sysg spawn + update docs (#42) (e8da51b)","headings":"","text":" Changes enhancement: impl sysg spawn + update docs (#42) ( e8da51b ) docs: update missed docs for rebrand ( b22517d ) Full changelog on GitHub "},{"id":"/blog/0.19.0","route":"/blog/0.19.0","section":"blog","group":"Release","title":"v0.19.0","description":"enhancement: swap charting to rasciigraph + remove comments (944fab9)","headings":"","text":" Changes enhancement: swap charting to rasciigraph + remove comments ( 944fab9 ) admin: rebrand to program composer + update docs ( 16e1869 ) fix+release: swap gnuchart with rasciichart + v0.18.1 ( 4ecc55b ) "},{"id":"/blog/0.18.0","route":"/blog/0.18.0","section":"blog","group":"Release","title":"v0.18.0","description":"fix: address cron pid race condition (21ee4eb)","headings":"","text":" Changes fix: address cron pid race condition ( 21ee4eb ) test: add docker tests ( a289eba ) enhancement: update rustfmt usage ( c583bd3 ) enhancement: use gnuplot for sysg inspect ( cf407d4 ) fix+release: address linux zombie thread bug + cleanup + v0.17.0-rc9 ( 502b2eb ) release+fix: resolve sysg inspect deadlock by using try_read for metrics + v0.17.0-rc8 ( c91011c ) fix+release: sysg inspect inline charts ( f3fbd5f ) enhancement+release: add sliding window to sysg inspect + v0.17.0-rc5 ( c2b7b1a ) release+fix: sysg status/inspect improvements + v0.17.0-rc4 ( cf3ae4d ) enhancement+release: update sysg status/inspect + v0.17.0-rc3 ( b57b7fd ) fix+release: use chart view for sysg inspect + v0.17.0-rc2 ( 622c210 ) enhancement: implement sysg inspect devx improvements (#39) ( 1eef279 ) enhancement: implement kernel space (#38) ( 2592828 ) Full changelog on GitHub "},{"id":"/blog/0.17.0","route":"/blog/0.17.0","section":"blog","group":"Release","title":"v0.17.0","description":"main<-develop (#40) (f02bf9b)","headings":"","text":" Changes main&#x3C;-develop (#40) ( f02bf9b ) Full changelog on GitHub "},{"id":"/blog/0.15.6","route":"/blog/0.15.6","section":"blog","group":"Release","title":"v0.15.6","description":"fix: address purge + fix ipc state updates (36bb3f8)","headings":"","text":" Changes fix: address purge + fix ipc state updates ( 36bb3f8 ) Full changelog on GitHub "},{"id":"/blog/0.15.5","route":"/blog/0.15.5","section":"blog","group":"Release","title":"v0.15.5","description":"fix: address individual service start/stop + refactor tests (91e10df)","headings":"","text":" Changes fix: address individual service start/stop + refactor tests ( 91e10df ) Full changelog on GitHub "},{"id":"/blog/0.15.4","route":"/blog/0.15.4","section":"blog","group":"Release","title":"v0.15.4","description":"fix: terminate full process tree and clean hashed service state (9b0b653)","headings":"","text":" Changes fix: terminate full process tree and clean hashed service state ( 9b0b653 ) docs: add philosophy ( a3ac662 ) fix: cleanup supervisor tracking ( 0b2e4aa ) Full changelog on GitHub "},{"id":"/blog/0.15.3","route":"/blog/0.15.3","section":"blog","group":"Release","title":"v0.15.3","description":"","headings":"","text":" Full Changelog : https://github.com/ra0x3/systemg/compare/v0.15.2...v0.15.3 "},{"id":"/blog/0.15.2","route":"/blog/0.15.2","section":"blog","group":"Release","title":"v0.15.2","description":"","headings":"","text":" Full Changelog : https://github.com/ra0x3/systemg/compare/v0.15.1...v0.15.2 "},{"id":"/blog/0.15.1","route":"/blog/0.15.1","section":"blog","group":"Release","title":"v0.15.1","description":"","headings":"","text":" Full Changelog : https://github.com/ra0x3/systemg/compare/v0.15.0...v0.15.1 "},{"id":"/blog/0.15.0","route":"/blog/0.15.0","section":"blog","group":"Release","title":"v0.15.0","description":"enhancement: support renaming services (f7f6e9c)","headings":"","text":" Changes enhancement: support renaming services ( f7f6e9c ) fix: limit sysg logs output size per log type ( 26f7287 ) Full changelog on GitHub "},{"id":"/blog/0.14.5","route":"/blog/0.14.5","section":"blog","group":"Release","title":"v0.14.5","description":"fix: re-attempt cron registration on restart (e0ebe7c)","headings":"","text":" Changes fix: re-attempt cron registration on restart ( e0ebe7c ) Full changelog on GitHub "},{"id":"/blog/0.14.4","route":"/blog/0.14.4","section":"blog","group":"Release","title":"v0.14.4","description":"fix: ensure sysg restart registers new cron + update rustdoc (1fee54e)","headings":"","text":" Changes fix: ensure sysg restart registers new cron + update rustdoc ( 1fee54e ) Full changelog on GitHub "},{"id":"/blog/0.14.3","route":"/blog/0.14.3","section":"blog","group":"Release","title":"v0.14.3","description":"fix: persist unexpected pre-start failures with ExitedWithError and record start attempts (b101c3e)","headings":"","text":" Changes fix: persist unexpected pre-start failures with ExitedWithError and record start attempts ( b101c3e ) fix: update daemon to record failed start attempts ( 43bb0da ) Full changelog on GitHub "},{"id":"/blog/0.14.2","route":"/blog/0.14.2","section":"blog","group":"Release","title":"v0.14.2","description":"fix: enable prestart for all deployment types (6bf322f)","headings":"","text":" Changes fix: enable pre_start for all deployment types ( 6bf322f ) Full changelog on GitHub "},{"id":"/blog/0.14.1","route":"/blog/0.14.1","section":"blog","group":"Release","title":"v0.14.1","description":"fix: address cron lockfile race (d7fbf23)","headings":"","text":" Changes fix: address cron lockfile race ( d7fbf23 ) fix: cleanup pid file when changing state ( 886fe6b ) docs: update multi-service example ( cdebe37 ) Full changelog on GitHub "},{"id":"/blog/0.13.3","route":"/blog/0.13.3","section":"blog","group":"Release","title":"v0.13.3","description":"","headings":"","text":" Full Changelog : https://github.com/ra0x3/systemg/compare/v0.13.2...v0.13.3 "},{"id":"/blog/0.13.2","route":"/blog/0.13.2","section":"blog","group":"Release","title":"v0.13.2","description":"fix: dont start cron on restart + address zombie threads (f88c1e3)","headings":"","text":" Changes fix: dont start cron on restart + address zombie threads ( f88c1e3 ) enhancement: add max_restarts config ( b032776 ) fix: colorize sysg status a bit more ( ab21d26 ) Full changelog on GitHub "},{"id":"/blog/0.13.1","route":"/blog/0.13.1","section":"blog","group":"Release","title":"v0.13.1","description":"fix: ensure monitor reaps services (095ba63)","headings":"","text":" Changes fix: ensure monitor reaps services ( 095ba63 ) Full changelog on GitHub "},{"id":"/blog/0.13.0","route":"/blog/0.13.0","section":"blog","group":"Release","title":"v0.13.0","description":"fix: ensure statuses are communicated differently (694923b)","headings":"","text":" Changes fix: ensure statuses are communicated differently ( 694923b ) enhancement: add supervisor logs (#34) ( 304f69b ) enhancement: add -s --service opt to start command ( 3dac369 ) Full changelog on GitHub "},{"id":"/blog/0.12.0","route":"/blog/0.12.0","section":"blog","group":"Release","title":"v0.12.0","description":"fix: ensure supervisor recognizes skip flag (d032f11)","headings":"","text":" Changes fix: ensure supervisor recognizes skip flag ( d032f11 ) enhancement: add -s --service flag to status command ( 5ac2ed5 ) fix: re-address supervisor abandoning procs after session exit ( bb0d2d2 ) Full changelog on GitHub "},{"id":"/blog/0.11.2","route":"/blog/0.11.2","section":"blog","group":"Release","title":"v0.11.2","description":"fix: address unrisilient logs + rolling deployment silently failing (13638e3)","headings":"","text":" Changes fix: address unrisilient logs + rolling deployment silently failing ( 13638e3 ) Full changelog on GitHub "},{"id":"/blog/0.11.1","route":"/blog/0.11.1","section":"blog","group":"Release","title":"v0.11.1","description":"fix: repair restart pid tracking and stop (b47880e)","headings":"","text":" Changes fix: repair restart pid tracking and stop ( b47880e ) docs: update examples ( 193407e ) Full changelog on GitHub "},{"id":"/blog/0.11.0","route":"/blog/0.11.0","section":"blog","group":"Release","title":"v0.11.0","description":"enhancement: add linux alpine support (c215fe2)","headings":"","text":" Changes enhancement: add linux alpine support ( c215fe2 ) enhancement: add root-level env config ( 66c6c7e ) enhancement: add 'skip' functionality ( ff52e66 ) "},{"id":"/blog/0.10.0","route":"/blog/0.10.0","section":"blog","group":"Release","title":"v0.10.0","description":"enhancement: add webhooks (#33) (83d0067)","headings":"","text":" Changes enhancement: add webhooks (#33) ( 83d0067 ) docs: thoroughly update command docs ( 8cb7459 ) fix: add debian build back to cross ( d7de0c1 ) Full changelog on GitHub "},{"id":"/blog/0.9.0","route":"/blog/0.9.0","section":"blog","group":"Release","title":"v0.9.0","description":"enhancement: add logs support on macos and fix prestart config (9a77b5a)","headings":"","text":" Changes enhancement: add logs support on macos and fix pre_start config ( 9a77b5a ) enhancement: impl cron support (#32) ( 2b29d5e ) enhancement: zero downtime deployments (#30) ( 3a67c2f ) chore: add RUSTFLAGS to docker build + update readme ( 19668ff ) enhancement: add debian support ( afacfd6 ) Full changelog on GitHub "},{"id":"/blog/0.8.0","route":"/blog/0.8.0","section":"blog","group":"Release","title":"v0.8.0","description":"enhancement: add --log-level (#29) (d4a5c01)","headings":"","text":" Changes enhancement: add --log-level (#29) ( d4a5c01 ) enhancement: fix daemon dep handling (#28) ( a25b0e6 ) enhancement: dont replace binaries with matching versions ( 96159d3 ) Full changelog on GitHub "},{"id":"/blog/0.7.1","route":"/blog/0.7.1","section":"blog","group":"Release","title":"v0.7.1","description":"fix: ctrl+c terminates all non --daemonize'd 'sysg start' children by @ra0x3 in https://github.com/ra0x3/systemg/pull/23","headings":"","text":" What's Changed fix: ctrl+c terminates all non --daemonize'd 'sysg start' children by @ra0x3 in https://github.com/ra0x3/systemg/pull/23 refactor: update for new supervisor by @ra0x3 in https://github.com/ra0x3/systemg/pull/27 Full Changelog : https://github.com/ra0x3/systemg/compare/v0.6.8...v0.7.1 "},{"id":"/blog/0.6.8","route":"/blog/0.6.8","section":"blog","group":"Release","title":"v0.6.8","description":"enhancement: update install script + update ci (d8e4004)","headings":"","text":" Changes enhancement: update install script + update ci ( d8e4004 ) Full changelog on GitHub "},{"id":"/blog/0.6.2","route":"/blog/0.6.2","section":"blog","group":"Release","title":"v0.6.2","description":"test: release test 0.6.2 (8a368bf)","headings":"","text":" Changes test: release test 0.6.2 ( 8a368bf ) "},{"id":"/blog/0.6.1","route":"/blog/0.6.1","section":"blog","group":"Release","title":"v0.6.1","description":"test: release test 0.6.1 (53f9d6e)","headings":"","text":" Changes test: release test 0.6.1 ( 53f9d6e ) ci: allow for dry run on cargo publish ( cfc7564 ) ci: remove macos builds ( 32c2989 ) fix: add ci scripts for cross build ( 4a5748b ) misc: temp turn off release actions ( ffcf619 ) chore: update ci actions (#11) ( c011a5a ) feat: upload + install binaries (#10) ( 87974aa ) "},{"id":"/blog/0.6.0","route":"/blog/0.6.0","section":"blog","group":"Release","title":"v0.6.0","description":"fix: start srvcs in session + send signals to proc group (#9) (eb2f164)","headings":"","text":" Changes fix: start srvcs in session + send signals to proc group (#9) ( eb2f164 ) docs: update usage ( 5ef565a ) feat/support rel abs paths (#4) ( 043ef35 ) docs: flush out docs + add more docs ( d10f177 ) chore: docs updates ( 31bd5f3 ) chore: update docs meta + logos ( f644fba ) fix: get docs building ( 1040e51 ) chore: update docs ( fe8deda ) enhancement: add examples ( e8fd533 ) fix: add daemon hooks on linux ( 96b3baf ) enhancement: add support for simple webhooks ( 192ba7b ) enhancement: add integration test skeleton ( d851882 ) chore: update rustdoc ( 6d4623c ) fix: add feature flag to docs.rs build ( 292a976 ) "},{"id":"/blog/0.5.0","route":"/blog/0.5.0","section":"blog","group":"Release","title":"v0.5.0","description":"enhancement: get start + log commands working on linux (#1) (f78032a)","headings":"","text":" Changes enhancement: get start + log commands working on linux (#1) ( f78032a ) Full changelog on GitHub "},{"id":"/blog/0.4.0","route":"/blog/0.4.0","section":"blog","group":"Release","title":"v0.4.0","description":"enhancement: fix status uptime issue + add warning for logs on mac (f1397d4)","headings":"","text":" Changes enhancement: fix status uptime issue + add warning for logs on mac ( f1397d4 ) fix: add optional linux imports ( 646dbdb ) enhancement: prettify status output format ( 6fe8175 ) enhancement: add sysd status command ( ce5f037 ) chore: update docs + rename binary to sysg ( 294899c ) chore: cleanup .expect ( d2f9df0 ) fix: remove quotes from injected env vars ( c63f8cd ) fix: version is string ( 85c511c ) "},{"id":"/blog/0.3.0","route":"/blog/0.3.0","section":"blog","group":"Release","title":"v0.3.0","description":"enhancement: update logs command (134fe91)","headings":"","text":" Changes enhancement: update logs command ( 134fe91 ) enhancement: reload pid file during monitoring ( 9bc5c40 ) enhancement: add pid manager + daemonize systemg itself ( 779582a ) enhancement: attach child procs to same group as systemg proc ( 09029a5 ) chore: update README ( e3d89a2 ) fix: remove lib ( 8d22e01 ) enhancement: daemonize services ( e75ae1e ) "},{"id":"/blog/0.2.0","route":"/blog/0.2.0","section":"blog","group":"Release","title":"v0.2.0","description":"enhancement: first mvp (0de95e3)","headings":"","text":" Changes enhancement: first mvp ( 0de95e3 ) enhancement: flush out daemon + tests ( 59e709f ) enhancement: add docs ( a5840ca ) enhancement: flush out systemg project ( c2a6e3d ) enhancement: init systemg project ( c80f2df ) "}]