chenhg5/cc-connect · error

systemd check failed (state: %s). Use nohup as alternative

Error message

systemd check failed (state: %s).
  Use nohup as alternative: nohup cc-connect > cc-connect.log 2>&1 &

What it means

This is the fallback branch of checkSystemdRunning in daemon/systemd.go: the systemd state query returned a value that is neither "running" nor the offline/not-booted cases handled earlier, so the exact cause is unknown but systemd is unusable. cc-connect refuses to install a systemd unit because systemctl operations would fail. The message recommends nohup as a direct alternative.

Source

Thrown at daemon/systemd.go:288

	// "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")
	return fmt.Errorf("systemd user session not available.\n"+
		"  This often happens when connecting via SSH without a systemd login session.\n"+
		"  Try one of:\n"+
		"    1. Run as root: sudo cc-connect daemon install (uses system-level systemd)\n"+
		"    2. loginctl enable-linger %s && export XDG_RUNTIME_DIR=/run/user/$(id -u)\n"+

View on GitHub (pinned to 4000b2338a)

Solutions

  1. Diagnose the reported state: run `systemctl is-system-running` and `systemctl --failed` to see why systemd is degraded, and fix the failing units
  2. If the system is mid-boot/shutdown, retry the daemon install once systemd reaches running state
  3. Fall back to `nohup cc-connect > cc-connect.log 2>&1 &` or tmux/screen as the error suggests
  4. If the state string looks valid but is still rejected, report it upstream so checkSystemdRunning can whitelist it (e.g. treat "degraded" as usable)

Example fix

// before
$ cc-connect daemon install
// error: systemd check failed (state: degraded)
// after: repair systemd or bypass
$ systemctl --failed   # fix failing units
$ sudo systemctl reset-failed
$ cc-connect daemon install
// or: nohup cc-connect > cc-connect.log 2>&1 &
Defensive patterns

Strategy: fallback

Validate before calling

state=$(systemctl is-system-running 2>/dev/null || true)
case "$state" in
  running) cc-connect daemon install ;;
  *) echo "systemd state '$state' unusable; falling back to nohup"; nohup cc-connect > cc-connect.log 2>&1 & ;;
esac

Try / catch

if err := daemon.Install(cfg); err != nil {
    var unsupported *daemon.SystemdStateError
    if errors.As(err, &unsupported) {
        slog.Warn("systemd not fully operational, using nohup fallback", "state", unsupported.State)
        return runWithNohup(cfg)
    }
    return fmt.Errorf("daemon install: %w", err)
}

Prevention

When it happens

Trigger: `cc-connect daemon install` when `systemctl is-system-running` returns an unexpected/degraded state such as "degraded", "maintenance", "stopping", or an empty/unparseable response that still indicates systemd is not fully operational.

Common situations: A system booting in degraded state after a failed unit; a system currently shutting down; a systemd build whose is-system-running output cc-connect does not recognize; NixOS or custom init scripts emitting unusual state strings.

Related errors


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