crowdsecurity/crowdsec · warning
EOL after PRI
Error message
EOL after PRI
What it means
The line ended immediately after the PRI (<PRI>) with no version field following. RFC5424 requires 'VERSION' (a 1-3 digit non-zero number) right after PRI, so a line like '<13>' or '<34>\n' is truncated and cannot be a valid RFC5424 message.
Source
Thrown at pkg/acquisition/modules/syslog/internal/parser/rfc5424/parse.go:308
}
r.Message = string(message)
return nil
}
func (r *RFC5424) Parse(message []byte) error {
r.len = len(message)
if r.len == 0 {
return errors.New("syslog line is empty")
}
r.buf = message
err := r.parsePRI()
if err != nil {
return err
}
if r.position >= r.len {
return errors.New("EOL after PRI")
}
err = r.parseVersion()
if err != nil {
return err
}
if r.position >= r.len {
return errors.New("EOL after Version")
}
err = r.parseTimestamp()
if err != nil {
return err
}
if r.position >= r.len {
return errors.New("EOL after Timestamp")View on GitHub (pinned to 909b515798)
Solutions
- Confirm the sender is emitting RFC5424 format with a version digit after PRI (e.g. '<34>1 ...')
- If the line is genuinely RFC3164, this error is expected — let the RFC3164 parser handle it (crowdsec does this automatically in parseLine)
- Check for TCP fragmentation/truncation between sender and collector
Example fix
// before (feeding RFC3164 line to 5424 parser)
p2.Parse([]byte("<34>Jan 1 00:00:00 host tag: msg")) // EOL after PRI
// after
err := p.Parse(line) // try RFC3164 first
if err != nil {
err = p2.Parse(line) // RFC5424
} Defensive patterns
Strategy: try-catch
Validate before calling
func looksRFC5424(line []byte) bool {
// PRI must be followed by a non-zero version digit and a space
end := bytes.IndexByte(line, '>')
return end > 0 && end < 5 && end+1 < len(line) && line[end+1] >= '1' && line[end+1] <= '9'
} Try / catch
var pe *syslog.ParseError
if err := p.Parse(line); err != nil {
if errors.As(err, &pe) {
log.Printf("bad syslog line %q: %v", pe.RawMessage, err)
}
return // handle/fallback
} Prevention
- Ensure senders emit the RFC5424 version field ('1') right after PRI
- Rely on the RFC3164 fallback for legacy senders instead of forcing RFC5424
- Watch for TCP framing issues that split lines mid-header
When it happens
Trigger: Parse([]byte("<13>")) or any input where the cursor reaches the end of the buffer directly after parsePRI() consumes '<PRI>'.
Common situations: An RFC3164-style line (which has no version) is fed to the RFC5424 parser — in crowdsec's syslog source this is normal and triggers the RFC3164 fallback; a client sends a truncated message; a TCP stream was cut mid-line.
Understand the failure class
Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.
Related errors
- PRI must end with '>'
- version must be followed by a space
- EOL after timestamp
- EOL after Version
- EOL after Timestamp
AI-assisted analysis of crowdsecurity/crowdsec@909b515798 (2026-09-06).
Data as JSON: /api/errors/66be406d16954320.
Report an issue: GitHub.