systemd is not active (state: %s). If running in a contain

Error message

systemd is not active (state: %s).
  If running in a container, systemd is typically not available.
  Use nohup, tmux, or screen instead:
    nohup cc-connect > cc-connect.log 2>&1 &

What it means

cc-connect's daemon management on Linux requires systemd, which it verifies via checkSystemdRunning before returning a platform Manager from newPlatformManager. This error is thrown when the systemd state query succeeds but reports the system bus is not active (e.g. state "offline" or "System has not been booted with systemd"). It means PID 1 is not systemd, so systemctl/unit management cannot work. The error message explicitly suggests nohup/tmux/screen as alternatives because containers and minimal environments typically lack systemd.

Source

Thrown at daemon/systemd.go:283

	switch state {
	case "running", "degraded", "starting", "initializing":
		return nil
	}

	// "offline" = systemd exists but is not PID 1 (WSL2 without systemd, some containers)
	// "not been booted" / empty = no systemd at all
	wsl := isWSL2()

	if system {
		if wsl {
			return fmt.Errorf("systemd is not active in this WSL2 instance.\n" +
				"  Add the following to /etc/wsl.conf and restart WSL (wsl --shutdown):\n" +
				"    [boot]\n" +
				"    systemd=true\n" +
				"  Or use: nohup cc-connect > cc-connect.log 2>&1 &")
		}
		if state == "offline" || strings.Contains(state, "not been booted") {
			return fmt.Errorf("systemd is not active (state: %s).\n"+
				"  If running in a container, systemd is typically not available.\n"+
				"  Use nohup, tmux, or screen instead:\n"+
				"    nohup cc-connect > cc-connect.log 2>&1 &", state)
		}
		return fmt.Errorf("systemd check failed (state: %s).\n"+
			"  Use nohup as alternative: nohup cc-connect > cc-connect.log 2>&1 &", state)
	}

	// User-level failures
	if wsl {
		return fmt.Errorf("systemd user session not available in WSL2.\n" +
			"  Add the following to /etc/wsl.conf and restart WSL (wsl --shutdown):\n" +
			"    [boot]\n" +
			"    systemd=true\n" +
			"  Or use: nohup cc-connect > cc-connect.log 2>&1 &")
	}

	user := os.Getenv("USER")

View on GitHub (pinned to 4000b2338a)

Solutions

Do not use the daemon subcommand in this environment; run cc-connect directly in the background: `nohup cc-connect > cc-connect.log 2>&1 &`
Use tmux or screen: `tmux new -d -s cc-connect 'cc-connect'`
If in Docker and you need systemd, run the container with systemd as PID 1 (e.g. `--privileged` with a systemd-enabled image) or use a host-side supervisor instead
On a real Linux host, boot with systemd as init and confirm with `ps -p 1 -o comm=` showing `systemd`

Example fix

// before: `cc-connect daemon install` inside a Docker container
// fails with "systemd is not active (state: offline)"
// after: run without daemon management
$ nohup cc-connect > cc-connect.log 2>&1 &
// or in CI/docker-compose use restart policies instead of an internal daemon

Defensive patterns

Strategy: fallback

Validate before calling

state := $(systemctl is-system-running 2>/dev/null)
if [ "$state" != "running" ]; then
  echo "systemd unavailable (state=$state); using nohup fallback"
  nohup cc-connect > cc-connect.log 2>&1 &
else
  cc-connect daemon install
fi

Try / catch

mgr, err := daemon.NewPlatformManager()
if err != nil {
    slog.Warn("daemon manager unavailable, falling back to foreground mode", "error", err)
    return runForeground(ctx)
}

Prevention

Detect containers before using daemon subcommands (check /.dockerenv or systemd state) and document a nohup/tmux runbook for them
In Docker deployments, use restart policies or a host supervisor instead of in-container daemon management
Script the fallback: attempt daemon install, and on failure launch cc-connect with nohup automatically
Verify `ps -p 1 -o comm=` shows systemd on hosts where you plan to use daemon management

When it happens

Trigger: Running `cc-connect daemon install` (or any daemon subcommand) on a machine where `systemctl is-system-running` returns "offline" or a state containing "not been booted" — typically inside a Docker/container without systemd as PID 1.

Common situations: Running cc-connect inside a Docker container or Kubernetes pod; a minimal chroot; WSL1; environments where systemd was replaced (e.g. runit/OpenRC systems).

Related errors

AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06). Data as JSON: /api/errors/0c0f1456ff883ef9. Report an issue: GitHub.