RSYSLOG.CONF(5)

💖 RSYSLOG.CONF(5) — Linux System Administration 💖

okay bestie, gather round, because this is rsyslog.conf, the main character of rsyslogd(8) config files, and honestly? she's a lot. but we're gonna get through her together, no cap. 🫶

---

✨ NAME ✨

rsyslog.conf — the configuration file for rsyslogd(8), bestie. the whole vibe of your system logging lives here. 💅

---

🌸 DESCRIPTION 🌸

So. The rsyslog.conf file is the main configuration file for rsyslogd(8), which is the lil daemon that logs system messages on *nix systems. This file is where you write down the rules for logging. If you want the special extra features, go peek at the rsyslogd(8) manpage, okay?

Here's the cute part: rsyslog.conf is backward-compatible with sysklogd's syslog.conf file. So if you're migrating from sysklogd you can literally just rename it and it should work. iconic behavior honestly. ✨

lowkey important: this version of rsyslog ships with extensive documentation in HTML format. It's provided in the ./doc subdirectory, and probably in a separate package if you installed rsyslog via a packaging system. To use rsyslog's advanced features you need to look at that HTML documentation, because the man pages only cover basic aspects of operation. the man page is the trailer, the HTML docs are the full movie, iykyk. 😭

---

🎀 MODULES 🎀

Rsyslog has a modular design. Consequently, there is a growing number of modules (she keeps expanding, we love a growing queen 👑). See the HTML documentation for their full description.

• omsnmp — SNMP trap output module
• omgssapi — Output module for GSS-enabled syslog
• ommysql — Output module for MySQL
• omrelp — Output module for the reliable RELP protocol (prevents message loss). For details, see below at imrelp and the HTML documentation. It can be used like this:

*.*  :omrelp:server:port

*.*  :omrelp:192.168.0.1:2514 # actual sample

• ompgsql — Output module for PostgreSQL
• omlibdbi — Generic database output module (Firebird/Interbase, MS SQL, Sybase, SQLite, Ingres, Oracle, mSQL)
• imfile — Input module for text files
• imudp — Input plugin for UDP syslog. Replaces the deprecated -r option. Can be used like this:

$ModLoad imudp

$UDPServerRun 514

• imtcp — Input plugin for plain TCP syslog. Replaces the deprecated -t option. Can be used like this:

$ModLoad imtcp

$InputTCPServerRun 514

• imrelp — Input plugin for the RELP protocol. RELP can be used instead of UDP or plain TCP syslog to provide reliable delivery of syslog messages. Please note that plain TCP syslog does NOT provide truly reliable delivery — with it, messages may be lost when there is a connection problem or the server shuts down. RELP prevents message loss in those cases. 💯 It can be used like this:

$ModLoad imrelp

$InputRELPServerRun 2514

• imgssapi — Input plugin for plain TCP and GSS-enable syslog
• immark — Support for mark messages
• imklog — Kernel logging. To include kernel log messages, you need to do:

$ModLoad imklog

Please note that the klogd daemon is no longer necessary and consequently no longer provided by the rsyslog package. rest in peace klogd 🕊️

• imuxsock — Unix sockets, including the system log socket. You need to specify:

$ModLoad imuxsock

in order to receive log messages from local system processes. This config directive should only be left out if you know exactly what you are doing. like, exactly exactly. 🙈

---

🦋 BASIC STRUCTURE 🦋

Lines starting with a hash mark ('#') and empty lines are ignored. (yes bestie, comment your config, future you will thank you 💜)

rsyslog.conf should contain the following sections (sorted by recommended order in file):

