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
- Diagnose the reported state: run `systemctl is-system-running` and `systemctl --failed` to see why systemd is degraded, and fix the failing units
- If the system is mid-boot/shutdown, retry the daemon install once systemd reaches running state
- Fall back to `nohup cc-connect > cc-connect.log 2>&1 &` or tmux/screen as the error suggests
- 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
- Monitor `systemctl is-system-running` and fix degraded units before installing services
- Add systemd health checks to deployment scripts prior to any daemon install step
- Keep a nohup/tmux fallback command documented for environments with flaky systemd
- Retry daemon install after boot completes if the system was mid-startup
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
- systemd is not active (state: %s). If running in a contain
- systemctl not found: systemd is required on Linux; if runnin
- systemd user session not available in WSL2. Add the follow
- systemd user session not available. This often happens whe
- systemd is not active in this WSL2 instance. Add the follo
AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06).
Data as JSON: /api/errors/6a15b7a1ab75a87a.
Report an issue: GitHub.