Linux online course

Syslog Protocol Explained for Linux

Learn how Linux syslog classifies, transports, routes, and stores events using facilities, severity levels, selectors, actions, and secure remote logging.

Syslog is a logging protocol and model used by Linux and other Unix-like systems to send, classify, route, and store event messages. It gives applications and operating-system services a common way to report errors, warnings, authentication events, service activity, status changes, and diagnostic output.

This lesson explains the syslog client-server model, facilities, severity levels, PRI values, routing rules, log files, network transport, security, and basic troubleshooting.

What Syslog Does

A logging system has three main jobs:

• Collect: receive messages from applications, services, and the operating system.
• Classify: attach a facility and severity to each message.
• Route: write, forward, or otherwise handle messages according to configuration rules.

An application is a syslog client when it generates and sends a syslog event. A syslog receiver or syslog daemon accepts those messages and applies routing rules. The receiver may run on the same host as the application or on a centralized logging server.

Typical events include kernel errors, failed logins, daemon startup and shutdown, mail activity, filesystem problems, warnings, and application diagnostics.

Syslog Implementations and the Client-Server Model

The word syslog can refer to both a protocol and a general logging model. Programs such as rsyslog, syslog-ng, and older syslogd implementations are logging daemons that implement parts of this model. They are not themselves the definition of the protocol.

Local logging usually follows this path:

1. An application or service creates a message.
2. The message is sent to a local logging interface or daemon.
3. The daemon matches the message against routing rules.
4. The message is written to a file, journal, terminal, user session, database, or another configured output.

In centralized logging, the local daemon additionally forwards selected messages over a network to a remote receiver. Centralization makes searching and retention easier, but it introduces transport, firewall, authentication, and availability concerns.

Where Linux Stores Logs

/var/log is the conventional location for persistent text log files. Common representative files include:

File names and destinations depend on the distribution, active daemon, included configuration files, and local policy. A system using systemd may retain events in the systemd journal instead of, or in addition to, text files. A syslog daemon can be configured to forward messages into the journal or receive messages from another logging component.

ls -lh /var/log
tail -n 50 /var/log/syslog
tail -n 50 /var/log/messages
tail -n 50 /var/log/auth.log

Use only paths that exist on the target host. To inspect a systemd journal, use:

journalctl -b
journalctl -p warning
journalctl -u ssh.service

Facilities, Severity, and Priority

Every syslog message is classified using two values:

• Facility: identifies the source category or subsystem.
• Severity: communicates urgency or impact.

Together they form the message priority, commonly called PRI. The sender selects the facility and severity. The receiver uses them when applying routing rules.

Syslog Facility Codes

Standard syslog facilities use codes from 0 through 23. Some names have historical origins, so a facility may be unused or interpreted differently by a particular implementation.

Applications commonly use local0 through local7 so their events can be separated from unrelated system services. For example, a payment service might use local0 and a web application might use local1. The application must be configured or coded to emit using that facility.

Syslog Severity Levels

Severity codes range from 0 through 7. The lower the number, the more severe the event.

Aliases such as panic, error, and warn are accepted by many tools, but supported names can vary.

PRI Calculation and Message Anatomy

PRI combines the numeric facility and severity:

PRI = (facility × 8) + severity

For mail.info, the facility code is 2 and the severity code is 6:

PRI = (2 × 8) + 6 = 22

A wire-format message may begin with <22>. A rendered log line commonly contains a priority, timestamp, hostname, application or tag, process identifier, and message body. For example, the conceptual structure might look like this:

<PRI> timestamp hostname application[process-id]: message text

Older BSD-style behavior is commonly associated with RFC 3164. RFC 5424 defines a more structured format with explicit fields and structured data. Actual lines differ between daemons, distributions, and configurations, so do not parse a log line based solely on its appearance.

Selectors and Actions

Traditional syslog configuration uses a selector-and-action model:

facility.priority    action

The selector chooses a facility and a priority threshold or matching behavior. The action specifies what to do, such as writing to a file, forwarding to a remote host, displaying to a terminal, notifying users, or invoking another supported output.

Under traditional selector semantics, mail.info generally means “mail messages at info and every more severe level.” That includes info, notice, warning, err, crit, alert, and emerg. It does not include debug.

Illustrative traditional rules are:

mail.info       /var/log/mail.log
authpriv.err   /var/log/auth-critical.log
local0.notice  /var/log/myapp.log

Exact syntax, threshold behavior, file destinations, rule ordering, and extensions vary between rsyslog, syslog-ng, and legacy syslogd. Always check the documentation for the active daemon, validate the configuration, and reload the service according to that implementation.

Practical Local Tests

The logger command sends a test message through the local syslog interface:

logger -p local0.notice "application test event"
logger -p mail.info "mail subsystem test event"

