You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The syslog messages are being sent in RFC 5424 octet-framing from a client app running on one machine directly to Promtail running on another machine; there is no rsyslog or syslog-ng in between.
Using a syslog message generation program allows me to vary the message size for testing. Messages with a length less than 8198 are properly consumed by Promtail. (They will show up just fine when seen in Grafana). Messages with a length >= 8198 cause the above failure.
Replacing Promtail with rsyslog (configured with a $MaxMessageSize of 64k) shows that rsyslog correctly receives the same messages that Promtail rejects.
Issue #2232 mentions that Promtail does not enforce any max message length, but the above possibly suggests otherwise.
To Reproduce
Steps to reproduce the behavior:
Start Promtail with syslog scraper.
Connect from non-local client to Promtail.
Send octet-framed syslog message with MSGLEN >= 8198.
Expected behavior
The message should be consumed and handled just like any other message.
Environment:
Two Linux VMs, one running Promtail, one running a syslog client.
Loki 2.1.0 and associated Promtail
Screenshots, Promtail config, or terminal output
Promtail configuration:
It has been remarked on #2232 that "the error from octet-counted is because it expects the message to be of the exact size mentioned in it's prefix." As best as I can tell, the message is of the correct size. And it doesn't explain why smaller messages are parsed correctly (i.e., if it were an issue with the RFC 5424 implementation of the sender, it should fail for every message).
For additional testing, I allowed the octet count in the message to remain the same while the message itself was either truncated or expanded. In other words, the message prefix would always be "8198 <..." but I might send 8100 bytes of data, or 16k of data. No matter the amount of data that was sent, Promtail failed as above.
Go is not something I'm too familiar with, but I took a look at the master branch of Promtail and the current branch of influxdata/go-syslog. From parser.go:104, this seems to be where the error is generated:
// Next we MUST see a SYSLOGMSG with length equal to MSGLEN
if tok = p.scan(); tok.typ != SYSLOGMSG {
e := fmt.Errorf(`found %s after "%s", expecting a %s containing %d octets`, tok, tok.lit, SYSLOGMSG, p.s.msglen)
func (s *Scanner) scanSyslogMsg() Token {
// Check the reader contains almost MSGLEN characters
n := int(s.msglen)
b, err := s.r.Peek(n)
if err != nil {
return Token{
typ: EOF,
lit: b,
}
}
My guess is that the call to s.r.Peek(n) might be failing with an overflow of an 8192-sized buffer (8198 == 8192 + len(prefix+1)).
This has me stumped, so I've resorted to opening this ticket. Perhaps I am missing something obvious somewhere, but I simply can't seem to get this to work. Any help would be appreciated.
The text was updated successfully, but these errors were encountered:
Describe the bug
Promtail consistently seems to fail when sent syslog messages that exceed a certain length:
The syslog messages are being sent in RFC 5424 octet-framing from a client app running on one machine directly to Promtail running on another machine; there is no rsyslog or syslog-ng in between.
Using a syslog message generation program allows me to vary the message size for testing. Messages with a length less than 8198 are properly consumed by Promtail. (They will show up just fine when seen in Grafana). Messages with a length >= 8198 cause the above failure.
Replacing Promtail with rsyslog (configured with a $MaxMessageSize of 64k) shows that rsyslog correctly receives the same messages that Promtail rejects.
Issue #2232 mentions that Promtail does not enforce any max message length, but the above possibly suggests otherwise.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The message should be consumed and handled just like any other message.
Environment:
Screenshots, Promtail config, or terminal output
Promtail configuration:
Below is the output of tcpdump taken on the Promtail VM:
It has been remarked on #2232 that "the error from octet-counted is because it expects the message to be of the exact size mentioned in it's prefix." As best as I can tell, the message is of the correct size. And it doesn't explain why smaller messages are parsed correctly (i.e., if it were an issue with the RFC 5424 implementation of the sender, it should fail for every message).
For additional testing, I allowed the octet count in the message to remain the same while the message itself was either truncated or expanded. In other words, the message prefix would always be "8198 <..." but I might send 8100 bytes of data, or 16k of data. No matter the amount of data that was sent, Promtail failed as above.
Go is not something I'm too familiar with, but I took a look at the master branch of Promtail and the current branch of influxdata/go-syslog. From parser.go:104, this seems to be where the error is generated:
From scanner.go:122:
My guess is that the call to
s.r.Peek(n)
might be failing with an overflow of an 8192-sized buffer (8198 == 8192 + len(prefix+1)).This has me stumped, so I've resorted to opening this ticket. Perhaps I am missing something obvious somewhere, but I simply can't seem to get this to work. Any help would be appreciated.
The text was updated successfully, but these errors were encountered: