VMware ESXi and vSphere Cluster Management

syslogd: Linux System Logging, Facilities, Priorities, and Configuration Rules

Learn how traditional syslogd receives, classifies, and routes Linux log messages using facilities, priorities, selectors, actions, and /etc/syslog.conf.

syslogd is the traditional Unix and Linux logging daemon. It receives messages from the kernel, system services, and applications, then applies configuration rules to decide where each message should go.

This lesson explains the classic syslog model, including facilities, priorities, selectors, actions, local files, remote forwarding, validation, and the differences between traditional syslogd and modern logging services.

What syslogd does

A daemon is a background service that performs work without requiring an interactive terminal. syslogd is a daemon dedicated to receiving and routing log records.

Typical message producers include:

• The kernel, which reports hardware, device, networking, and other kernel events.
• Local services such as cron, mail services, authentication services, and network daemons.
• Applications that explicitly send messages through the syslog interface, often by using the logger command or a programming library.

Rather than every program inventing its own storage and naming scheme, syslogd provides centralized handling. Producers submit messages, the daemon classifies them by facility and priority, and configuration rules route matching records to destinations.

Standard destinations make administration easier. Operators know where to look for classes of events, monitoring tools can watch predictable files or streams, retention can be managed consistently, and troubleshooting does not require learning a separate logging mechanism for every service.

The syslog message model

A syslog record has a producer, a classification, message content, and one or more possible destinations.

• Producer: the kernel, a service, or an application that creates the message.
• Facility: the category or source classification, such as kern or mail.
• Priority: the urgency or severity, such as err or debug.
• Logging daemon: syslogd or a replacement that receives and evaluates the record.
• Action: the operation performed when a rule matches, such as writing a file or forwarding to another host.

A selector is the facility-priority matching part of a rule. An action is the destination or handling operation that follows it.

selector       action

For example, in mail.* /var/log/mail, mail.* is the selector and /var/log/mail is the action.

Facilities

A facility identifies the type or originating subsystem associated with a message. It is a classification, not necessarily the exact executable name that produced the record.

Facility — Typical source — Example use

kern — Kernel messages — Device, hardware, or kernel networking events

user — User-level processes — General user-space messages

mail — Mail systems — Mail transfer and delivery activity

daemon — System daemons — Messages from background services

auth or authpriv — Authentication and security — Login and authorization events; the exact facility name depends on the implementation

syslog — The logging system — Messages generated by the logging service itself

lpr — Printing — Line-printer subsystem messages

news — Network news — Legacy news services

uucp — UUCP services — Legacy Unix-to-Unix communication

cron — Scheduled jobs — Cron and periodic task messages

local0 through local7 — Locally assigned categories — Custom application or site-specific routing

The wildcard facility, written as *, matches messages from all facilities in a selector such as *.emerg.

Applications can choose a local facility when they need a dedicated routing policy. For example, an application might use local0 so its records can be sent to a separate file without mixing them with general daemon messages. The application and the logging implementation must agree on that choice.

Priorities and severity matching

A priority, also called a severity, describes how urgent a message is. The conventional levels are ordered from most urgent to least urgent:

Priority — Relative urgency — Typical interpretation — Selector behavior

emerg — Highest — The system is unusable — Matches only emerg for an exact implementation-specific selector, or is included by broader higher-threshold selectors as defined by the daemon

alert — Very high — Immediate action is required — alert normally matches alert and emerg

crit — High — Critical condition — Normally matches crit, alert, and emerg

err — High — Error condition — Normally matches err and more urgent levels

warning — Moderate — Warning condition — Normally matches warning and more urgent levels

notice — Moderate — Significant but non-error condition — Normally matches notice and more urgent levels

info — Low — Informational event — Normally matches info and more urgent levels

debug — Lowest — Diagnostic detail — Normally matches debug and more urgent levels

In traditional syslog syntax, a selector such as kern.alert normally means “kernel messages at alert severity or higher urgency.” Therefore, it includes alert and emerg.

The priority wildcard * matches all priorities for the selected facilities. Thus, mail.* matches every conventional severity assigned to the mail facility.

Exact-match notation and exclusion syntax can vary between traditional syslogd implementations and replacements. Check the manual page and configuration documentation for the daemon installed on the host before relying on advanced selector syntax.

The traditional configuration file

