Linux online course

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

Learn how traditional syslogd routes Linux log messages using facilities, priorities, selectors, local files, remote hosts, and terminal broadcasts.

syslogd is a traditional Unix and Linux logging daemon. A daemon is a background service process that performs an ongoing task. syslogd receives messages from programs, services, and the kernel, then routes those messages according to rules in a configuration file.

The syslog model separates message classification from message storage. A message has a facility, which identifies its source category, and a priority, also called severity, which describes its urgency. Rules use those values to select messages and send them to destinations such as local files, remote log hosts, or logged-in users' terminals.

Standardized destinations make administration easier. Instead of every program inventing its own storage format and location, administrators can monitor common files, forward records to a central collector, apply retention policies, and investigate failures consistently.

What syslogd does

Applications and system components submit log records to a logging service. The kernel can submit kernel-related messages, mail services can submit mail-related messages, and other programs can select appropriate facilities when they emit messages. syslogd acts as the central routing point for these records.

• It receives messages from local programs, services, and the kernel.
• It evaluates each message against configured selectors.
• It writes matching messages to local destinations, forwards them to remote hosts, or broadcasts urgent messages to terminals.
• It can send one message to more than one destination when multiple rules match.

Centralized handling does not necessarily mean that all logs go to one file. It means that a logging daemon applies consistent routing rules. For example, ordinary mail messages might go to a mail log, serious kernel messages might go to a dedicated kernel log and a central collector, and emergency events might also be broadcast to text-mode users.

How syslog message routing works

A traditional syslog rule has two major parts:

• Selector: the facility and priority expression that determines which messages match.
• Action: the destination or handling instruction applied to matching messages.

The typical structure is a selector, whitespace, and an action:

selector    action

Each configuration line evaluates a class of messages and sends matching records to its action. A message can match multiple rules, so it can be written locally, forwarded remotely, and broadcast at the same time if the configuration requests all three behaviors.

The traditional /etc/syslog.conf file

The traditional configuration file for syslogd is /etc/syslog.conf. Its rules commonly use this form:

facility.priority    action

For example:

kern.alert    /var/log/kern.log

Whitespace separates the selector from the action. Comments and additional syntax may be supported by a particular implementation, but administrators should consult the documentation for the active logging service before using implementation-specific features.

File locations and service-management behavior differ among distributions and newer logging implementations. A system may use /etc/syslog.conf, an rsyslog configuration under /etc/rsyslog.conf or a related directory, syslog-ng configuration, systemd-journald configuration, or a combination of services.

After changing logging configuration, validate the syntax if the implementation provides a validation mode, then reload or restart the correct service using the distribution's service manager. Do not assume that restarting a service named syslogd is correct on every Linux system.

Facilities: message source categories

A facility is the category or source assigned to a syslog message. It lets administrators route messages according to the component that produced them. Applications choose, or are configured to use, facilities when they emit messages.

• kern: kernel-related messages.
• mail: mail-service-related messages.
• Other standard facilities: traditional configurations commonly include rules for many standard categories, depending on the distribution and installed services.

A facility is not necessarily the name of the executable that produced a message. It is a classification chosen by the emitting program or service. Therefore, troubleshooting a missing message includes checking which facility the program actually uses.

Priorities and severity matching

A priority is the urgency level assigned to a message. It is also called severity. Traditional syslog priorities form an ordered hierarchy, with emerg as the most severe level.

In traditional selector behavior, specifying a priority normally selects that priority and more severe priorities. Thus:

kern.alert    /var/log/kern.log

This matches kernel messages at alert and emerg. It does not normally match lower-severity messages such as warning or info.

The priority wildcard * matches all priorities for the selected facility:

mail.*       /var/log/mail

The two wildcard positions have different meanings. In mail.*, the wildcard means every priority for the mail facility. In *.emerg, the wildcard means every facility at the emergency priority.

Writing messages to local files

A local file path in the action portion of a rule tells the logging daemon to write matching records to that file. For example:

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

• The first rule records serious kernel messages in /var/log/kern.log.
• The second rule records every priority from the mail facility in /var/log/mail.

Choose an appropriate log directory, normally under /var/log, and plan for operational maintenance:

• Ensure the destination directory exists.
• Ensure the logging daemon has permission to create or write the file.
• Monitor available disk space.
• Configure log rotation so files do not grow without limit.
• Consider ownership, permissions, retention, and access to potentially sensitive records.

