What causes "non-critical monitor error: %w" in slimtoolkit/slim?

Inspect the wrapped error (%w) via errors.Unwrap or errors.As to find the root cause.

non-critical monitor error: %w

Error message

non-critical monitor error: %w

What it means

NonCriticalError wraps an error to mark it as non-fatal for the monitoring pipeline. Callers (runWithMonitor, processMonitoringResults, runMonitor) use it to classify monitor failures that should be logged but must not abort the whole sensor run.

Source

Thrown at pkg/app/sensor/monitor/composite.go:343

	fanReport, fanErr := m.fanMon.Status()
	ptReport, ptErr := m.ptMon.Status()

	if fanErr != nil || ptErr != nil {
		return nil, fmt.Errorf(
			"one or more monitors failed: fanotify.error=%q, ptrace.error=%q",
			fanErr, ptErr,
		)
	}

	return &CompositeReport{
		// PeReport: peReport,
		FanReport: fanReport,
		PtReport:  ptReport,
	}, nil
}

func NonCriticalError(err error) error {
	return fmt.Errorf("non-critical monitor error: %w", err)
}

// Using simple io.MultiWriter(os.Stdout, os.File) would make cmd.Wait()
// block until either the cmd's stdout is closed or the multi-writer is closed.
// However, both are impossible. We need the Wait() to return much earlier
// than the process termination (see pkg/monitors/ptrace logic), and multi-writer
// cannot be closed at all. Hence, the pipe trick.
func dupAppStdStream(artifactsDir string, w io.Writer, kind string) (*os.File, *os.File, error) {
	filename := filepath.Join(artifactsDir, "app_"+kind+".log")

	f, err := os.OpenFile(filename, os.O_CREATE|os.O_WRONLY, 0o644)
	if err != nil {
		return nil, nil, fmt.Errorf("cannot open file %q to duplicate app's %s stream: %w", filename, kind, err)
	}

	pr, pw, err := os.Pipe()
	if err != nil {
		f.Close()

View on GitHub (pinned to 81940d17fa)

Solutions

Inspect the wrapped error (%w) via errors.Unwrap or errors.As to find the root cause.
If the failure should be fatal, change the classification at the call site instead of treating it as non-critical.
Fix the underlying monitor issue (privileges, kernel support) to eliminate the warning.

Defensive patterns

Strategy: type-guard

Type guard

func asNonCritical(err error) (error, bool) {
    // the wrapper is textual; inspect the message or match on the wrapped cause
    if err == nil {
        return nil, false
    }
    return errors.Unwrap(err), strings.Contains(err.Error(), "non-critical monitor error")
}

Try / catch

if err := runMonitor(ctx, m); err != nil {
    if _, nonCritical := asNonCritical(err); nonCritical {
        log.Warnf("continuing despite monitor issue: %v", err)
    } else {
        return err
    }
}

Prevention

Treat non-critical monitor errors as degraded-mode signals and log them with context.
Use a sentinel wrapper type instead of matching message text where possible.
Fix root causes (privileges, kernel features) to reduce non-critical failures in production.

When it happens

Trigger: Any code path that wraps a monitor error with NonCriticalError(err) — e.g. a sub-monitor (fanotify or ptrace) failing during a run where its failure is tolerable.

Common situations: fanotify unavailable on the container's filesystem/kernel; ptrace blocked by seccomp/AppArmor; target app exiting early — these get wrapped as non-critical so the scan continues.

Related errors

AI-assisted analysis of slimtoolkit/slim@81940d17fa (2026-08-31). Data as JSON: /api/errors/d8716786f9fb60b9. Report an issue: GitHub.