SUSE Linux Enterprise Server 16.1

Managing and Analyzing System Log Files

Publication Date: 05 Nov 2026

System log files record almost everything that happens on your system, from kernel events to service failures and application errors. Knowing where these logs are located, how to query them with journalctl and standard tools and how to read their priority levels lets you diagnose problems quickly instead of guessing. This article also covers logrotate, which automates log rotation and compression to keep logs from filling up your disk.

Prerequisites:

Access to a terminal with sudo privileges

Revision History: Managing and Analyzing System Log Files

1 Where to find system log files? #

SLES logs several types of messages, for example, from the kernel, SELinux or other services.

Kernel messages and messages of system services registered with systemd are logged in the systemd journal (see Section 4, “The systemd journal”). The journal also forwards messages to rsyslog, which writes most of them to plain-text files under the /var/log directory. SELinux messages are logged separately, in /var/log/audit/audit.log.

The following list provides an overview of all system log files found in SLES after a default installation. Depending on your installation scope, /var/log also contains log files from other services and applications not listed here. Some files and directories described below are “placeholders” and are only used when the corresponding application is installed. Most log files are only visible for the user with sudo access. Usually, you can view these files using an editor as they are in plain text.

Important: Unsupported log files

utmp, wtmp and lastlog have been removed from SLES and are no longer supported. If there are any applications that write into these log files, remember that the log files are incomplete then. wtmp has been replaced with wtmpdb, lastlog with lastlog2.

audit/audit.log: Logs from the audit framework, including SELinux access control decisions.
boot.log: Messages logged during the current boot, mirroring what is also shown on the console while the system starts up. boot.msg and boot.omsg contain raw kernel ring buffer dumps from the current and previous boot. They show the same content as dmesg. Use them to find the exact kernel command line of a boot.
chrony/: Logs from the Network Time Protocol daemon (chrony). This directory is empty by default. Files only appear here once you enable specific logging directives (for example, log measurements) in /etc/chrony.conf.
cups/: Access and error logs of the Common Unix Printing System (cups).
firewall, firewalld: firewall catches kernel-level packet-filter messages. firewalld holds errors and warnings from the firewalld daemon itself. Neither is the place to look for logged network traffic unless you have explicitly enabled that in your firewall rules.
journal/: The systemd journal's own storage location. See Section 4, “The systemd journal”.
krb5/: Log files from the Kerberos network authentication system. Empty unless you have installed and configured Kerberos client or server tools.
localmessages: Messages logged to the local0 through local7 facilities, commonly used by third-party applications that do not have a dedicated log file of their own. This file only appears once something logs to one of these facilities.
mail, mail.info, mail.warn, mail.err: Mail server logs, split by severity. Empty unless a mail transfer agent such as postfix is installed.
messages: The default destination for kernel and system log messages, forwarded from the journal by rsyslog. Together with /var/log/warn, this is the first place to look in case of problems.
NetworkManager: NetworkManager log files.
pbl.log: Log of the update-bootloader tool (also known as pbl), which configures the boot loader on SLES. Check this file after a kernel update or a manual boot loader change if the system does not boot as expected.
pcp/: Logs from Performance Co-Pilot, installed and enabled by default for system performance monitoring.
snapper.log: Log of snapper, the tool that manages Btrfs snapshots. Check this file if a scheduled snapshot did not run or a snapshot could not be deleted.
warn: All system warnings and errors, filtered from /var/log/messages.
zypp/: libzypp log files. Refer to these files for the package installation history.
zypper.log: Logs from the command-line installer zypper.

2 Viewing and parsing `/var/log` files #

Plain-text logs in /var/log can be viewed, searched and parsed with standard command-line tools.

For viewing log files, use the commands less or more. Use head and tail to view the beginning or end of a log file. To view entries appended to a log file in real time, use tail -f. For information about how to use these tools, see their man pages.

> sudo tail -f /var/log/messages

To search for strings or regular expressions in log files, use grep. awk is useful for parsing and rewriting log files. For example, to show only lines logged by the sshd-session process:

> sudo grep sshd-session /var/log/messages

Rotated log files are compressed (see Section 5.1, “Configuring logrotate”). SLES compresses them with xz by default, so use xzless, xzcat or xzgrep instead of the less, cat or grep commands above:

> sudo xzgrep sshd-session /var/log/messages-20260828.xz

3 Interpreting log entries #

Whether a message comes from a plain-text file or from the journal, it follows a predictable structure and carries a priority level. Knowing both helps you find what matters quickly.

