crowdsecurity/crowdsec · error
EOL after timestamp
Error message
EOL after timestamp
What it means
After collecting a non-empty timestamp, parseTimestamp checks that the buffer has not ended. RFC 5424 requires hostname, appname, procid, msgid and structured data after the timestamp, so a line ending right after the timestamp is truncated and rejected.
Source
Thrown at pkg/acquisition/modules/syslog/internal/parser/rfc5424/parse.go:111
r.position += 2
return nil
}
for r.position < r.len {
c := r.buf[r.position]
if c == ' ' {
break
}
timestamp = append(timestamp, c)
r.position++
}
if len(timestamp) == 0 {
return errors.New("timestamp is empty")
}
if r.position == r.len {
return errors.New("EOL after timestamp")
}
date, err := time.Parse(VALID_TIMESTAMP, string(timestamp))
if err != nil {
return errors.New("timestamp is not valid")
}
r.Timestamp = date
r.position++
if r.position >= r.len {
return errors.New("EOL after timestamp")
}
return nil
}
View on GitHub (pinned to 909b515798)
Solutions
- Fix framing so complete syslog frames are delivered (octet counting per RFC 6587 for TCP).
- Verify the sending device includes hostname/appname/procid/msgid/structured-data after the timestamp.
- Check any intermediate transformation (forwarder, log shipper) isn't truncating the message.
Example fix
// before (nothing after timestamp)
parser.Parse([]byte("<34>1 2024-01-01T00:00:00Z"))
// after (full header + message)
parser.Parse([]byte("<34>1 2024-01-01T00:00:00Z host app 1 - msg")) Defensive patterns
Strategy: validation
Validate before calling
// Go: require content after the timestamp token
func hasFieldsAfterTimestamp(line []byte) bool {
// header must have at least '<P>1 TS host ...'
parts := bytes.SplitN(line, []byte(" "), 5)
return len(parts) == 5 && len(parts[3]) > 0
} Try / catch
if err := parser.Parse(line); err != nil {
if strings.Contains(err.Error(), "EOL after timestamp") {
// flag the sender; frame is incomplete
}
} Prevention
- Verify senders emit the full header (hostname onwards) after the timestamp
- Use octet-counted TCP framing to avoid truncation
- Inspect intermediate forwarders for line-cutting transformations
When it happens
Trigger: Calling RFC5424.Parse on "<34>1 2024-01-01T00:00:00Z" — the timestamp loop stops at end of buffer with r.position == r.len, before any time parsing occurs.
Common situations: A device emitting timestamp-only messages, TCP framing dropping the rest of the frame, or a regex/filter upstream cutting the 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 PRI
- EOL after Version
- EOL after Timestamp
AI-assisted analysis of crowdsecurity/crowdsec@909b515798 (2026-09-06).
Data as JSON: /api/errors/b4cb79d2a5984639.
Report an issue: GitHub.