• Global directives — Global directives set some global properties of the whole rsyslog daemon, for example size of main message queue ($MainMessageQueueSize), loading external modules ($ModLoad) and so on. All global directives need to be specified on a line by their own and must start with a dollar-sign. The complete list of global directives can be found in HTML documentation in doc directory or online on web pages.
• Templates — Templates allow you to specify the format of the logged message. They are also used for dynamic file name generation. They have to be defined before they are used in rules. For more info about templates see the TEMPLATES section of this manpage.
• Output channels — Output channels provide an umbrella for any type of output that the user might want. They have to be defined before they are used in rules. For more info about output channels see the OUTPUT CHANNELS section of this manpage.
• Rules (selector + action) — Every rule line consists of two fields, a selector field and an action field. These two fields are separated by one or more spaces or tabs. The selector field specifies a pattern of facilities and priorities belonging to the specified action.

---

🌈 SELECTORS 🌈

The selector field itself again consists of two parts: a facility and a priority, separated by a period ('.'). Both parts are case insensitive and can also be specified as decimal numbers — but don't do that, you have been warned. ⚠️ Both facilities and priorities are described in syslog(3). The names mentioned below correspond to the similar LOG_-values in /usr/include/syslog.h.

The facility is one of the following keywords: auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, security (same as auth), syslog, user, uucp and local0 through local7. The keyword security should not be used anymore and mark is only for internal use and therefore should not be used in applications. Anyway, you may want to specify and redirect these messages here. The facility specifies the subsystem that produced the message, i.e. all mail programs log with the mail facility (LOG_MAIL) if they log using syslog.

The priority is one of the following keywords, in ascending order: debug, info, notice, warning, warn (same as warning), err, error (same as err), crit, alert, emerg, panic (same as emerg). The keywords error, warn and panic are deprecated and should not be used anymore. The priority defines the severity of the message.

The behavior of the original BSD syslogd is that all messages of the specified priority and higher are logged according to the given action. Rsyslogd behaves the same, but has some extensions. she does a lil extra, as always 💅

In addition to the above mentioned names the rsyslogd(8) understands the following extensions: An asterisk ('*') stands for all facilities or all priorities, depending on where it is used (before or after the period). The keyword none stands for no priority of the given facility.

You can specify multiple facilities with the same priority pattern in one statement using the comma (',') operator. You may specify as much facilities as you want. Remember that only the facility part from such a statement is taken — a priority part would be skipped.

Multiple selectors may be specified for a single action using the semicolon (';') separator. Remember that each selector in the selector field is capable to overwrite the preceding ones. Using this behavior you can exclude some priorities from the pattern.

Rsyslogd has a syntax extension to the original BSD source that makes its use more intuitively. You may precede every priority with an equals sign ('=') to specify only this single priority and not any of the above. You may also (both is valid, too) precede the priority with an exclamation mark ('!') to ignore all that priorities, either exact this one or this and any higher priority. If you use both extensions then the exclamation mark must occur before the equals sign — just use it intuitively. 🧚

okay so here's the part where we have to be real with you, bestie: there are some restrictions over the traditional BSD syslog behaviour. These restrictions stem back to sysklogd, exist probably since at least the 1990's and as such have always been in rsyslog.

Namely, in BSD syslogd you can craft a selector like this:

*.debug;local6.err

The intent is to log all facilities at debug or higher, except for local6, which should only log at err or higher.

Unfortunately, local6.err will permit error severity and higher, but will not exclude lower severity messages from facility local6. 💀 the vibes are not vibing.

As an alternative, you can explicitly exclude all severities that you do not want to match. For the above case, this selector is equivalent to the BSD syslog selector:

*.debug;local6.!=info;local6.!=notice;local6.!=warn

An easier approach is probably to do if ... then based matching in script. ✨

---

🎀 ACTIONS 🎀

ok so bestie, the action part of a rule is literally the whole point — it's what you're actually doing with the message once the selector has claimed it. most of the time you're writing stuff to some kind of "logfile" 📝 but you can also do fancier things like yeeting it into a database table or forwarding it to a whole other host. main character energy, honestly.

---

📁 Regular file 📁

classic behaviour, no notes: messages get logged to actual files. the file has to be given as a full pathname, and it starts with a slash (/). no shortcuts.

Example:

