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
- Enable systemd in WSL: add `[boot]\nsystemd=true` under /etc/wsl.conf, then run `wsl --shutdown` from Windows and reopen the distro.
- Update WSL itself (`wsl --update`) — newer WSL versions default systemd on for new distros.
- Use the suggested fallback: `nohup cc-connect > cc-connect.log 2>&1 &` to run without systemd.
- 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
- Enable [boot] systemd=true in /etc/wsl.conf on all WSL2 dev machines.
- Run `wsl --update` to get systemd-by-default WSL releases.
- Keep a nohup fallback path in scripts for systemd-less environments.
- Check `systemctl is-system-running` before any daemon management command.
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
- systemd user session not available in WSL2. Add the follow
- systemctl not found: systemd is required on Linux; if runnin
- systemd is not active (state: %s). If running in a contain
- systemd check failed (state: %s). Use nohup as alternative
- systemd user session not available. This often happens whe
AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06).
Data as JSON: /api/errors/d869cad3f8f8f00a.
Report an issue: GitHub.