Commands
restart
Restart services, applying any manifest change on the way through.
$ sysg restartWarning
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.
Note
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 |
- | --delta | Bounce only the units the manifest changed, plus their dependents, instead of every declared unit |
-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) |
Info
--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
--daemonizeto 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
$ sysg restartRestart specific service
$ sysg restart --service apiRestart with new configuration
$ sysg restart --config production.yamlReloads configuration and restarts all services.
If the submitted manifest differs from the loaded one, systemg validates it
before teardown, then applies it: added services start, removed services stop,
and every remaining unit is bounced. restart means restart — the scope is read
off what you asked for, never off the diff, because a rebuilt binary at an
unchanged path hashes identically and a diff-derived scope would leave that
process running behind a green exit code.
$ sysg restart --config production.yaml --delta--delta asks for the narrow reconcile instead: added services start, removed
services stop, changed services restart, and unchanged services retain their
PIDs. A changed dependency also reevaluates its transitive dependents. A
--delta run that ends up bouncing nothing fails with
SG0304 rather than reporting success.
Info
To add a service to the primary project without bouncing the stack, register
the manifest with sysg start --config <file>: a registration applies the same
delta and never bounces what it did not change.
Info
restart -s <service> restarts that service and its transitive dependents in
dependency order. It does not bounce unrelated services.
Restart a project and reload its stored manifest
$ sysg restart --project arbitrationWhen --config is omitted, restart --project reuses the config path the
running supervisor already recorded for that project and reloads it from disk.
Manifest changes are applied: services added since the last load start, services
removed from the manifest stop, and every remaining unit is bounced. You do not
need to pass --config again if the project already has a known config path.
Cron units
restart --service <CRON_UNIT> is invalid. Cron units are scheduler entries,
not persistent services, so they cannot be restarted directly. The command
returns SG0101:
error[SG0101]: cron unit `<name>` cannot be restarted directly
To reschedule cron definitions, reload or restart the whole project. A project restart re-reads the manifest and reschedules every cron unit it defines; it does not run the cron unit immediately. Failed cron runs remain scheduled for their next trigger.
Deployment strategies
Services configured with deployment.strategy: rolling start the candidate
before retiring the old instance:
- New instance starts
- Health checks pass
- (Optional) blue/green
switch_commandshifts traffic to candidate slot - Candidate remains alive through the configured grace/stability gate
- Old instance receives
SIGTERMand stops
This is zero downtime only when both instances can run concurrently and traffic
can reach the candidate. When systemg can infer a fixed port from the health URL
or PORT environment variable, it preflights the rollout as an immediate
restart instead of launching a candidate that cannot bind. Use blue-green slots
when fixed-port zero downtime is required. Services without rolling deployment
stop and then start.
For deployment scripts, pick the form by what the exit code needs to mean:
sysg restart --config <config> --daemonizeUse this when the supervisor may be down and the deploy must restore
daemonized supervision regardless. It returns as soon as the supervisor accepts
the request, so a 0 means "accepted", not "restarted".
sysg restart --config <config>Use this when the supervisor is known to be up and the script should fail on a failed restart. It waits for the operation to finish and reports the real outcome.
See also
start- Launch servicesstop- Stop services- Deployment strategies