After sending a message, check the configured destination and the journal. The first command should match a rule such as local0.notice /var/log/myapp.log if that rule is active.

Network Transport

Historically, syslog commonly used UDP on port 514. UDP is connectionless: it does not establish a session or provide delivery confirmation. Messages can be lost, duplicated, or received out of order, especially during congestion or network failure.

TCP is also widely supported and provides connection-oriented delivery handling. Port 514 is commonly used when TCP syslog is configured, but port and transport are deployment choices rather than guarantees.

A common rsyslog-style forwarding example is:

*.warning    @@logs.example.net:514

In common rsyslog notation, @@ indicates TCP forwarding. This is not universal syntax. For sensitive or untrusted networks, use TLS rather than plain TCP.

Security Considerations

Traditional syslog over UDP or TCP does not encrypt messages or strongly authenticate their origin. An attacker may intercept sensitive events, spoof messages, alter traffic, or learn details about users, hosts, and services.

TLS-protected syslog is often deployed over TCP port 6514 by convention. TLS can provide confidentiality and peer authentication, but only when configured correctly. Certificate trust-chain validation, hostname or identity validation, permitted peers, key protection, and access controls all matter.

• Restrict logging ports with host and network firewalls.
• Accept remote logs only from trusted source addresses or authenticated peers.
• Protect authentication and authorization logs with appropriate permissions.
• Avoid placing secrets, passwords, tokens, or unnecessary personal data in messages.
• Use TLS for logs crossing untrusted networks.

Operational Filtering and Storage

Facilities and severities let administrators separate kernel, daemon, mail, authentication, and application events. Choose a threshold that provides enough detail for troubleshooting without retaining high-volume debug output indefinitely.

Operational logging also requires:

• Rotation: rename, compress, and replace old files.
• Retention: define how long events must remain available.
• Capacity monitoring: prevent logs, journals, queues, and spool files from filling the filesystem.
• Permissions: restrict sensitive logs to authorized users and services.
• Application tags: use stable names and local facilities to improve filtering and centralized analysis.

Log rotation and journal retention should be tested rather than assumed. A forwarding failure can also cause local queues to grow, so remote delivery health needs monitoring.

Inspecting the Active Logging Service

systemctl status rsyslog
systemctl status syslog-ng
ss -lunpt | grep ':514'
ss -ltnp | grep ':514\|:6514'

Do not assume both rsyslog and syslog-ng are installed. The socket commands help show whether a daemon is listening for network syslog and which transport is configured.

Troubleshooting Syslog

A Test Event Does Not Appear

• Check whether the logging daemon is running.
• Send a known event with an explicit facility and severity using logger.
• Search /var/log and query journalctl.
• Confirm that an active rule matches the selected facility and severity.
• Check whether the distribution uses a different destination or only the journal.

Informational Messages Are Missing

For a rule such as mail.info, verify that the sender actually uses the mail facility. Then confirm the installed daemon's selector semantics, rule ordering, included files, and any later rule that may override or discard the message.

A Remote Receiver Gets Nothing

• Confirm that sender and receiver use the same transport: UDP, TCP, or TLS over TCP.
• Verify the destination address and port.
• Check listening sockets on the receiver.
• Inspect host firewalls, network firewalls, routes, and security policies.
• Confirm that the receiver is configured to accept remote messages.
• Use packet capture only when authorized, and only to verify whether traffic arrives.

Remote Logs Are Unreadable or Untrusted

Identify whether plain UDP or TCP is being used. For TLS, check the certificate, trust chain, hostname validation, permitted peers, and clock accuracy. Incorrect system time can interfere with certificate validation; see Linux NTP for related background.

Logs Consume Disk Space

• Measure usage in /var/log and the journal.
• Identify high-growth files and services.
• Reduce unnecessary debug logging.
• Review rotation and retention settings.
• Check whether failed forwarding is causing queues or spool files to grow.

Exam-Relevant Notes

• Facility identifies the source category; severity identifies urgency.
• PRI is calculated as (facility × 8) + severity.
• Severity 0 is most severe and severity 7 is least severe.
• mail.info traditionally includes info and all more severe priorities, but not debug.
• UDP port 514 is historical and connectionless; TCP and TLS are configuration choices.
• Plain syslog transport does not provide encryption or strong authentication.
• local0 through local7 are intended for local application use.
• Log file names and routing syntax vary by distribution and daemon.

Summary

Syslog provides a common way for Linux applications and services to emit events. A local or remote daemon classifies each event by facility and severity, combines those values into PRI, and routes the result to files, journals, terminals, users, databases, or other destinations. Traditional deployments often use UDP or TCP on port 514, while secure centralized logging commonly uses TLS over TCP, conventionally on port 6514. Reliable operations depend on correct selectors, protected permissions, rotation, retention, capacity monitoring, and verified network security.