chenhg5/cc-connect · error

systemd is not active in this WSL2 instance. Add the follo

Error message

systemd is not active in this WSL2 instance.
  Add the following to /etc/wsl.conf and restart WSL (wsl --shutdown):
    [boot]
    systemd=true
  Or use: nohup cc-connect > cc-connect.log 2>&1 &

What it means

checkSystemdRunning detects that a systemd binary exists but is not PID 1 in a WSL2 instance, i.e. systemd was never enabled for that distro. Instead of a bare error it returns a detailed, multi-line message telling the user to enable [boot] systemd=true in /etc/wsl.conf and restart WSL, or fall back to running cc-connect with nohup. newPlatformManager surfaces this whenever daemon management is attempted in such an environment.

Source

Thrown at daemon/systemd.go:276

		args = []string{"--user", "is-system-running"}
	}

	out, _ := runSystemctl(args...)
	state := strings.TrimSpace(strings.ToLower(out))

	// These states all mean systemd is usable for managing services
	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" +

View on GitHub (pinned to 4000b2338a)

Solutions

  1. Enable systemd in WSL: add `[boot]\nsystemd=true` under /etc/wsl.conf, then run `wsl --shutdown` from Windows and reopen the distro.
  2. Update WSL itself (`wsl --update`) — newer WSL versions default systemd on for new distros.
  3. Use the suggested fallback: `nohup cc-connect > cc-connect.log 2>&1 &` to run without systemd.
  4. If this is actually a plain container (not WSL2), use a container-appropriate supervisor instead of the systemd manager.

Example fix

// before
$ cc-connect install
# systemd is not active in this WSL2 instance...
// after (in WSL)
$ printf '[boot]\nsystemd=true\n' | sudo tee -a /etc/wsl.conf
$ wsl --shutdown   # from Windows, then reopen WSL
$ cc-connect install
Defensive patterns

Strategy: fallback

Validate before calling

out, err := exec.Command("systemctl", "is-system-running").Output()
state := strings.TrimSpace(string(out))
if err != nil || state == "offline" || strings.Contains(state, "not been booted") {
    return fmt.Errorf("systemd not active; enable [boot] systemd=true in /etc/wsl.conf or use nohup fallback")
}

Type guard

func systemdActive() bool {
    out, err := exec.Command("systemctl", "is-system-running").Output()
    s := strings.TrimSpace(string(out))
    return err == nil && s == "running" || s == "degraded"
}

Try / catch

if err := mgr.Install(cfg); err != nil {
    if strings.Contains(err.Error(), "WSL2") {
        // fall back to nohup-style process management
        return startNohup(cfg)
    }
    return err
}

Prevention

When it happens

Trigger: Running any cc-connect daemon command (install/start/restart/status) inside WSL2 where systemctl exists but `systemctl is-system-running` reports the system as offline/not booted, because /etc/wsl.conf lacks [boot] systemd=true.

Common situations: Fresh WSL2 Ubuntu install (systemd disabled by default on older WSL releases); a WSL distro where the user never enabled systemd; Docker containers sharing the WSL2 VM without systemd.

Understand the failure class

Background: "unsupported platform" / "not supported on this platform" errors: what they mean and how to fix them — this error's family across 47 libraries.

Related errors


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