prometheus/node_exporter · error
couldn't get IOPPowerSourcesList
Error message
couldn't get IOPPowerSourcesList: %w
What it means
The Darwin power supply collector's Update calls getPowerSourceList(), which wraps IOKit's IOPSCopyPowerSourcesInfo/IOPSCopyPowerSourcesList. When that IOKit call fails, the error is wrapped as "couldn't get IOPPowerSourcesList". This means the collector could not enumerate the machine's power sources (battery/AC) via IOKit, so no power metrics can be reported for this scrape.
Solutions
- Run the collector outside sandbox/container restrictions so it can talk to IOKit power services (host access, not virtualized).
- Check that macOS power management is functioning (pmset -g batt works for the same user).
- If the host has no queryable power sources, disable the powersupply collector instead of treating the scrape as failed.
Example fix
// before node_exporter --collector.powersupply # inside a container // after node_exporter --collector.powersupply # run directly on the macOS host
Defensive patterns
Strategy: try-catch
Try / catch
// Update already returns the wrapped error; treat it as a failed scrape.
if err := coll.Update(ch); err != nil {
if isPowerSourceUnavailable(err) {
logger.Warn("power sources unavailable; skipping powersupply collection", "err", err)
return nil
}
return err
} Prevention
- Run node_exporter directly on the macOS host, not inside containers or sandboxes.
- Smoke-test IOKit access with `pmset -g batt` under the same user before deploying.
- Disable the powersupply collector on hosts known to have no queryable power sources.
When it happens
Trigger: Update -> getPowerSourceList returning an error, i.e. IOPSCopyPowerSourcesList failing or returning nil on macOS — typically when the process lacks entitlement/sandbox access to IOKit power services or IOKit returns no power sources handle.
Common situations: Running node_exporter inside a sandbox/container on macOS where IOKit power APIs are restricted; running in CI VMs without battery/power-source services; IOKit returning NULL under unusual system states.
Understand the failure class
Background: "API request failed": what wrapped HTTP errors from external APIs mean and how to find the real cause — this error's family across 29 libraries.
Related errors
- could not get power_supply class info
- no CPU power status has been recorded
- invalid flag value
- error obtaining power_supply class info
- failed to open procfs
AI-assisted analysis of prometheus/node_exporter@17ddd77c59 (2026-09-07).
Data as JSON: /api/errors/8f2430846a29a2bd.
Report an issue: GitHub.
Appendix: source
Thrown at collector/powersupplyclass_darwin.go:193
free(ps->InternalFailure);
free(ps->IsPresent);
free(ps);
}
*/
import "C"
import (
"fmt"
"strconv"
"github.com/prometheus/client_golang/prometheus"
)
func (c *powerSupplyClassCollector) Update(ch chan<- prometheus.Metric) error {
psList, err := getPowerSourceList()
if err != nil {
return fmt.Errorf("couldn't get IOPPowerSourcesList: %w", err)
}
for _, info := range psList {
labels := getPowerSourceDescriptorLabels(info)
powerSupplyName := labels["power_supply"]
if c.ignoredPattern.MatchString(powerSupplyName) {
continue
}
for name, value := range getPowerSourceDescriptorMap(info) {
if value == nil {
continue
}
ch <- prometheus.MustNewConstMetric(
prometheus.NewDesc(
prometheus.BuildFQName(namespace, c.subsystem, name),View on GitHub (pinned to 17ddd77c59)