Applies to openSUSE Leap 42.1

3 Analyzing and Managing System Log Files

System log file analysis is one of the most important tasks when analyzing the system. In fact, looking at the system log files should be the first thing to do when maintaining or troubleshooting a system. openSUSE Leap automatically logs almost everything that happens on the system in detail. Since the move to systemd, kernel messages and messages of system services registered with systemd are logged in systemd journal (see Book “Reference”, Chapter 11 “journalctl: Query the systemd Journal”). Other log files (mainly those of system applications) are written in plain text and can be easily read using an editor or pager. It is also possible to parse them using scripts. This allows you to filter their content.

3.1 System Log Files in /var/log/

System log files are always located under the /var/log directory. The following list presents an overview of all system log files from openSUSE Leap present 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 root.


AppArmor log files. See Book “Security Guide for details of AppArmor.


Logs from the audit framework. See Book “Security Guide for details.


Logs of the ConsoleKit daemon (daemon for tracking what users are logged in and how they interact with the computer).


Access and error logs of the Common Unix Printing System (cups).


Database file that contains all login failures. Use the faillog command to view. See man 8 faillog for more information.


Firewall logs.


Log files from the GNOME display manager.


Log files from the Kerberos network authentication system.


A database containing information on the last login of each user. Use the command lastlog to view. See man 8 lastlog for more information.


Log messages of some boot scripts, for example the log of the DHCP client.


Mail server (postfix, sendmail) logs.


This is the default place where all Kernel and system log messages go and should be the first place (along with /var/log/warn) to look at in case of problems.


NetworkManager log files.


Log messages from a news server.


Logs from the Network Time Protocol daemon (ntpd).


PackageKit (with libzypp back-end) log files.


Log files from the data center automation tool puppet.


Log files from samba, the Windows SMB/CIFS file server.


Log of all system warnings and errors. This should be the first place (along with the output of the systemd journal) to look in case of problems.


Database of all login/logout activities, and remote connections. Use the command last to view. See man 1 last for more information.


Log files from the extended Internet services daemon (xinetd).


X.Org start-up log file. Refer to this in case you have problems starting X.Org. Copies from previous X.Org starts are numbered Xorg.?.log.


All YaST log files.


libzypp log files. Refer to these files for the package installation history.


Logs from the command line installer zypper.

3.2 Viewing and Parsing Log Files

To view log files, you can use any text editor. There is also a simple YaST module for viewing the system log available in the YaST control center under Miscellaneous › System Log.

For viewing log files in a text console, 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.

To search for strings or regular expressions in log files use grep. awk is useful for parsing and rewriting log files.

3.3 Managing Log Files with logrotate

Log files under /var/log grow on a daily basis and quickly become very 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 as a daily cron job, 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.

The main configuration file of logrotate is /etc/logrotate.conf. System packages and programs that produce log files (for example, apache2) put their own configuration files in the /etc/logrotate.d/ directory. The content of /etc/logrotate.d/ is included via /etc/logrotate.conf.

Example 3.1: Example for /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly

# keep 4 weeks worth of backlogs
rotate 4

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

# use date as a suffix of the rotated file

# uncomment this if you want your log files compressed

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

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d
Important: Avoid Permission Conflicts

The create option pays heed to the modes and ownerships of files specified in /etc/permissions*. If you modify these settings, make sure no conflicts arise.

logrotate is controlled through cron and is called daily by /etc/cron.daily/logrotate. Use /var/lib/logrotate.status to find out when a particular file has been rotated lastly.

3.4 Monitoring Log Files with logwatch

logwatch is a customizable, pluggable log-monitoring script. It parses system logs, extracts the important information and presents them in a human readable manner. To use logwatch, install the logwatch package.

logwatch can either be used at the command line to generate on-the-fly reports, or via cron to regularly create custom reports. Reports can either be printed on the screen, saved to a file, or be mailed to a specified address. The latter is especially useful when automatically generating reports via cron.

On the command line, you can tell logwatch for which service and time span to generate a report and how much detail should be included:

# Detailed report on all kernel messages from yesterday
logwatch --service kernel --detail High --range Yesterday --print

# Low detail report on all sshd events recorded (incl. archived logs)
logwatch --service sshd --detail Low --range All --archives --print

# Mail a report on all smartd messages from May 5th to May 7th to root@localhost
logwatch --service smartd --range 'between 5/5/2005 and 5/7/2005' \
--mailto root@localhost --print

The --range option has got a complex syntax—see logwatch --range help for details. A list of all services that can be queried is available with the following command:

ls /usr/share/logwatch/default.conf/services/ | sed 's/\.conf//g'

logwatch can be customized to great detail. However, the default configuration should usually be sufficient. The default configuration files are located under /usr/share/logwatch/default.conf/. Never change them because they would get overwritten again with the next update. Rather place custom configuration in /etc/logwatch/conf/ (you may use the default configuration file as a template, though). A detailed HOWTO on customizing logwatch is available at /usr/share/doc/packages/logwatch/HOWTO-Customize-LogWatch. The following configuration files exist:


The main configuration file. The default version is extensively commented. Each configuration option can be overwritten on the command line.


Filter for all lines that should globally be ignored by logwatch.


The service directory holds configuration files for each service you can generate a report for.


Specifications on which log files should be parsed for each service.

3.5 Using logger to Make System Log Entries

logger is a tool for making entries in the system log. It provides a shell command interface to the rsyslogd system log module. For example, the following line outputs its message in /var/log/messages or directly in the journal (if no logging facility is running):

logger -t Test "This messages comes from $USER"

Depending on the current user and host name, the log contains a line similar to this:

Sep 28 13:09:31 venus Test: This messages comes from tux
Print this page