3.1 Structure of a plain-text log line #

A line in a plain-text log file such as /var/log/messages consists of a time stamp, the host name, the name of the program that generated the message (usually followed by its process ID in brackets) and the message text itself:

Example 1: A line from /var/log/messages #

2026-09-07T09:21:30.439903+02:00 sles16 sshd-session[4731]: pam_unix(sshd:session): session opened for user tux(uid=1000) by tux(uid=0)

In this example, 2026-09-07T09:21:30.439903+02:00 is the time stamp (in ISO 8601 format, including the time zone offset), sles16 is the host name, sshd-session is the program that logged the message, 4731 is its process ID and everything after the colon is the message itself. Not every program includes a process ID. Certain programs log under just their name.

3.2 Priority levels #

Every log message carries a priority level indicating its severity. The same eight levels apply both to journal entries (visible in the PRIORITY field and filterable with journalctl -p) and to the selector lines in rsyslog configuration files (for example, *.err or mail.warning), which decide into which file a message is written. Raw kernel messages, such as those in boot.msg or the output of dmesg, show the same level as a bracketed number prefix, for example, <6> for info.

Table 1: Syslog priority levels #

Level	Name	Meaning
0	`emerg`	The system is unusable.
1	`alert`	Action must be taken immediately.
2	`crit`	A critical condition.
3	`err`	A service or application failed to complete a requested operation.
4	`warning`	Something undesirable happened, but it is not a failure.
5	`notice`	A normal but significant condition.
6	`info`	Normal operational information.
7	`debug`	Information useful for developers only.

When troubleshooting, start by looking for the lowest-numbered (most severe) entries around the time the problem occurred. For example, journalctl -p err -b shows the messages of the current boot with the priority err or more severe (crit, alert and emerg).

4 The `systemd` journal #

systemd features its own logging system called journal. The journal itself is a system service managed by systemd—systemd-journald.service.

The systemd-journald service is enabled and started by default. On SLES, it stores log data persistently in /var/log/journal/, so entries survive a reboot, and forwards a copy of every message to rsyslog (see Section 1, “Where to find system log files?”). To query the journal, use the journalctl command (see Section 4.1, “Using journalctl”).

4.1 Using `journalctl` #

Because the journal stores data in a binary format, you cannot open it directly with tools such as cat or less. Use the journalctl command to query and display its content instead.

Running journalctl without any options displays all logged messages, usually starting from the oldest, and pipes the output through a pager (like less) for easy navigation.

The general syntax of the journalctl command is as follows:

> sudo journalctl [OPTIONS...] [MATCHES...]

Tip: Messages related to a specific executable

To show all journal messages related to a specific executable, specify the full path to the executable:

> sudo journalctl /usr/lib/systemd/systemd

Listed below are the common useful options to enhance the default journalctl behavior:

-f

Shows only the most recent journal messages, and prints new log entries as they are added to the journal.

-e

Prints the messages and jumps to the end of the journal, so that the latest entries are visible within the pager.

-r

Prints the messages of the journal in reverse order, so that the latest entries are listed first.

-k

Shows only kernel messages from the current boot. This is equivalent to -b with the field match _TRANSPORT=kernel.

-u

Shows only messages for the specified systemd unit. Besides messages with _SYSTEMD_UNIT=UNIT, the output includes what systemd logs about the unit, such as start and stop messages and core dump reports.

> sudo journalctl -u apache2

For a complete list of options refer to man page, man 1 journalctl.

5 Controlling log file growth with `logrotate` #

Log files under /var/log grow daily and can quickly become large. logrotate is a tool that helps you manage log files and their growth. It allows automatic rotation, removal, compression and mailing of log files. Log files can be handled periodically (daily, weekly or monthly) or when exceeding a particular size.

logrotate is usually run daily by systemd, and thus usually modifies log files only once a day. However, exceptions occur when a log file is modified because of its size, if logrotate is run multiple times a day or if --force is enabled. View the /var/lib/misc/logrotate.status file to find out when a particular file was last rotated.

logrotate can be configured to suit your needs. For details, see Section 5.1, “Configuring logrotate”.

To test your configuration without rotating anything, run logrotate in debug mode, pointing it at whichever configuration file is in effect (/etc/logrotate.conf if you have created it, or the shipped default otherwise, see Section 5.1, “Configuring logrotate”):

> sudo logrotate -d /usr/etc/logrotate.conf

