Preserve unavailability errors in assertSystemdAvailable

assertSystemdAvailable() now returns on any non-zero systemctl --user status result unless isSystemctlMissing() matches, so errors like Failed to connect to bus are treated as available. That change is user-visible because callers proceed as if systemd is usable; for example, uninstallSystemdService does not check the disable --now result and can report success after deleting the unit file even though systemd never processed the disable/stop request. Please keep throwing for non-degraded unavailability cases instead of falling through for all non-missing failures.

Useful? React with 👍 / 👎.

Addressed — assertSystemdAvailable() now checks for bus-unavailability patterns (failed to connect, not been booted, no such file or directory, not supported) and throws with a descriptive message. See latest commit.

assertSystemdAvailable() does not catch bus-unavailability errors after this fix.

Compare with isSystemdUserServiceAvailable() (lines 178–205): it explicitly checks for unavailability patterns like "failed to connect" (line 190), "not been booted" (line 193), and "not supported" (line 199), and returns false if any match.

The current implementation only checks isSystemctlMissing(), which catches binary-absence errors (lines 149–160) but NOT bus-unavailability. This means if a system's D-Bus is unreachable (e.g., remote SSH without lingering D-Bus socket), assertSystemdAvailable() silently returns, and subsequent systemctl --user stop/restart calls fail downstream with opaque errors instead of the early, helpful "systemctl not available" message.

Suggested fix: Apply the same unavailability checks:

async function assertSystemdAvailable() {
  const res = await execSystemctl(["--user", "status"]);
  if (res.code === 0) {
    return;
  }
  const detail = readSystemctlDetail(res);
  const detailLower = `${res.stderr} ${res.stdout}`.toLowerCase();
  if (
    isSystemctlMissing(detail) ||
    detailLower.includes("failed to connect") ||
    detailLower.includes("not been booted") ||
    detailLower.includes("not supported")
  ) {
    throw new Error(`systemctl --user unavailable: ${detail || "unknown error"}`.trim());
  }
  // Non-zero exit with none of the above patterns → degraded session, still usable.
}

Also add a regression test (e.g., in the "systemd service control" suite) that verifies stopSystemdService throws when the bus is unavailable.

This is a comment left during a code review.
Path: src/daemon/systemd.ts
Line: 207-218

Comment:
`assertSystemdAvailable()` does not catch bus-unavailability errors after this fix. 

Compare with `isSystemdUserServiceAvailable()` (lines 178–205): it explicitly checks for unavailability patterns like `"failed to connect"` (line 190), `"not been booted"` (line 193), and `"not supported"` (line 199), and returns `false` if any match.

The current implementation only checks `isSystemctlMissing()`, which catches binary-absence errors (lines 149–160) but NOT bus-unavailability. This means if a system's D-Bus is unreachable (e.g., remote SSH without lingering D-Bus socket), `assertSystemdAvailable()` silently returns, and subsequent `systemctl --user stop/restart` calls fail downstream with opaque errors instead of the early, helpful `"systemctl not available"` message.

**Suggested fix**: Apply the same unavailability checks:

```ts
async function assertSystemdAvailable() {
  const res = await execSystemctl(["--user", "status"]);
  if (res.code === 0) {
    return;
  }
  const detail = readSystemctlDetail(res);
  const detailLower = `${res.stderr} ${res.stdout}`.toLowerCase();
  if (
    isSystemctlMissing(detail) ||
    detailLower.includes("failed to connect") ||
    detailLower.includes("not been booted") ||
    detailLower.includes("not supported")
  ) {
    throw new Error(`systemctl --user unavailable: ${detail || "unknown error"}`.trim());
  }
  // Non-zero exit with none of the above patterns → degraded session, still usable.
}
```

Also add a regression test (e.g., in the "systemd service control" suite) that verifies `stopSystemdService` throws when the bus is unavailable.

How can I resolve this? If you propose a fix, please make it concise.

Fixed — assertSystemdAvailable() now mirrors the unavailability checks from isSystemdUserServiceAvailable(). Both functions check the same set of patterns.

Treat ENOENT/EACCES as unavailable in user service check

isSystemdUserServiceAvailable() now returns true for any non-zero systemctl --user status result that does not match the hardcoded substrings, but execFileUtf8 reports missing/blocked binaries as messages like spawn systemctl ENOENT / spawn systemctl EACCES (see isSystemctlMissing), which do not match this list. In those environments, availability probes used by onboarding/doctor will incorrectly report systemd as available and proceed down the wrong flow. Reuse isSystemctlMissing (or equivalent checks) here before falling through to true.

Useful? React with 👍 / 👎.

Fixed — added isSystemctlMissing(detail) check before the return true fallthrough in isSystemdUserServiceAvailable(), so ENOENT/EACCES now correctly returns false. Added a test covering the ENOENT case.

Treat spawn ENOENT/EACCES as unavailable

isSystemdUserServiceAvailable() now falls through to true for any non-zero systemctl --user status result that does not match the hardcoded substrings, but execFileUtf8 reports missing or blocked binaries as messages like spawn systemctl ENOENT/spawn systemctl EACCES (see isSystemctlMissing in the same file). On hosts where systemctl is absent or not executable, onboarding/doctor paths that rely on this probe will incorrectly report systemd as available and proceed down the wrong flow.

Useful? React with 👍 / 👎.

Addressed in the latest commit — same fix as above. isSystemctlMissing() catches both ENOENT and EACCES patterns.

Fail fast on unknown status errors before service actions

The new fall-through in assertSystemdAvailable() treats all non-matching systemctl --user status failures as acceptable, which means non-degraded errors (for example permission/policy failures that don't contain the four checked substrings) now proceed into service operations; uninstallSystemdService() then ignores the disable --now result and can print a successful removal after deleting the unit file even though systemd never accepted the disable/stop request. This regression is introduced by returning success on unknown status failures here.

Useful? React with 👍 / 👎.

Addressed — assertSystemdAvailable() now checks isSystemctlMissing() (throws) and bus-unavailability patterns (throws) before silently accepting the degraded state. Only a genuine degraded-but-available systemd falls through without throwing.