---
title: stop
---

# stop

Stop services for a project, service, or the entire supervisor.

```sh
$ sysg stop
```

## 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 |
| `-` | `--sys` | Opt into privileged system mode. Requires running as root |
| `-` | `--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

```sh
$ sysg stop
```

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

```sh
$ sysg stop --config ./systemg.yaml
```

### Stop a registered project

```sh
$ sysg stop --project arbitration
```

### Stop a specific service

```sh
$ sysg stop --service api
```

Leaves other services running.

For multi-project supervisors, combine project and service selectors:

```sh
$ sysg stop --project arbitration --service api
```

### Shut down the supervisor

```sh
$ sysg stop --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 10 seconds, `SIGKILL` is sent if needed
4. The supervisor remains available unless you used `--supervisor`

When stopping a single service, its dependents keep running. Only crashes trigger cascading stops.

## Reloading a manifest after stop

Stopping a project does not freeze its old unit definitions. Running
`sysg stop --project <id>` followed by `sysg start --config <file>` 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 <id>`](/how-it-works/commands/restart),
which reuses the project's stored config path.

## See also

- [`start`](/how-it-works/commands/start) - Launch services
- [`restart`](/how-it-works/commands/restart) - Restart services