To rotate logs immediately, for example, right after changing a configuration file, use --force with the same path:

> sudo logrotate --force /usr/etc/logrotate.conf

Important: logrotate does not manage the journal

logrotate only rotates the plain-text files under /var/log. The journal binary storage in /var/log/journal/ is unaffected by it and, unless you have set a limit in a journald.conf.d drop-in, is only capped by the built-in systemd default (a percentage of the file system it resides on).

Check the current journal disk usage and trim it manually if needed with:

> sudo journalctl --disk-usage
> sudo journalctl --vacuum-size=500M

--vacuum-time=TIME (for example, --vacuum-time=2weeks) and --vacuum-files=COUNT work the same way, removing the oldest archived journal files until the given age or file count is reached.

5.1 Configuring `logrotate` #

The main configuration file logrotate.conf defines, for example, how often to rotate logs or which tool is used for data compression. Each service can have its own logrotate configuration in /etc/logrotate.d/. SLES ships with weekly rotation, four kept backlogs and compression enabled by default.

5.1.1 Adjusting `logrotate.conf` #

The default version of logrotate.conf resides in the /usr/etc/ directory. If the default does not suit your needs, copy the file to /etc/logrotate.conf and change the configuration values there. Do not modify the /usr/etc/ version as it may be overwritten with a system update. You can replace the following values:

Example 2: Default /usr/etc/logrotate.conf #

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
compress

# comment these to switch compression to use gzip or another
# compression scheme
compresscmd /usr/bin/xz
uncompresscmd /usr/bin/xzdec

# Additional location (directory or file) for rotation information
# include <file_or_directory>

weekly: The frequency of log rotation. You can use any of the values: hourly, daily, weekly, monthly or yearly.
maxage: You can specify a number of days that logs are kept.
rotate 4: The number determines the amount of log rotations to retain the rotated logs. When set to rotate 0, the logs are deleted immediately. When set to rotate -1, the logs are not removed until they reach the value of maxage.
dateext: If the option is present in the configuration file, rotated log file names receive a suffix with a date in the format logname-YYYYMMDD, for example, messages-20260828.xz. If not present, the default file name scheme is logname.1, logname.2. SLES enables dateext by default.
compress: If commented out, the logs are not compressed. Enabled by default on SLES.
compresscmd and uncompresscmd: Here, you can change the default compression and decompression tools by setting corresponding absolute paths to the tools. SLES uses /usr/bin/xz and /usr/bin/xzdec by default.
include PATH: You can change the default location of the file with log rotation information. The default is /var/lib/misc/logrotate.status.

5.1.2 Service-specific logrotate configuration #

Services and applications can have a specific logrotate configuration in /etc/logrotate.d. Besides the options mentioned in Section 5.1.1, “Adjusting logrotate.conf”, you can also use the following configurations:

missingok: The log rotation does not report errors if any of the specified log files are missing.
notifempty: An empty log file is not rotated.
delaycompress: The compression of rotated logs is postponed until the next log rotation.
sharedscripts: Denotes a section with scripts that should be executed only once regardless of the numbers of logs being rotated. If omitted, the scripts are executed for each log file being rotated.
size: Defines the size a log file can reach before the log rotation is initiated. This option may ignore the time scheduling. The value can be in megabytes (M), kilobytes (K) or bytes (B).
minsize: Logs are rotated according to the specified time schedule if their size exceeds this value. The value can be in megabytes (M), kilobytes (K) or bytes (B).
maxsize: Specifies the maximum log file size. Reaching this limit triggers rotation even when the time interval has not been reached. The value can be in megabytes (M), kilobytes (K) or bytes (B).

6 For more information #

For more information about configuring systemd-journald and filtering the journal by boot, time or field, see Mastering System Logs: From systemd-journald to journalctl.
For more information about the SELinux messages in /var/log/audit/audit.log, see Understanding SELinux logs.

7 Legal Notice #

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”.

For SUSE trademarks, see https://www.suse.com/company/legal/. All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.

All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors, nor the translators shall be held liable for possible errors or the consequences thereof.

Managing and Analyzing System Log Files

1 Where to find system log files? #

2 Viewing and parsing /var/log files #

3 Interpreting log entries #

3.1 Structure of a plain-text log line #

3.2 Priority levels #

4 The systemd journal #

4.1 Using journalctl #

5 Controlling log file growth with logrotate #

5.1 Configuring logrotate #

5.1.1 Adjusting logrotate.conf #