slimtoolkit/slim · error
composite monitor failed: %w
Error message
composite monitor failed: %w
What it means
After the monitor completes, processMonitoringResults calls mon.Status() to collect the composite monitor report. If Status() returns an error, it is logged and wrapped with this message. This means the monitor could not produce a valid status/report.
Source
Thrown at pkg/app/sensor/controlled/controlled.go:245
return s.processMonitoringResults(mon)
}
func (s *Sensor) processMonitoringResults(mon monitor.CompositeMonitor) error {
// A bit of code duplication to avoid starting a goroutine
// for error event handling - keeping the control flow
// "single-threaded" keeps reasoning about the logic.
for _, err := range mon.DrainErrors() {
log.WithError(err).Warn("sensor: non-critical monitor error condition (drained)")
s.exe.PubEvent(event.Error, monitor.NonCriticalError(err).Error())
}
log.Info("sensor: composite monitor is done, checking status...")
report, err := mon.Status()
if err != nil {
log.WithError(err).Error("sensor: composite monitor failed")
return fmt.Errorf("composite monitor failed: %w", err)
}
if err := s.artifactor.Process(
mon.StartCommand(),
s.mountPoint,
report.PeReport,
report.FanReport,
report.PtReport,
); err != nil {
log.WithError(err).Error("sensor: artifact.Process() failed")
return fmt.Errorf("saving reports failed: %w", err)
}
return nil // Clean exit
}
View on GitHub (pinned to 81940d17fa)
Solutions
- Inspect the wrapped error and individual sub-monitor states for the root cause
- Check monitor logs for which sub-monitor failed
- Ensure the monitor was started correctly and had sufficient resources (memory, file descriptors)
Defensive patterns
Strategy: try-catch
Try / catch
err := sensor.Run(ctx)
if err != nil && strings.Contains(err.Error(), "composite monitor failed") {
// inspect sub-monitor states / logs before retry
} Prevention
- Monitor sub-monitor health during runs
- Ensure adequate memory/fd limits for monitors
- Capture monitor logs to correlate with Status() failure
When it happens
Trigger: processMonitoringResults (called from runWithMonitor) invokes mon.Status() and the composite monitor reports failure — e.g. one of its sub-monitors errored or its internal state is invalid.
Common situations: Sub-monitor (PE/fan/Pt) crash mid-run, monitor timeout, corrupted monitor state after resource exhaustion.
Related errors
- run sensor without monitor failed: %w
- run sensor with monitor failed: %w
- failed to prepare artifacts env: %w
- saving reports failed: %w
- sensor shutdown before monitor stop
AI-assisted analysis of slimtoolkit/slim@81940d17fa (2026-08-31).
Data as JSON: /api/errors/ccc3049febf31cc8.
Report an issue: GitHub.