Commands

restart

Restart services or reconcile manifest changes without disturbing unrelated workloads.

$ sysg restart

Warning

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
`-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 --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

$ sysg restart

Restart specific service

$ sysg restart --service api

Restart with new configuration

$ sysg restart --config production.yaml

Reloads configuration and restarts all services.

If the submitted manifest differs from the loaded one, systemg validates it before teardown and applies the diff surgically: added services start, removed services stop, changed services restart, and unchanged services retain their PIDs. A changed dependency also reevaluates its transitive dependents.

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 arbitration

When --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 changed commands take effect. 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_command shifts traffic to candidate slot
Candidate remains alive through the configured grace/stability gate
Old instance receives SIGTERM and 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> --daemonize

Use 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.