How systemg compares

to other process managers

We ran systemg through a gauntlet of tests against systemd, Supervisor, and Docker Compose — install, boot, memory, teardown, crash recovery, and readiness.

TL;DR: systemg installs faster than Supervisor, boots a dependency graph faster than Docker Compose, and uses less memory than either. It is also the only one of the three that leaves nothing running after you stop a service, and the only one that neither duplicates nor loses your workload when the supervisor itself dies.

Each tool installed the way its users install it, timed until one service is actually supervised.

Supervisor's 48 MB is 47.6 MB of apt index plus 0.4 MB of packages — on a machine that ran apt today it pulls 0.4 MB. sysg pulls 6.8 MB in every cache state. systemd is 14.6 MB installed and ships with the distribution, so its marginal install cost is zero. 86% of Supervisor's disk figure is the CPython runtime; sysg carries its runtime compiled into the binary.

Two independent roots, a five-wide fan-in. 0.64 walked the topological order one unit at a time; 0.65 dispatches every unit whose dependencies are already satisfied.

Supervisor has no dependency edges. priority orders starts but does not gate on readiness, so this graph cannot be expressed. Compose runs each unit as a container and sysg runs each as a process — different isolation, and Compose ran against the host daemon while sysg ran in a container.

A service that starts but cannot do work for five seconds. The marker is when the tool says it is up; the shaded band is the distance from there to when it actually works.

startsecs is a fixed timer: set it to the real startup time and it is exact. A probe is closed-loop, so it does not need to be told.

Memory for the tool, minus the same services run bare. Ten near-idle services, so the tool dominates. These are orders of magnitude apart, so area is proportional to megabytes.

On macOS, Docker Desktop adds a further 476 MB host-side for the VM and its helpers.

The intercept matters less than the slope. sysg 0.66 adds an exec: argv form that runs a service directly instead of through a shell, which removes a resident process per service.

command: is unchanged and still spawns through a shell, which stays resident as the service's parent — 85 processes for 40 services instead of 45.

A service and five descendants, one of which deliberately escapes the process group. Stop it with each tool's own command, then count what is still running.

Survivors reparent to init and keep running. The loss is per stop/restart cycle, so a service that restarts hourly accumulates them.

kill -9 the supervisor — dockerd for Compose, not the CLI — then start it again and look at what happened to the workload.

Supervisor's services keep running, but supervisord has no record of them and starts a second copy. With live-restore: false the Docker daemon does not re-attach to containers from the previous session; live-restore: true is untested here. While dockerd was down the workload could not be inspected at all — every path goes through the daemon.

Numbers where a figure was measured, marks where the answer is yes or no. A dash means it was not measured for that tool.

systemg is open source and always welcomes contributors and users. Bugs, benchmark disputes, and re-runs that disagree with anything above are all useful — every script that produced these figures is in the repo, so a contradicting result is a pull request rather than an argument.

The full writeup carries every trial, the pinned versions and images, the reasoning behind each metric, and the four harness bugs that produced plausible wrong numbers before they were caught.

Every tool gets the same service body and the same probe interval. Where a setting changes a result — stopasgroup, startsecs, exec: — both configurations are charted. Trial counts are 2–5 per figure, cold, with raw output published alongside the scripts.