What causes "failed to process line" in crowdsecurity/crowdsec?

Inspect the wrapped inner error to find why the line failed processing (parse failure, channel closed, etc.).

failed to process line

Error message

failed to process line

What it means

errProcessLine is a sentinel error (pkg/acquisition/modules/kubernetes/run.go:27) that wraps failures of the per-line callback while tailing pod logs. It marks the failure as fatal: followPodLogs (run.go:231) checks errors.Is(err, errProcessLine) and returns immediately instead of retrying, because a processing failure will recur for the same line whereas stream/scan errors are transient.

Source

Thrown at pkg/acquisition/modules/kubernetes/run.go:27

	"time"

	"github.com/prometheus/client_golang/prometheus"
	log "github.com/sirupsen/logrus"
	corev1 "k8s.io/api/core/v1"
	apierrors "k8s.io/apimachinery/pkg/api/errors"
	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
	"k8s.io/apimachinery/pkg/types"
	"k8s.io/client-go/informers"
	"k8s.io/client-go/kubernetes"
	"k8s.io/client-go/tools/cache"

	"github.com/crowdsecurity/crowdsec/pkg/metrics"
	"github.com/crowdsecurity/crowdsec/pkg/pipeline"
)

// errProcessLine marks onLineFunc failures as fatal, as opposed to stream/scan
// errors which followPodLogs retries.
var errProcessLine = errors.New("failed to process line")

func podRef(p *corev1.Pod) string {
	if p == nil {
		return "<nil pod>"
	}
	return fmt.Sprintf("%s/%s uid=%s phase=%s rv=%s node=%s",
		p.Namespace,
		p.Name,
		p.UID,
		p.Status.Phase,
		p.ResourceVersion,
		p.Spec.NodeName,
	)
}

func (s *Source) initClient() error {
	cfg, err := s.config.buildClientConfig(s.logger)
	if err != nil {

View on GitHub (pinned to 909b515798)

Solutions

Inspect the wrapped inner error to find why the line failed processing (parse failure, channel closed, etc.).
Fix the parser/config so the offending log line is handled, or ensure the source's log format matches acquisition expectations.
If the failure is expected to be skippable, make onLineFunc log and return nil instead of an error so tailing continues.

Example fix

// before
if err := processLine(line); err != nil {
    return err // aborts the whole pod tail
}

// after
if err := processLine(line); err != nil {
    logger.Warnf("skipping unparsable line: %s", err)
    return nil // continue tailing
}

Defensive patterns

Strategy: try-catch

Try / catch

if err := run(); err != nil {
    if errors.Is(err, errProcessLine) {
        // fatal: inspect inner cause, fix parser/config; do not retry
        log.Fatalf("fatal line processing failure: %v", err)
    }
    // transient stream error: safe to retry
}

Prevention

Ensure the acquisition parser handles all log formats the selected pods can emit.
Prefer logging-and-skipping bad lines over returning errors from the line callback.
Check the inner wrapped error with errors.Unwrap / %w inspection to find the real cause.

When it happens

Trigger: The onLineFunc passed to followPodLogs returns a non-nil error when processing a scanned line (run.go:220); followPodLogs wraps it with %w: %w into errProcessLine, which then propagates out of the retry loop unchanged.

Common situations: The downstream event pipeline (parsing/arsing the log line) rejects a malformed or unexpected log line emitted by a container, causing the whole log-tail for that pod to abort rather than loop forever on the same bad line.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

AI-assisted analysis of crowdsecurity/crowdsec@909b515798 (2026-09-06). Data as JSON: /api/errors/50cf226bca0a43a3. Report an issue: GitHub.