Start vs Spawn

start is now the primary process-creation command.

Quick comparison

	start (manifest/ad-hoc)	start (child mode)	spawn (deprecated)
Flags	sysg start [--config ...] [-- command...]	sysg start --parent-pid <pid> [--ttl ...] -- <cmd...>	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:

services:
  web:
    command: "python app.py"
    restart_policy: always
  database:
    command: "postgres"
    depends_on: []

Run with:

$ sysg start

Ad-hoc single command:

$ sysg start --name quick-task -- ./task.sh

Child-mode replacement for spawn:

$ sysg start --parent-pid 12345 --name worker_1 --ttl 3600 -- python job.py

Legacy spawn mapping

Existing invocations:

$ sysg spawn --name worker_1 -- python job.py

Equivalent start command:

$ sysg start --parent-pid <parent_pid> --name worker_1 -- python job.py

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

services:
  queue:
    command: "redis-server"
    restart_policy: always

  scheduler:
    command: "python scheduler.py"
    depends_on: ["queue"]
    spawn:
      mode: dynamic
      limit: 50

The scheduler reads from queue and spawns workers:

# scheduler.py
import os
import subprocess

while job := queue.pop():
    subprocess.run(["sysg", "start", "--parent-pid", str(os.getpid()),
                    "--name", f"job_{job.id}",
                    "--ttl", "3600", "--", "python", "worker.py", job.id])

See also

• start - Launch services
• spawn - Deprecated command reference
• Configuration - Service definitions