*.* /var/log/traditionalfile.log;RSYSLOG_TraditionalFileFormat      # log to a file in the traditional format

Note: if you want those ✨high-precision timestamps✨ in your log files, just delete the ;RSYSLOG_TraditionalFormat. that switches you over to the default template, which — unless you changed it — uses RFC 3339 timestamps. slay.

Example:

*.*     /var/log/file.log # log to a file with RFC3339 timestamps

ngl, by default files are not synced after every write. if you want syncing on globally, you use either the $ActionFileEnableSync directive or the sync parameter over on omfile. fair warning though — turning this on tanks your performance, so don't do it unless you genuinely know what you're doing 💀. and if you want to turn syncing off for just certain files, prefix the file path with a minus sign (-).

🪈 Named pipes 🪈

this version of rsyslogd(8) can log output into named pipes (fifos). to send log messages to a fifo or named pipe, just prepend a pipe symbol (|) to the file name. super handy for debugging 🐛. one thing though — the fifo has to already exist, created with the mkfifo(1) command, before rsyslogd(8) starts up. no fifo, no vibes.

🖥️ Terminal and console 🖥️

if the file you specified is a tty, rsyslog does special tty-handling for it. same deal with /dev/console.

🌐 Remote machine 🌐

ok so there are three ways to forward a message, and they have very different personalities:

• the traditional UDP transport — extremely lossy but it's the standard
• the plain TCP based transport — only loses messages during certain situations, and it's widely available
• the RELP transport — does not lose messages, but currently only available as part of rsyslogd 3.15.0 and above

to forward messages to another host over UDP, prepend the hostname with the at sign (@). to forward over plain tcp, prepend two at signs (@@). to forward via RELP, prepend the string :omrelp: in front of the hostname.

Example:

*.* @192.168.0.1

in that example up there, messages are forwarded via UDP to the machine 192.168.0.1, and the destination port defaults to 514. and because UDP is just Like That™, you will probably lose some messages in transit 😭. if you're expecting high traffic volume, expect to lose a quite noticeable number of messages — the higher the traffic, the more likely and the more severe the message loss.

sockets for forwarded messages can be bound to a specific device using the device option for the omfwd module.

Example:

action(type="omfwd" Target="192.168.0.1" Device="eth0" Port="514" Protocol="udp")

so in that example, messages get forwarded via UDP to the machine 192.168.0.1 at port 514 over the device eth0. want TCP instead? just set Protocol to "tcp" in that same example. easy.

on Linux with VRF support, the device option is what you use to specify the VRF to send messages.

if you would like to prevent message loss, use RELP:

*.* :omrelp:192.168.0.1:2514

Note: a port number was given there because there is no standard port for relp. iykyk.

also keep in mind you need to load the correct input and output plugins (see "Modules" above 👀).

and heads up — rsyslogd offers a whole variety of options when it comes to remote forwarding. for full details, please see the HTML documentation.

👥 List of users 👥

usually critical messages also get directed to root on that machine. you can specify a list of users who should get the message by simply writing :omusrmsg: followed by the login name. want more than one user? separate them with commas (,). if they're logged in, they get the message — for example: :omusrmsg:root,user1,user2.

📢 Everyone logged on 📢

emergency messages often go out to every user currently online, so everyone knows something strange is happening with the system 🚨. to use this wall(1)-feature, use an :omusrmsg:*.

🗄️ Database table 🗄️

this one lets you log the message to a database table. by default, a MonitorWare-compatible schema is required for this to work. you can create that schema with the createDB.SQL file that came with the rsyslog package. you can also use literally any other schema you like — you just need to define a proper template and assign that template to the action.

for further details on database logging, see the HTML documentation.

🗑️ Discard 🗑️

if the discard action gets carried out, the received message is immediately discarded. discard can be highly effective if you want to filter out some annoying messages that would otherwise fill up your log files 🙈. to do that, place the discard actions early in your log files. this often plays really well with property-based filters, giving you great freedom in specifying what you do not want.