Writing a message to a local file and forwarding it remotely are separate actions. If both are needed, create separate matching rules.

Forwarding logs to a remote host

In traditional syslog syntax, an action beginning with @ forwards matching messages to a remote syslog host. This rule forwards serious kernel messages to the host named suse1:

kern.alert    @suse1

The receiver must be configured to accept syslog input. Remote logging also requires:

• A reachable receiving host.
• Correct hostname resolution for suse1.
• A receiver configured to listen for and accept remote syslog messages.
• Network and firewall rules that permit the selected logging traffic.
• Compatible forwarding syntax and transport settings on the sending and receiving implementations.

Centralized logging can preserve evidence when the sending host fails, becomes inaccessible, or suffers disk corruption. It also provides one location for searching, alerting, retention, and access control. However, forwarding does not automatically replace local logging. Use a local-file rule and a remote-forwarding rule when both destinations are desired.

Broadcasting urgent messages to logged-in users

The traditional action * means a terminal broadcast destination. This rule sends emergency messages from every facility to users logged in through eligible text terminals:

*.emerg      *

The selector *.emerg means emergency messages from all facilities. The action * means broadcast the matching records to logged-in users' terminals.

For example, with both rules below, a mail message at emergency severity is written to the mail log and broadcast to terminal users:

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

Terminal broadcasts should be used carefully because they are disruptive. They may not reach graphical sessions, disconnected sessions, or restricted environments. A broadcast is an immediate notification mechanism, not a replacement for durable local or remote storage.

Traditional syslogd and modern Linux logging

Many current Linux distributions use rsyslog, syslog-ng, or systemd-journald instead of the original syslogd implementation.

rsyslog and syslog-ng retain core syslog concepts such as facilities, severities, routing, local files, and remote forwarding. Syntax, configuration paths, service names, and supported features can vary. Traditional syslogd knowledge is therefore foundational: it explains the syslog protocol and the concepts used by compatible logging systems, even when the installed implementation is different.

Troubleshooting syslog routing

Messages are not appearing in a local file

• Confirm that the emitting program uses the facility expected by the rule.
• Confirm that the message severity matches the selector. Remember that a priority such as alert normally includes that priority and more severe priorities, not lower-severity messages.
• Check the selector syntax and the whitespace separating selector and action.
• Verify that syslogd or the installed replacement is running.
• Reload or restart the active logging service after the change.
• Verify that the destination directory exists and that the daemon can write the target file.
• Check disk space and log rotation behavior.

Messages are not arriving at a remote host

• Confirm that the forwarding rule uses the intended hostname.
• Check hostname resolution and network reachability.
• Confirm that the receiving host is listening for and accepting remote syslog input.
• Check firewalls and other network policy controls on both sides.
• Verify that the sender and receiver support compatible forwarding syntax and transport defaults.

An emergency message was logged but no user saw a notification

• Confirm that a broadcast rule such as *.emerg * exists and matches the message.
• Confirm that users are logged in through eligible text-mode terminals.
• Remember that graphical, disconnected, or restricted sessions may not display terminal broadcasts.

Configuration changes have no effect

• Determine which service is active: syslogd, rsyslog, syslog-ng, systemd-journald, or an integration between them.
• Confirm the active configuration path instead of assuming that /etc/syslog.conf is being read.
• Reload or restart the correct service using the distribution's service manager.
• Review service logs for parse errors or startup failures.

The same event appears in more than one location

Review every matching selector rule. Multiple outputs are normal when a message matches multiple rules. Decide whether the duplicate destinations are intentional for local retention, user notification, alerting, or central collection.

Exam-relevant summary

• syslogd is a traditional background logging daemon.
• A syslog rule consists primarily of a selector and an action.
• A selector combines a facility and a priority, such as kern.alert.
• kern identifies kernel-related messages; mail identifies mail-related messages.
• alert matches alert and more severe messages under traditional behavior.
• * in mail.* means all priorities for mail; * in *.emerg means all facilities.
• A file path writes locally, @hostname forwards remotely, and an action of * broadcasts to eligible terminals.
• One message can match multiple rules and therefore have multiple outputs.
• Always identify the active logging implementation and configuration path before editing or restarting a service.

For related Linux fundamentals, see Linux file structure, managing file ownership, and Network Time Protocol. Text-search skills are also useful when inspecting logs; review searching for text with grep.