The traditional syslogd configuration file is /etc/syslog.conf. A basic rule has a selector followed by whitespace and an action.

# This is a comment

kern.alert    /var/log/kern.log
mail.*       /var/log/mail

• Each rule normally occupies one line.
• A line beginning with # is a comment.
• Blank lines improve readability and have no routing effect.
• Whitespace separates the selector from the action.

Modern systems may not use this file. Common alternatives include /etc/rsyslog.conf, files under /etc/rsyslog.d/, or configuration files specific to syslog-ng. A host using systemd-journald may store records in the journal instead of traditional plain-text files.

Selectors

The basic selector form is:

facility.priority

• kern.alert selects urgent kernel messages.
• mail.* selects every priority from the mail facility.
• *.emerg selects emergency messages from every facility.

Traditional syntax can combine facilities with commas and selector clauses with semicolons where supported:

kern,daemon.err    /var/log/system-errors
mail.info;authpriv.notice    /var/log/selected-events

The exact interpretation of multiple clauses, especially whether a later clause replaces or adds to an earlier priority selection, is implementation-dependent. Verify the installed daemon documentation.

A message can match more than one rule. Rules are not automatically mutually exclusive. This allows one event to be stored locally and forwarded remotely, or to be written to a service-specific file and displayed to logged-in users.

Actions and destinations

The action tells the daemon what to do with a matching record.

Action form — Meaning

/var/log/file — Write the record to a local file.

@hostname — Forward the record to a remote host using traditional syslog notation.

* — Notify logged-in users, usually by writing to their terminals where supported.

A named user list — Notify specified users where supported by the implementation.

A pipe or program — Send records to a named pipe or program where supported.

A terminal device — Write to a specified terminal device where supported.

File actions depend on the destination directory existing, correct ownership and permissions, available disk space, and any mandatory access control policy such as SELinux or AppArmor. Log rotation can rename, compress, or remove files, so the daemon and rotation tool must cooperate when a file is replaced or reopened.

Configuration examples

Urgent kernel messages in a local file

kern.alert    /var/log/kern.log

The selector is kern.alert. The action is the local file /var/log/kern.log. Under normal priority matching, alert and more urgent kernel messages, including emerg, are sent to that file.

Forward urgent kernel messages

kern.alert    @suse1

The @ prefix denotes a remote destination in traditional syntax. The receiving host, here named suse1, must resolve correctly, run a compatible receiving service, and be configured to accept remote messages.

This rule can coexist with the local-file rule:

kern.alert    /var/log/kern.log
kern.alert    @suse1

With both rules, the same matching message can be stored locally and forwarded to the central host.

All mail records in one file

mail.*       /var/log/mail

The priority wildcard matches all severities for the mail facility. The resulting file isolates mail-service activity from unrelated system messages.

Emergency notification to logged-in users

*.emerg      *

This matches emergency messages from every facility and broadcasts them to eligible logged-in users' terminals where supported. Because this is an intrusive destination, it is intended for rare, genuinely urgent conditions.

One message matching multiple rules

mail.*       /var/log/mail
*.emerg      *

A mail message with emergency severity matches both selectors. It is written to /var/log/mail and also sent to logged-in users. This behavior is useful to remember when investigating apparent duplication.

Remote logging

Remote logging sends records to a remote log host, usually a central collector. Centralization can simplify searching, retention, alerting, and incident investigation. It also preserves a copy when a source machine becomes unavailable or its local disk is damaged.

The traditional destination notation is:

kern.alert    @loghost.example

Do not assume that this example works immediately. Check the following:

• Hostname resolution: the sender must resolve the name to the intended address.
• Network reachability: routing and connectivity must permit traffic between the hosts.
• Firewall policy: sender and receiver firewalls must permit the selected transport and port.
• Receiver configuration: the target daemon must listen for remote input and permit the sender.
• Transport: traditional implementations commonly use UDP, while some support TCP or other transports. The protocol, port, reliability, and configuration are implementation-dependent.

Traditional unauthenticated or unencrypted forwarding has important security limitations. Messages can be observed, altered, lost, or spoofed in transit. Modern rsyslog and syslog-ng deployments can provide stronger transport options, including TCP-based delivery, TLS encryption, certificates, and authentication. Choose a secure design appropriate for the sensitivity of the logs and verify the receiving implementation's capabilities.