discard is just the single stop command with no further parameters. that's it. that's the whole thing.

Example:

*.*   stop      # discards everything.

📤 Output channel 📤

binds an output channel definition (see there for details) to this action. output channel actions must start with a $-sign — so if you'd like to bind your output channel definition mychannel to the action, use $mychannel. output channels support template definitions like all all other actions. (yes, the original really does say "like all all other actions" — iconic typo, we keep it 💅)

🐚 Shell execute 🐚

this executes a program in a subshell. the program gets passed the template-generated message as the only command line parameter. Rsyslog waits until the program terminates and only then continues to run — so yeah, it's blocking, keep that in mind.

Example:

^program-to-execute;template

program-to-execute can be any valid executable. it receives the template string as a single parameter (argv[1]).

---

🔍 FILTER CONDITIONS 🔍

rsyslog offers three different types of "filter conditions":

• "traditional" severity and facility based selectors
• property-based filters
• expression-based filters

---

🎯 Selectors 🎯

selectors are the traditional way of filtering syslog messages. they've been kept in rsyslog with their original syntax, because it's well-known, highly effective, and also needed for compatibility with stock syslogd configuration files. so if you just need to filter based on priority and facility, do it with selector lines. these are not second-class citizens in rsyslog, ok? they offer the best performance for this job. periodt. 👑

🏷️ Property-Based Filters 🏷️

property-based filters are unique to rsyslogd. they let you filter on any property — like HOSTNAME, syslogtag and msg.

a property-based filter must start with a colon in column 0. that's what tells rsyslogd it's the new filter type. the colon has to be followed by the property name, a comma, the name of the compare operation to carry out, another comma, and then the value to compare against. that value must be quoted. there can be spaces and tabs between the commas, so breathe, bestie. property names and compare operations are case-sensitive — so msg works, while MSG is an invalid property name 😤. in brief, the syntax is:

:property, [!]compare-operation, "value"

the following compare-operations are currently supported:

• contains — checks if the string provided in value is contained in the property
• isequal — compares the "value" string provided and the property contents. these two values must be exactly equal to match.
• startswith — checks if the value is found exactly at the beginning of the property value
• regex — compares the property against the provided regular expression.

🧮 Expression-Based Filters 🧮

