Syslog Rsyslog and Logrotate

The journal covers a lot of ground, but it isn’t the only logging mechanism running on a typical Debian or Ubuntu system — and it isn’t a full replacement for the older approach either. This chapter covers syslog, the traditional standard still very much in active use, why it coexists with the journal rather than being replaced by it, and logrotate, the tool that keeps the resulting log files from growing forever.

Syslog: A Standard, Not A Program

“Syslog” refers to a logging standard — a defined message format and a set of severity levels — not any single piece of software. You’ve actually already met syslog’s severity levels without the name attached: the emerg through debug priority scale from the journalctl chapter is the same scale syslog originally defined, which systemd’s journal adopted directly rather than inventing its own.

On Debian and Ubuntu, the program actually implementing this standard is rsyslog — a daemon that receives log messages and writes them out as traditional, plain-text files under /var/log, the same directory referenced back when this course first covered the Filesystem Hierarchy Standard.

Why Both journald And rsyslog Exist Together

This is worth explaining directly rather than leaving as an unexplained coincidence: on a typical Debian or Ubuntu install, systemd-journald receives log messages first, then forwards a copy of them to rsyslog, which writes them out in the traditional plain-text format. Both are genuinely running, doing genuinely different jobs with the same underlying data.

Actually systemd-journald on a typical system, only starts after syslog.socket is ready:

systemctl cat systemd-journald | grep syslog

After=systemd-journald.socket systemd-journald-dev-log.socket systemd-journald-audit.socket syslog.socket

journald’s strength is structure — every entry carries metadata (unit, priority, boot ID) that makes precise filtering possible, exactly as covered in the last chapter. rsyslog’s strength is compatibility and reach — plenty of existing tools, scripts, and monitoring systems expect plain text log files in /var/log, and rsyslog can also forward logs to a remote logging server over the network, something the journal alone isn’t built around. In a real infrastructure with many servers, centralizing logs onto one dedicated log server is a common, genuinely important practice — outside the hands-on scope of this chapter, but worth knowing rsyslog is the piece that makes it possible.

    flowchart LR
    A["Kernel & services"] --> B["systemd-journald"]
    B --> C["Structured journal<br/>(journalctl)"]
    B --> D["rsyslog"]
    D --> E["/var/log/*.log<br/>plain text files"]
    D -.->|"optional"| F["Remote log server"]
  

Where rsyslog’s Configuration Lives

cat /etc/rsyslog.conf
ls /etc/rsyslog.d/

Following a pattern you’ve seen before in this course — a main configuration file plus a .d directory of smaller, focused snippets — /etc/rsyslog.conf holds the core configuration, while /etc/rsyslog.d/ holds additional rules, often one file per package or purpose, without needing to edit the main file directly.

Reading A Basic rsyslog Rule

A rule follows a facility.priority action shape:

mail.*                          /var/log/mail.log
auth,authpriv.*                 /var/log/auth.log
kern.*                          /var/log/kern.log

Facility describes the general source or category of a message — a fixed, standard set of categories syslog defines:

Priority is the same emerg through debug scale already covered — * means “any priority.” So auth,authpriv.* reads as: any message from the authentication facilities, at any priority level, gets written to /var/log/auth.log.

Common Log Files And What Generates Them

sudo tail -f /var/log/auth.log

Watching login attempts and sudo usage in real time — directly useful given everything covered in the Privilege Escalation chapter, since every sudo invocation logs here.

sudo less /var/log/syslog

The general catch-all log on Debian-family systems — messages that don’t have a more specific dedicated log file end up here. Every reading tool from earlier in this course — less, grep, tail -f — works on these exactly the way it would on any other plain text file, since that’s genuinely all they are.

logrotate: Keeping Log Files From Growing Forever

Left unmanaged, files like /var/log/syslog would simply grow without bound for as long as the system runs — eventually consuming meaningful disk space with old, rarely-needed historical data. logrotate solves this: periodically, it renames the current log file, starts a fresh empty one in its place, and eventually deletes or compresses the oldest rotated copies once enough time has passed.

ls /etc/logrotate.d/

Like rsyslog, logrotate configuration is split across a main file (/etc/logrotate.conf) and a directory of per-service snippets, typically installed automatically alongside whatever service they apply to.

A typical entry:

/var/log/myapp/*.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

• weekly — rotate on this schedule (daily and monthly are the other common options)
• rotate 4 — keep 4 old rotated copies before deleting the oldest
• compress — gzip rotated copies to save space
• missingok — don’t error out if the log file doesn’t exist yet
• notifempty — skip rotating if the file is currently empty, avoiding pointless empty rotated files

Testing A Rotation Manually

Waiting for the actual schedule to test a new logrotate configuration is impractical — force it to run immediately instead:

sudo logrotate -f /etc/logrotate.conf

-f forces rotation regardless of whether the configured schedule or size threshold has actually been met — the right way to confirm a new configuration behaves as expected before trusting it to run unattended on its normal schedule.

A Long Cheatsheet Of Log Files

It is impossible to remember. Don’t even try. Take it as a reference:

The Confusing Authentication/Login Logs

This distinction matters:

What’s Next

Between the journal and traditional syslog-based logging, you can now find and manage essentially anything a Linux system records about itself. The next chapter shifts to a different kind of automation entirely — running tasks on a schedule, with cron.