What do #012 and #015 mean in rsyslog?

In rsyslog's usual control-character escaping, #012 represents line feed (LF, \n) and #015 represents carriage return (CR, \r). The numbers are octal. A Windows-style CRLF sequence is therefore #015#012; the reverse order is LF followed by CR.

These sequences can come from embedded newlines in a stack trace, a sender's line endings, or a prior relay that has already escaped the message. Rsyslog normally performs this escaping during message reception and parsing, rather than only when an output template is rendered.

Normalize one output when appropriate

If the received $msg contains the literal text #015#012, a RainerScript expression can replace that sequence before formatting a specific output:

template(name="CleanMessage" type="list") {
  property(name="$.clean")
  constant(value="\n")
}

if $programname == "myapp" then {
  set $.clean = replace($msg, "#015#012", " ");
  action(type="omfile"
         file="/var/log/myapp-clean.log"
         template="CleanMessage")
  stop
}

This writes message content only, followed by one line terminator. Add timestamp and host fields if the resulting file needs them. The example leaves lone #012 and #015 sequences untouched; handle those separately only if your input contract requires it.

The replacement operates on text. It cannot distinguish an escaped newline from an application that deliberately logged the characters #015#012. Preserve an original copy if that distinction matters, and apply the rule only to an understood stream.

Keep raw control characters only deliberately

The documented global option is:

global(parser.escapeControlCharactersOnReceive="off")

The legacy alternative is $EscapeControlCharactersOnReceive off. There is no equivalent generic escapeCC="off" global parameter. Turning escaping off does not decode strings that an upstream hop already escaped. Depending on the input module, additional newline handling may apply.

Raw LF characters can turn one event into several physical lines in a text output. Property-replacer options such as space-cc act on actual control characters, not an already escaped #012 string. If the destination supports structured data, preserving the field as a JSON string with proper JSON escaping is often clearer than flattening it.

Verify before changing the pipeline

Test four distinct samples: a real LF, a real CRLF, literal #015#012 text, and a normal single-line message. Inspect both the intermediate record and final output. Downstream normalization is also valid, but agree on which layer owns it so multiple stages do not repeatedly transform the same content.

References: rsyslog parser settings and the replace function.