see the HTML documentation for this feature. (yes really, that's all it says here — go read the HTML docs, bestie 🫶)

💖 TEMPLATES 💖

okay so bestie, literally every single output in rsyslog runs on templates — files, user messages, all of it. no exceptions. 🫶

The templates that play nice with the stock syslogd formats are hardcoded right into rsyslogd, and if you don't hand it a template, it just grabs one of those hardcoded ones. wanna see them with your own eyes? search for "template_" in syslogd.c and boom, there they are. 🔍

So a template is made of: a template directive</>, a name</>, the actual template text</>, and optional options</>. Like so:

$template MyTemplateName,"\7Text %property% some more
text\n",<options>

The $template is the directive — it's literally rsyslog's way of going "bestie this line is a template, noted." 💅 The backslash is your escape character: \7 rings the bell (yes that's an ASCII value, it's giving terminal jumpscare), and \n is a new line. ngl the escape set in rsyslog is a bit restricted right now, no cap.

Everything in the template gets used literally, EXCEPT the stuff sitting between percent signs. Those are properties, and they're your backstage pass to the contents of the syslog message. You reach them through the property replacer, which can like, pick a substring or do date-specific formatting. more deets live in the PROPERTY REPLACER section of this manpage. ✨

To escape, here's the tea:

% = \%
\ = \\ --> '\' is used to escape (as in C)

$template TraditionalFormat,"%timegenerated% %HOSTNAME%
%syslogtag%%msg%\n"

Properties = accessed by the property replacer (go read that section, it's a whole thing). 🔥

Oh and PLOT TWIST — templates can also be used to generate selector lines with dynamic file names. So say you wanna split syslog messages from different hosts into different files, one per host? iconic, do this:

$template DynFile,"/var/log/system-%HOSTNAME%.log"

Then you use that template when you're defining an output selector line, and you end up with something like "/var/log/system-localhost.log". chef's kiss. 😘

---

✨ Template options ✨

The <options> part? optional. It carries options that influence the template as a whole. Details below, but FIRST, a very important PSA: do NOT mix up template options with property options, bestie. property options get processed by the property replacer and apply to a SINGLE property only — not the whole template. two totally different vibes, don't conflate them. 🚫

Template options are case-insensitive. Currently defined ones:

• sql — formats the string so it's suitable for a SQL statement in MySQL format. This replaces single quotes ("'") and the backslash character with their backslash-escaped counterpart ("´" and "\") inside each field. ⚠️ heads up: in MySQL configuration, the NO_BACKSLASH_ESCAPES mode has to be turned off for this format to work (and that's the default, so you're probably fine).
• stdsql — formats the string suitable for a SQL statement that's getting sent to a standards-compliant sql server. This replaces single quotes ("'") with two single quotes ("''") inside each field. You must use stdsql together with MySQL if the NO_BACKSLASH_ESCAPES is turned on in your MySQL config.

Either the sql or stdsql option MUST be specified when a template is used for writing to a database. If you don't, injection might occur. fr fr, this is not the vibe you want. 💀

And like, because several vendors unfortunately violated the sql standard and introduced their own little escape methods, it's impossible to have one single option doing all the work. so YOU have to make sure you're using the right format. pick the wrong one and you are still vulnerable to sql injection. no cap, be careful. 😭

Also note that the database writer checks that the sql option is present in the template. Not present? the write database action gets disabled. This is on purpose, to guard you against accidentally forgetting it and then becoming vulnerable to SQL injection. protective king behavior honestly. 👑

Fun fact: the sql option can also be useful with files — especially if you wanna import them into a database on another machine for performance reasons. BUT do NOT use it if you don't have a real need for it. among other things, it takes some toll on processing time. not much! but on a really busy system you might notice it ;) 👀

The default template for the write to database action has the sql option set. slay.

---

🌸 Template examples 🌸

PSA first: these samples are split across multiple lines just so they fit here. A template MUST NOT actually be split across multiple lines. don't do it bestie. 🙈

A template that resembles traditional syslogd file output:

$template TraditionalFormat,"%timegenerated% %HOSTNAME%
%syslogtag%%msg:::drop-last-lf%\n"

A template that tells you a little more about the message:

$template
precise,"%syslogpriority%,%syslogfacility%,%timegenerated%,%HOSTNAME%,
%syslogtag%,%msg%\n"

A template for RFC 3164 format:

$template RFC3164fmt,"<%PRI%>%TIMESTAMP% %HOSTNAME%
%syslogtag%%msg%"

A template for the format traditionally used for user messages:

$template usermsg," XXXX%syslogtag%%msg%\n\r"

And a template with the traditional wall-message format:

$template wallmsg,"\r\n\7Message from syslogd@%HOSTNAME% at
%timegenerated%"

A template that can be used for writing to a database (please note the SQL template option):

$template MySQLInsert,"insert iut, message, receivedat values
('%iut%', '%msg:::UPPERCASE%', '%timegenerated:::date-mysql%')
into systemevents\r\n", SQL

NOTE 1: This template is embedded into core application under name StdDBFmt, so you don't need to define it.

NOTE 2: You have to have MySQL module installed to use this template.

---

🦋 OUTPUT CHANNELS 🦋

okay so Output Channels are a new concept, first introduced in rsyslog 0.9.0. But ngl, as of this writing it's most likely that they will be replaced by something different in the future. So if you use them, be prepared to change your configuration file syntax when you upgrade to a later release. it's giving "temporary main character". 😬

Output channels are defined via an $outchannel directive. Its syntax is as follows:

$outchannel name,file-name,max-size,action-on-max-size

breakdown time bestie:

• name — the name of the output channel (not the file! the channel itself)
• file-name — the file name to be written to
• max-size — the maximum allowed size
• action-on-max-size — a command to be issued when the max size is reached

That command always has exactly one parameter. The binary is that part of action-on-max-size before the first space, and its parameter is everything behind that space. periodt.

Keep in mind that $outchannel just defines a channel with a "name". It does NOT activate it. to actually turn it on, you must use a selector line (see below). That selector line includes the channel name plus ":omfile:$" in front of it. a sample might be:

*.* :omfile:$mychannel

and that's how you wake it up. 💅

✨ PROPERTY REPLACER ✨

Okay bestie, this is THE moment. The property replacer is a core component in rsyslogd's output system — like, it's the backbone of everything you're gonna print, fr fr. A syslog message has a bunch of well-defined properties (list incoming, don't worry). Every single one of those properties can be accessed and manipulated by the property replacer. And the way that it lets you grab just part of a property value or transform it — like converting all characters to lower case — is genuinely iconic. 🎀

---

🌸 Accessing Properties 🌸

Syslog message properties get used inside templates. You access them by putting them between percent signs. And the property replacer can modify them while it's at it. Full syntax goes like this:

%propname:fromChar:toChar:options%

propname is the name of the property you're reaching for. And heads up — it is case-sensitive. No cap. 🙈

---

💖 Available Properties 💖

Get comfy, here's the whole roster:

• msg — the MSG part of the message (aka "the message" ;))
• rawmsg — the message exactly as it was received from the socket. Should be useful for debugging.
• HOSTNAME — hostname from the message
• FROMHOST — hostname of the system the message was received from (in a relay chain, this is the system immediately in front of us and not necessarily the original sender)
• syslogtag — TAG from the message
• programname — the "static" part of the tag, as defined by BSD syslogd. For example, when TAG is "named[12345]", programname is "named".
• PRI — PRI part of the message — undecoded (single value)
• PRI-text — the PRI part of the message in a textual form (e.g. "syslog.info")
• IUT — the monitorware InfoUnitType — used when talking to a MonitorWare backend (also for phpLogCon)
• syslogfacility — the facility from the message — in numerical form
• syslogfacility-text — the facility from the message — in text form
• syslogseverity — severity from the message — in numerical form
• syslogseverity-text — severity from the message — in text form
• timegenerated — timestamp when the message was RECEIVED. Always in high resolution
• timereported — timestamp from the message. Resolution depends on what was provided in the message (in most cases, only seconds)
• TIMESTAMP — alias for timereported
• PROTOCOL-VERSION — The contents of the PROTOCOL-VERSION field from IETF draft draft-ietf-syslog-protocol
• STRUCTURED-DATA — The contents of the STRUCTURED-DATA field from IETF draft draft-ietf-syslog-protocol
• APP-NAME — The contents of the APP-NAME field from IETF draft draft-ietf-syslog-protocol
• PROCID — The contents of the PROCID field from IETF draft draft-ietf-syslog-protocol
• MSGID — The contents of the MSGID field from IETF draft draft-ietf-syslog-protocol
• $NOW — The current date stamp in the format YYYY-MM-DD
• $YEAR — The current year (4-digit)
• $MONTH — The current month (2-digit)
• $DAY — The current day of the month (2-digit)
• $HOUR — The current hour in military (24 hour) time (2-digit)
• $MINUTE — The current minute (2-digit)

