henrygd/beszel · error

systemd manager unavailable

Error message

systemd manager unavailable

What it means

On non-Linux platforms, systemdManager is a stub that cannot query systemd. getServiceDetails always returns the error 'systemd manager unavailable', while getFailedServiceCount returns 0. The code compiles on all platforms but systemd data is only available on Linux with a real systemd implementation.

Source

Thrown at agent/systemd_nonlinux.go:37

}

// getServiceStats returns nil for non-linux systems.
func (sm *systemdManager) getServiceStats(conn any, refresh bool) []*systemd.Service {
	return nil
}

// getServiceStatsCount returns 0 for non-linux systems.
func (sm *systemdManager) getServiceStatsCount() int {
	return 0
}

// getFailedServiceCount returns 0 for non-linux systems.
func (sm *systemdManager) getFailedServiceCount() uint16 {
	return 0
}

func (sm *systemdManager) getServiceDetails(string) (systemd.ServiceDetails, error) {
	return nil, errors.New("systemd manager unavailable")
}

View on GitHub (pinned to b38fb7dafa)

Solutions

1. Only enable systemd monitoring for systems running on Linux with actual systemd (PID 1)
2. Check platform-specific build tags — ensure the real systemd implementation file is included on Linux builds
3. Disable the systemd/failed-services metric for non-Linux systems in the hub UI

Example fix

// before: querying service details on a macOS dev machine
sm.getServiceDetails("nginx.service")
// after: guard by GOOS
if runtime.GOOS != "linux" { return } // skip systemd queries

// only query systemd on linux
if runtime.GOOS != "linux" {
    return // skip service details
}

details, err := sm.getServiceDetails(name)
if err != nil && err.Error() == "systemd manager unavailable" {
    details = defaultUnavailableDetails() // graceful degradation
}

When it happens

Trigger: getServiceDetails is called on any non-Linux OS (or a Linux build using the nonlinux stub file), or on Linux when the build tag excluded the real systemd implementation.

Common situations: Running the hub/agent on macOS or Windows during development while systemd monitoring is enabled for a system; deploying in a container without systemd despite a Linux runtime.

Related errors

• service name is required
• missing asset containing ${suffix}
• no sysfs values found
• nvml not supported on this platform
• chcon failed: %w

AI-assisted analysis of henrygd/beszel@b38fb7dafa (2026-08-31). Data as JSON: /api/errors/ce54d2b2932d8dff. Report an issue: GitHub.