Editing, reloading, and validating configuration

Make a backup or use version control before changing a production logging configuration. First identify the active logging implementation:

sudo cat /etc/syslog.conf
systemctl status syslog rsyslog syslog-ng systemd-journald

The first command may report that the traditional file does not exist. The second command may show missing service units because service names vary by distribution. A running system can use more than one component, such as journald forwarding records to rsyslog.

1. Identify the active daemon and its actual configuration files.
2. Read its manual page and check syntax-validation support.
3. Edit the appropriate file carefully, preserving comments and permissions.
4. Run the daemon's configuration test command when available.
5. Reload the correct service if supported; use a restart only when necessary.
6. Generate a test message and inspect the expected destination.
7. Check service status and error output if routing fails.

logger -p mail.info "Mail logging test"
sudo tail -f /var/log/mail
journalctl -f
sudo systemctl reload rsyslog

The reload command is an rsyslog example, not a universal syslogd command. Use the service-management method for the installed implementation. Reloading a logging service can briefly affect collection, so schedule changes carefully on production systems and confirm that messages continue arriving afterward.

Modern Linux logging context

Component — Typical configuration location — Primary storage model — Relationship to traditional syntax

syslogd — /etc/syslog.conf — Plain-text files, terminals, programs, or remote hosts — Implements the classic facility-priority-action model.

rsyslog — /etc/rsyslog.conf and /etc/rsyslog.d/ — Plain-text files, databases, remote destinations, and other outputs — Extends traditional syslog routing and transport.

syslog-ng — Distribution-specific syslog-ng files — Flexible sources, filters, destinations, and log paths — Uses related concepts but its configuration syntax differs.

systemd-journald — Usually configured through systemd settings rather than /etc/syslog.conf — Structured journal storage queried with journalctl — Can integrate with syslog services, but is not simply traditional syslogd.

Classic syslogd has often been replaced or supplemented by rsyslog, syslog-ng, and systemd-journald. The facility-priority-action model remains foundational even when syntax, inputs, transport, or storage differ.

Journal storage is structured and can contain metadata that plain-text files do not. Use journalctl to query journald records, while tools such as tail are appropriate for traditional text logs. Adapt every example to the active implementation instead of assuming that /etc/syslog.conf exists.

Troubleshooting

A test message is missing from the expected file

• Confirm which daemon is active.
• Confirm that the test facility and priority match the selector. For example, logger -p mail.info requires a rule that accepts mail.info.
• Review all applicable rules and implementation-specific processing behavior.
• Verify that the destination directory exists and that the daemon can write to it.
• Check the journal if the host uses systemd-based logging.

Remote messages do not arrive

• Verify that the destination hostname resolves to the intended address.
• Check network connectivity and firewall policy.
• Confirm that the receiver listens for remote input and allows the sender.
• Check the expected transport and port for the implementation.
• Inspect both sender and receiver logs for parsing, permission, or connection errors.

Messages appear in several places

Review every selector that can match the message. Broad rules such as *.emerg or *.info can overlap with service-specific rules. Multiple destinations may be intentional rather than an error.

Editing /etc/syslog.conf has no effect

• Determine whether the host runs rsyslog, syslog-ng, or journald instead of classic syslogd.
• Locate the active configuration file and included configuration directories.
• Validate and reload or restart the correct service.

A file destination is missing or stops receiving entries

• Check file and parent-directory ownership and permissions.
• Check disk space and inode availability.
• Review logrotate configuration and any post-rotation daemon signaling.
• Review SELinux or AppArmor denials if mandatory access control is enabled.

Exam-relevant summary

• syslogd receives messages from the kernel, services, and applications, then routes them according to rules.
• A facility classifies the message source or subsystem; a priority expresses urgency.
• A selector matches facility and priority; an action specifies the destination.
• kern.alert normally includes alert and more urgent kernel messages.
• mail.* means all priorities for mail; *.emerg means emergency messages from all facilities.
• /etc/syslog.conf is the traditional configuration path, but modern systems may use rsyslog, syslog-ng, or journald.
• A message can match multiple rules and therefore reach multiple destinations.
• @host is traditional remote-forwarding notation; receiver configuration, networking, firewall rules, and transport must also be correct.
• Plain traditional forwarding may lack encryption and authentication; modern secure transport features should be considered.

For the related foundational topic, see syslogd.