Properties starting with a $-sign are so-called system properties. These do NOT stem from the message — they're internally-generated. Periodt. 💅

---

🦋 Character Positions 🦋

FromChar and toChar are how you build substrings. They specify the offset within the string that should be copied. And listen — offset counting starts at 1, so if you need the first 2 characters of the message text, you use this syntax: "%msg:1:2%". 🌟

If you don't wanna specify from and to but you do wanna specify options, you still gotta include the colons. For example, if you'd like to convert the full message text to lower case, use "%msg:::lowercase%".

And if you'd like to extract from a position allll the way to the end of the string, you can place a dollar-sign ("$") in toChar (e.g. %msg:10:$%, which will extract from position 10 to the end of the string). Slay.

There's also support for regular expressions. To use them, you need to place a "R" into FromChar. This tells rsyslog that a regular expression instead of position-based extraction is desired. The actual regular expression must then be provided in toChar. The regular expression must be followed by the string "--end". It denotes the end of the regular expression and will not become part of it. If you're using regular expressions, the property replacer will return the part of the property text that matches the regular expression. An example for a property replacer sequence with a regular expression is:

"%msg:R:.*Sev:. \(.*\) \[.*--end%"

Also, extraction can be done based on so-called "fields". To do so, place a "F" into FromChar. A field in its current definition is anything that is delimited by a delimiter character. The delimiter by default is TAB (US-ASCII value 9). However, if can be changed to any other US-ASCII character by specifying a comma and the decimal US-ASCII value of the delimiter immediately after the "F". For example, to use comma (",") as a delimiter, use this field specifier: "F,44". If your syslog data is delimited, this is a quicker way to extract than via regular expressions (actually, a much quicker way). 🔥

Field counting starts at 1. Field zero is accepted, but will always lead to a "field not found" error. The same happens if a field number higher than the number of fields in the property is requested. The field number must be placed in the "ToChar" parameter. An example where the 3rd field (delimited by TAB) from the msg property is extracted is as follows: "%msg:F:3%". The same example with semicolon as delimiter is "%msg:F,59:3%".

Please note that the special characters "F" and "R" are case-sensitive. Only upper case works, lower case will return an error. There are no white spaces permitted inside the sequence (that will lead to error messages and will NOT provide the intended result). 😭

---

👑 Property Options 👑

Property options are case-insensitive. Currently, the following options are defined:

• uppercase — convert property to lowercase only
• lowercase — convert property text to uppercase only
• drop-last-lf — The last LF in the message (if any), is dropped. Especially useful for PIX.
• date-mysql — format as mysql date
• date-rfc3164 — format as RFC 3164 date
• date-rfc3339 — format as RFC 3339 date
• escape-cc — replace control characters (ASCII value 127 and values less then 32) with an escape sequence. The sequence is "#<charval>" where charval is the 3-digit decimal value of the control character. For example, a tabulator would be replaced by "#009".
• space-cc — replace control characters by spaces
• drop-cc — drop control characters — the resulting string will neither contain control characters, escape sequences nor any other replacement character like space.

bestie I'm just the messenger, I typed those first two exactly like the page has them 🙈 no notes, moving on

---

🌈 QUEUED OPERATIONS 🌈

Rsyslogd supports queued operations to handle offline outputs (like remote syslogd's or database servers being down). When running in queued mode, rsyslogd buffers messages to memory and optionally to disk (on an as-needed basis). Queues survive rsyslogd restarts. 💪

It is highly suggested to use remote forwarding and database writing in queued mode, only.

To learn more about queued operations, see the HTML documentation.

---

📁 FILES 📁

• /etc/rsyslog.conf — Configuration file for rsyslogd

---

🔍 SEE ALSO 🔍

• rsyslogd(8), logger(1), syslog(3)

The complete documentation can be found in the doc folder of the rsyslog distribution or online at

https://www.rsyslog.com/doc/

Please note that the man page reflects only a subset of the configuration options. Be sure to read the HTML documentation for all features and details. This is especially vital if you plan to set up a more-then-extremely-simple system. 🫶

---

🎀 AUTHORS 🎀

rsyslogd is taken from sysklogd sources, which have been heavily modified by Rainer Gerhards (rgerhards@adiscon.com) and others.

---

And that's a wrap on the whole page, bestie! This version is 8.2502.0, dated 18 February 2025, and it's the RSYSLOG.CONF(5) page — go forth and configure, you absolute icon. 👑💖